-
Notifications
You must be signed in to change notification settings - Fork 46.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Differentiate null and undefined in Custom Elements - removing sets t…
…o undefined (#28716) In React DOM, in general, we don't differentiate between `null` and `undefined` because we expect to target DOM APIs. When we're setting a property on a Custom Element, in the new heuristic, the goal is to allow passing whatever data type instead of normalizing it. Switching between `undefined` and `null` as an explicit value should therefore be respected. However, in this mode if `undefined` is used for the initial value, we don't actually set the property at all. If passing `null` we will now initialize it to the value `null`. Meaning `undefined` kind of represents the default. ### Removing Properties There is a pretty complex edge case which is what should happen when a prop used to exist but was removed from the props object. This doesn't have any kind of defined semantics. It really should mean - return to "default". Because in the declarative world it means the same as if it was just created - i.e. we can't just leave it as it was. The closest might be `delete object.property` but that's not really the intended way that properties on custom elements / classes are supposed to operate. Additionally, for a property to even hit our heuristic it must pass the `in` test and must exist to being with so the default must have a value. Since the point of these properties is to contain any kind of type, there isn't really a conceptual default value. E.g. a numeric default value might be zero `0` while a default string might be empty `""` and default object might `null`. Additionally, the conceptual default can really be initialized to anything. There's also varied precedence in the ecosystem here and really no consensus. Anything we pick would be kind of wrong, so we used to just pick `null`. _The safest way to consume a Custom Element is to always pass the same set of props._ JS does have a concept of a "default value" though and that is described as the value `undefined`. That's why default argument / object property initializers are initialized if the value is `undefined`. The problem with using `undefined` as value is that [you shouldn't actually ever set the value of a class property to `undefined`](https://twitter.com/sebmarkbage/status/1774082540296388752). A property should always be initialized to some value. It can't be left missing and shouldn't be initialized to the value `undefined` for hidden class optimizations. If we just mutate it to be `undefined` it would be potentially bad for perf and shouldn't really be the value after removing property - it should be returned to default. Every property should really have a setter to be useful since it is what is used to trigger reactivity when it changes. Sometimes you can just use the properties passively when something else happens but most of the time it should be a setter but to reach parity with DOM it should really be always so that the active value can be normalized. Those setters can have default argument initializers to represent what the default value should be. Therefore Custom Element properties should be used like this: ```js class CustomElement extends HTMLElement { _textLabel = ''; _price = 0; _items = null; constructor() { super(); } set textLabel(value = '') { this._textLabel = value; } get textLabel() { return this._textLabel; } set price(value = 0) { this._price = value; } get price() { return this._price; } set items(value = null) { this._items = value; } get items() { return this._items; } } ``` The default initializer can be used to initialize a value back to its original default when `undefined` is passed to it. Therefore, we pass `undefined`, not because we expect that to be the value of a property but because that's the value that represents "return to default". This fixes #28203 but not really for the reason specified in the issue. We don't expect you to actually store the `undefined` value but to use a setter to set the property to something else that represents the default. When we initialize the element the first time, we won't set anything if it's the value `undefined` so we assume that the property initializers running in the constructor is going to set the same default value as if we set the property to `undefined`. cc @josepharhar DiffTrain build for [48ec17b](48ec17b)
- Loading branch information
1 parent
9350ce4
commit 385c181
Showing
11 changed files
with
73 additions
and
73 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1 @@ | ||
| ba5496d411a2d3067b5aae58b882aa2041807e77 | ||
| 48ec17b865f439754fcdaa289ef0aa98f15a05c2 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.