Hi Harbs, El lun., 23 dic. 2019 a las 16:20, Harbs (<[email protected]>) escribió:
> I certainly can’t stop you from implementing things how you’d like in > Jewel, but I hope you reconsider. > I think it solves a concrete problem that is very useful. For all what you and Alex said, I understand is not right to put in UIBase, since it needs to maintain as agnostic as possible But since Jewel tries to go straight to the problem, I don't think such level of abstraction would be what we need in that UI Set that tries to be flexible in the implementation. > > I’ll be happy to implement the errors. > Fo me is ok to implement the errors in UIBase. I think the current implementation needs to go one way or another, but not stay in the middle of both. So be free to add it. > > Is there a reason you don’t like the approach of using a method for > “inherit” values? That basically would do what you say, but would be more > explicit about the functionality. I don’t see why using NaN is easier than > calling a method. Making it explicit gives more type safety which seem like > a good thing to me. > Both approach are not ideal to me. I think the problem is that UIBase will reach to all UI sets and visual components (all possible use cases), while making it only for Jewel, (and to every UI set), will need to, in the case of Jewel, add to StyledUIBase, and as well to other containers intermediate classes (three in concrete: Jewel Group, Jewel DataContainerBase and Jewel Container) to cover all jewel code. So both solutions seems to add excessive boilerplate code to Royale so not good for me. Maybe we need to think how to solve this kind of problems where UIBase can't hold a piece of code for PAYG or other reasons. I added StyledUIBase to solve IClassSelectorListSupport problem, that can't be in UIBase, but maybe StyledUIBase is not a good idea since the code in Basic bifurcates and I need to add the exact same code to the three other container classes before mentioned. If you have some other proposal to solve this kind of problems, I'd want to hear it. Thanks > Thanks, > Harbs > > > On Dec 23, 2019, at 5:08 PM, Carlos Rovira <[email protected]> > wrote: > > > > Hi, > > > > ok. I think it's clear there's no much consensus, so I think we should > left > > things as they are now and see other ways to solve. > > I think we can have a removeStyleProperty function that accepts an > element > > and a string property to be removed. This can solve most of the problems > of > > this kind with any property user needs. > > As well, I think since Jewel is more focused on making things easier so > > I'll implement width/height changes at StyledUIBase level. > > > > Thanks for your participation! :) > > > > Carlos > > > > > > > > > > El lun., 23 dic. 2019 a las 11:42, Harbs (<[email protected]>) > escribió: > > > >> > >> > >>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <[email protected]> > >> wrote: > >>> > >>>>> If NaN is not allowed then what’s the uninitialized value? > >>>> > >>>> The initial value is obviously NaN. That has a special meaning on the > >>>> uninitialized state — meaning there’s no value to set. > >>>> > >>> > >>> For me that't the key: in JS a style not set means it has the default > >> value > >>> since is not assigned to a concrete instance. > >>> (width and height defaults to auto, position to static, display to > block > >> or > >>> inline depending on the element). > >> > >> I disagree. That’s just an implementation detail that doesn’t concern > the > >> user. > >> > >> The getter for dimensions never return NaN, so while “_height” might be > >> NaN, “height” (the getter) will never be NaN. > >> > >>> > >>>> > >>>> My point is that *setting* the value to NaN is an anti-pattern > (besides > >>>> adding extra code for that not being PAYG). Usually setting a value > >> which > >>>> is supposed to be a valid number to NaN indicates a bug somewhere. > We’d > >> be > >>>> doing a better service to developers by explicitly making NaN illegal > >> and > >>>> throwing an error rather than allowing it and encouraging an > >> anti-pattern. > >>>> > >>> > >>> We can do that, but IMO the special way JS works will need people to > >> learn > >>> about what means NaN for width/height in Royale, all because JS does in > >>> that strange way, and we need to think "what will be more useful for > our > >>> devs/users?", options are: > >>> > >>> - Remove style value for width/height: I think that will be useful for > >>> them (I know since I work on things like that all the time) > >> > >> We should have an inheritWidth and inheritHeight utility function which > >> removes the style. For non-basic components (such as Jewel), I’d bake > this > >> into the components as a method (with the same name). > >> > >> It likely makes sense to have inheritX and inheritY as well. > >> > >>> - Make it ilegal (throw error): IMHO, people will find this strange > >>> since NaN is a possible value for Number, so I think nothing better or > >>> worse than the above option, but more cumbersome since people will > left > >>> without options to go back to the default value in JS. Then some of > >> them > >>> could try to do going to lower JS code as I did in some components > >> already. > >> > >> We should do this as well. I don’t think it’s strange at all to get an > >> error “height must be a valid number”. It would go a long way towards > >> finding bugs. I’ve actually bumped into this class of bugs already. > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > -- Carlos Rovira http://about.me/carlosrovira
