Attributes and properties for Custom Components

[edoardocavazza]

Do you want to request a feature or report a bug?
Feature
What is the current behavior?
Custom component's properties are always set as attribute.
What is the expected behavior?
Maybe React should watch at the static observedAttributes property for custom elements (https://w3c.github.io/webcomponents/spec/custom/) and then decide to set an attribute or an instance property. Otherwise, objects and array could be always passed as properties, in order to avoid <custom-element prop="[object Object]"></custom-element>.

[robdodson]

I wanted to +1 this issue, I think it would really help out with Custom Element interop. I don't know if React needs to watch observedAttributes, instead it could do something like Preact and check for the property on the node. Or if that's too much work just default to setting properties all the time.

Any custom element built with Polymer (and I believe SkateJS) will have property setters auto-generated so you can rely on them being there for those elements. And we're encouraging developers to rely on properties as their source of truth when building custom elements.

cc @blasten @sebmarkbage @treshugart

[sebmarkbage]

I'm leaning towards a properties-if-available model too.

if (propName in obj) {
  obj[propName] = value;
} else {
  obj.setAttribute(propName, value);
}

[treshugart]

Properties-if-available is what we've done in Skate with our Incremental DOM wrapper FWIW. However, I've recently been messing around with an alternative approach, similar to the proposed events in #7249.

That repo is only a playground for me at the moment, but I really like how you have full control over what is set as properties, attributes and events by having special attributes and events props. I definitely think that's worth considering as there's no error prone internal checks that need to be done. For example, the proposed approach here doesn't work with the custom element polyfill because it's possible that it wouldn't have been upgraded yet (thus have upgraded props) by the time it does the propName in obj check.

[treshugart]

@robdodson

Any custom element built with Polymer (and I believe SkateJS) will have property setters auto-generated so you can rely on them being there for those elements.

Yup, we have first class props.

[blasten]

There's a possibility of a raise condition between upgrading a custom element and running DOM reconciliation. For example:

1. The DOM is initially server-side rendered and the app runs on a browser that doesn't have native CE. React reconciles the DOM, but because the polyfill upgrades CEs in the next micro task, React might set an attribute or a property depending on the order of those calls. If set as an attribute and the value is an object, then the CE will end up with prop="[Object object]" or prop="1,2,3,4".

2. Similar issue, but this time the CE upgrades asynchronously. If React were to always set the values as properties, then a CE constructor could check if a property is defined in the instance. e.g.: If it's an instance prop, remove it and call the setter in the prototype instead. Not great, but better than [Object object].

Any thoughts?

[justinfagnani]

@blasten is correct. If an element is not-upgraded when React sets props, then attributes would be set, and once it's upgraded the element wouldn't have access to the props like it would with properties.

[treshugart]

+1 for what @blasten said. After having messed around with the method I linked to in my last comment, I can say it's a very robust approach. I'm not sure there is a fool proof method other than giving the consumer full control. A positive side effect is that there's less logic necessary to decide what to do.

[treshugart]

As a proof of concept, for this (and #7901) I've created a gist. It is a function that wraps any hyperscript style vdom function and enables full control over props, attributes and events (including custom events) for any vdom implementation that supports ref. It even allows one to pass a custom element constructor as the component name. Details of the implementation are in the readme of the gist.

[blasten]

Thanks for putting that proposal together @treshugart. I think it would be great if all frameworks supported this contract:

• Is it a custom element?
  • Set everything as a property, including events and traditional HTML attributes.

React, Preact:

render() {
  return 
  <div ref="scroller" style={{ overflowY: 'auto' }}>
    <custom-element props={{ 
      onSomething: () => {},
      ariaLabel: 'Tap',
      scroller: () => this.ref.scroller
    }}></custom-element>
  </div>;
}

class CustomElement extends HTMLElement {
  set props(props) {
    let prevProps = this._props;
    // check prevProps.onSomething !== props.onSomething 
    // check prevProps.ariaLabel !== props.ariaLabel 
    this._props = props;
    debounce(this._render);
  }

  get props() {
    return Object.assign({}, this._props);
  }
}

The CE props setter can add event listeners or set attributes when necessary and call it's equivalent render function. The CE can also support setting those props as attributes as long as it knows how to deserialize them. (Mostly for declarative HTML documents) For example:

Declarative HTML

<div id="scrollingElement" style="overflow-y: auto;">
  <custom-element on-something="foo()" aria-label="tap" scroller="scrollingElement">
  </custom-element>
</div>

What I like about this setup is:

1. Simple.
2. A single setter, which drastically reduces the boilerplate for CE authors.
3. Can supports async upgrades because the CE constructor can do something like this:

 if (this.hasOwnProperty('props')) {
    let userProps = self.props;
    delete this.props;
    this.props = userProps;
  }

4. No expensive deserialization.
5. No race conditions. Properties are the source of truth.

I'm curious about your guys thoughts.
cc @addyosmani @robdodson @developit @justinfagnani

[robdodson]

A possible proposal is for CE authors to always use the properties pattern that @blasten has shown, although I don't know if we want to encourage everyone to put everything into a single props object. Instead we might want to do something like:

upgradeProperty(prop) {
  if (this.hasOwnProperty(prop)) {
    let value = this[prop];
    delete this[prop];
    this[prop] = value;
  }
}

Then the Custom Element author could use this approach with any properties their element exposes.

Here's a jsbin that illustrates this technique. h/t to @sjmiles

I believe if CE authors use this technique then React/Preact should be able to always set properties and not worry about attributes. And this will avoid situations where someone ends up with
<x-foo zerp="[object Object]">.

For events I still think it's preferable to use addEventListener as discussed in #7901. Maybe by adding some additional syntax or a heuristic to make this a bit nicer.

[Hypnosphi]

There are some cases, e. g. text input's value, where React both assigns a property AND sets the corresponding attribute. Maybe this option could be helpful here as well.