-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deserializing empty attributes when the property type definition is Number results in "0" #147
Comments
Perhaps:
https://github.com/Netflix/x-element/blob/main/x-element.js#L843 One reason not to do this is that it's not actually the normal behavior of JavaScript, because |
Funny:
This is zero. Wat. Update: we could do:
|
Thanks for the discussion on this one yesterday, @klebba. I think
Ultimately, I think if / when we would decide to allow |
It would always be counter-intuitive to declare `<my-element number>` in HTML markup and introspect the element to find `element.number === 0`. In other words, while it’s true that in JS `Number('') === 0`, this is not sensible behavior when deserializing values in markup into typed objects in JS. This is mostly due to the concept of so-called “boolean attributes”. As a custom element author, you don’t want to coerce a boolean attribute to a `Number`. In otherwords, when dealing with numbers, the markup `<my-element number>` should _not_ equal `<my-element number="0">`. While this change makes a strong opinion, part of the goal of `x-element` is to reduce obvious boiler plate. Since it seems incredibly unlikely that any author would actually _desire_ the `Number('') >> 0` behavior, taking a stance here seems more helpful than hurtful. Additionally, we will always, conceptually, have a _default_ deserializer. In the future, if needed, we could allow authors to declare their own deserializers / serializers within property declarations. Closes #147.
Agree about |
It would always be counter-intuitive to declare `<my-element number>` in HTML markup and introspect the element to find `element.number === 0`. In other words, while it’s true that in JS `Number('') === 0`, this is not sensible behavior when deserializing values in markup into typed objects in JS. This is mostly due to the concept of so-called “boolean attributes”. As a custom element author, you don’t want to coerce a boolean attribute to a `Number`. In otherwords, when dealing with numbers, the markup `<my-element number>` should _not_ equal `<my-element number="0">`. While this change makes a strong opinion, part of the goal of `x-element` is to reduce obvious boiler plate. Since it seems incredibly unlikely that any author would actually _desire_ the `Number('') >> 0` behavior, taking a stance here seems more helpful than hurtful. Additionally, we will always, conceptually, have a _default_ deserializer. In the future, if needed, we could allow authors to declare their own deserializers / serializers within property declarations. Closes #147.
Is it a bug?
Consider:
Where
baz
is defined as a Number type property; the value ofbaz
will be coerced toNumber 0
. This is because, in Javascript,Number('') === 0
.The text was updated successfully, but these errors were encountered: