Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Bug: Removal of custom element property sets it to null rather than undefined #28203

Closed
augustjk opened this issue Feb 1, 2024 · 3 comments · Fixed by #28716
Closed

Bug: Removal of custom element property sets it to null rather than undefined #28203

augustjk opened this issue Feb 1, 2024 · 3 comments · Fixed by #28716
Labels
React 19 Type: Needs Investigation

Comments

@augustjk
Copy link

augustjk commented Feb 1, 2024

React version: experimental

Steps To Reproduce

  1. Set up a React project with react@experimental & react-dom@experimental which includes custom element property support.
  2. Render a custom element with a property value provided as prop, then on a re-render remove that prop.

e.g.

function App() {
  const [condition, setCondition] = useState(false);
  return (
    <>
      <button onClick={() => setCondition(c => !c)}>toggle</button>
      {condition ? <my-element foo={"foo"} /> : <my-element />}
    </>
  );
}

Link to code example:
https://stackblitz.com/edit/vitejs-vite-dz2rka?file=src%2FApp.tsx

The current behavior

The value of the foo property on <my-element> will start off undefined. Toggling condition to true will set the property to "foo", but subsequently toggling condition back to false will set the property to null.

The expected behavior

I would expect the property to be undefined.
@augustjk augustjk added the Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug label Feb 1, 2024
@augustjk
Copy link
Author

augustjk commented Feb 1, 2024

I'm guessing the source of this is behavior is here:

react/packages/react-dom-bindings/src/client/ReactDOMComponent.js

Lines 1776 to 1783 in 2efa383

setPropOnCustomElement(
domElement,
tag,
propKey,
null,
nextProps,
lastProp,
);

@augustjk augustjk mentioned this issue Feb 1, 2024
Merged
@augustjk
Copy link
Author

augustjk commented Mar 29, 2024 •
edited
Loading

@rickhanlonii I saw the update on #11347 about support coming in canary and next major. I just wanted to raise this particular issue so it might be looked at before custom element support gets a wider release.

@rickhanlonii rickhanlonii added Type: Needs Investigation React 19 and removed Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug labels Mar 31, 2024
@rickhanlonii
Copy link
Member

rickhanlonii commented Mar 31, 2024 •
edited
Loading

Thanks for the ping @augustjk.

Confirmed that this is the behavior, we'll need to do some more investigating before deciding what to do here.

I tagged it as a React 19 issue though so we can address before stable.

@sebmarkbage sebmarkbage mentioned this issue Apr 2, 2024
Merged
sebmarkbage added a commit that referenced this issue Apr 2, 2024
@sebmarkbage
Differentiate null and undefined in Custom Elements - removing sets t…
48ec17b 
…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
github-actions bot pushed a commit that referenced this issue Apr 2, 2024
@sebmarkbage
Differentiate null and undefined in Custom Elements - removing sets t…
385c181 
…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)
EdisonVan pushed a commit to EdisonVan/react that referenced this issue Apr 15, 2024
@sebmarkbage @AndyPengc12
Differentiate null and undefined in Custom Elements - removing sets t…
b2aad57 
…o undefined (facebook#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 facebook#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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
React 19 Type: Needs Investigation
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Differentiate null and undefined in Custom Elements - removing sets to undefined sebmarkbage/react
2 participants
@rickhanlonii @augustjk