I certainly can’t stop you from implementing things how you’d like in Jewel, but I hope you reconsider.
I’ll be happy to implement the errors. 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. 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
