Bypass synthetic event system for Web Component events

[staltz]

To use a Web Component in React, you must directly attach an event listener to the React ref for that WC. We could change the implementation so that when React detects a custom element (tag names with dashes, like my-component), it will bypass the synthetic event system (and the whitelist) and just attach the event listener on the element itself.

Why bypass the synthetic event system? Because anyway we already need to bypass it manually when using a Web Component. I'm not so familiar with the React codebase, but this naive approach seems to work. Whoever uses Web Components in React can be responsible for whatever downsides that would cause, maybe in performance, I don't know. They are already having those (supposed) downsides, this issue is just about the convenience of WC usage inside React.

I was about to send a PR for this, but thought of opening an issue. I looked through the issues and didn't see any existing one related to the handling of WC events.

What is the current behavior?

A WC custom event (e.g. flipend) must be handled by attaching the event listener directly to the element in componentDidMount using a ref.

http://jsbin.com/yutocopasu/1/edit?js,output

React v15.1.0

class HelloMessage extends React.Component {
  handleHelloClick() {
    this.refs['foo'].toggle();
  }

  handleFlipend(ev) {
    console.log('Handle flip end');
  }

  componentDidMount() {
    this.refs['foo'].addEventListener('flipend', ev =>
      this.handleFlipend(ev);
    );
  }

  render() {
    return (
      <div>
        <div onClick={ev => this.handleHelloClick()}>
          Hello {this.props.name}, click me!
        </div>
        <brick-flipbox class="demo" ref="foo">
          <div>front</div>
          <div>back</div>
        </brick-flipbox>
      </div>
    );
  }
}

What is the expected behavior?

A WC custom event can be handled with onMyEvent={ev => this.handleMyEvent(ev)} on the ReactElement corresponding to the WC.

class HelloMessage extends React.Component {
  handleHelloClick() {
    this.refs['foo'].toggle();
  }

  handleFlipend(ev) {
    console.log('Handle flip end');
  }

  render() {
    return (
      <div>
        <div onClick={ev => this.handleHelloClick()}>
          Hello {this.props.name}, click me!
        </div>
        <brick-flipbox onFlipend={ev => this.handleFlipend(ev)} class="demo" ref="foo">
          <div>front</div>
          <div>back</div>
        </brick-flipbox>
      </div>
    );
  }
}

PS: this snippet above still has the ref, but for unrelated reasons. Ideally we wouldn't need refs for handling events of WCs.

[treshugart]

https://github.com/webcomponents/react-integration will create a React component from a web component constructor and give you custom event support.

[sebmarkbage]

As long as we only support attributes. I don't see a problem doing this for the heuristic if (typeof props[propName] === 'function') element.addEventListener(propName, props[propName], false). The only concern would be if we should have some heuristic for normalizing the event name. I'm not really a fan of converting things like onXxx into xxx after doing that in MooTools. The other concern is related to #6436 and how we'd handle capture/bubble/passive/active etc.

I'd like it better if we could just pass through all props to element properties but it seems like that ship has sailed since most web components aren't designed to handle properties properly. A massive loss to the community IMO.

[treshugart]

I'd like it better if we could just pass through all props to element properties but it seems like that ship has sailed since most web components aren't designed to handle properties properly. A massive loss to the community IMO.

It feels like that statement is clumping all web components into a single bag of poor design, which in many cases they are, but it doesn't mean you can't optimise for the ones that are designed well. A couple paradigms I'm trying to push in the community (and with SkateJS) are:

• events up, props down
• use props as your source of truth, sync attributes to props when you can

Monica Dinculescu mentioned the former and Rob Dodson the latter in their Polymer Summit talks, so I think that's something they're trying to espouse. It's unfortunate the primitives don't make this more obvious, but I think that comes with the nature of most browser built-ins these days.

React not setting props, and not supporting custom events, is the reason we've had to maintain that React integration library I posted above (https://github.com/webcomponents/react-integration). It's worth looking at as a source of some patterns that are definitely working for us in production. It's also worth noting that the patterns employed there are also used in Skate's wrapper around Incremental DOM. We set props for everything we can, falling back to attributes as a last resort.

In the integration lib, events have their own special convention, similar to React's. This in particular is something to pay attention to because adding event listeners if prop is a function - without checking the name for something like /^on[A-Z].*/ - will prefer events over properties.You could flip that around and set props if prop in element and leave it up to the web component to addEventListener() when the onClick property is set. This creates a little more work for the component, but means you don't have to do the prefix checking if you're not a fan.

[sebmarkbage]

@treshugart Most people seem to find this counter-intuitive but my preference would be to effectively just call Object.assign(element, props). It sounds like you'd be a fan of that approach as well? Maybe there is still hope to change the Web Components ecosystem to prefer that - and indeed React promoting that style would perhaps help.

@staltz What do you think about that approach?

[treshugart]

@sebmarkbage I like that approach but I think there are a few things to consider (and you're probably already aware):

1. Props don't work for all elements. SVGElement will error if you set width as a property, for example because it's readonly.
2. Attributes don't work for all elements. HTMLInputElement needs value set as a property, for example because the attribute does not 2-way sync once the property is set or a user sets a value.
3. Some web components may have edge-cases where an attribute-only handler is necessary (aria-*, maybe).
4. Attributes with dashes (my-property) reflected to camel-cased props (myProperty). What is the behaviour here? Probably fine to not worry about this case because the consumer can just use <x-element myProperty={something} />.
5. Attributes with the same name as the property. What happens if the property is only a getter (no set() or writable: false)? There's no way for the consumer to prefer the attribute. Maybe this is something that is enforced; that the component author must provide a setter or the consumer has to <x-element ref={e => e.setAttribute('some', 'value')} />.
6. Would this behaviour be applied to custom elements only and how would this be detected if so?

Something like the following might be a little bit more robust:

Object.keys(props).forEach(name => {
  if (name in element) {
    // You might also need to ensure that it's a custom element because of point 1.
    element[name] = props[name];
  } else {
    doWhatReactNormallyDoesWithAttributes();
  }
});

Brainstorming just in case. Overall, I tend to agree with you that it'd be fine for React to just do Object.assign(). It seems like there are ways for the consumer to get around any potential design problems with the component they'd be using.

Maybe there is still hope to change the Web Components ecosystem to prefer that - and indeed React promoting that style would perhaps help.

I sure hope so. I'm trying to and I know the Polymer team is trying to, as well. I think if React did do this, that it'd be a massive help, too.

[justinfagnani]

I'd like it better if we could just pass through all props to element properties but it seems like that ship has sailed since most web components aren't designed to handle properties properly. A massive loss to the community IMO.

I'm not sure what exactly you're referring to, but with Polymer we'd definitely prefer setting properties to setting attributes. Which web components don't handle properties and in what way?

[robdodson]

@sebmarkbage I think we can definitely encourage folks to write components that support the Object.assign approach you mentioned above. As @treshugart mentioned, I spoke about doing this in my Polymer Summit talk based on our previous twitter discussion. Having easy event support in React would also be great.

[robdodson]

Talk is here: https://www.youtube.com/shared?ci=256yfQG-abU

I also mentioned the need to dispatch events for state changes so libraries like React can revert those changes (similar to the way React handles the native input checkbook element)

[nhunzaker]

events up, props down

Yes. I think there would be benefits outside of web components too. I wonder if we'd see libraries rely less on the context API when they could just emit a custom event.

I don't see a problem doing this for the heuristic if (typeof props[propName] === 'function') element.addEventListener(propName, props[propName], false).

@sebmarkbage Unless you know if any current work here, I'd be happen to stencil something out.

[sebmarkbage]

@nhunzaker Well I think that what is being discussed here would be an alternate strategy.

We would not support addEventListener('click', fn). We would instead support element.onclick = fn;

[staltz]

Yeah I think I'm ok with the idea of Object.assign(element, props) and element.onflipend = fn. Just to understand why you proposed this, is it just to avoid translating onFoo to foo? Or are there more reasons?

[sebmarkbage]

A problem with properties, attributes, events and children is that you have to know which one to use so you end up with heuristics or explicit namespaces. I don't think explicit namespaces is very ergonomic.

Properties are more powerful than attributes because:

• Properties can have rich data types. E.g. boolean for checked or complex objects like style. Typed CSSOM will let us have specific data types for individual style properties too.
• In HTML, properties can always control and represent the current visible state of an element. Whenever they diverge, properties is the source of truth - like in the case of HTMLInputElement's value. The only exception is that you can set progress into an indeterminate state - which is just an oversight. As @treshugart pointed out the exception to this is mostly random things added carelessly outside of the normal process - such as RDF or custom elements built by third parties. SVG does have some properties that can't be set in the normal way, but usually you can do that using style instead which are just nested normal properties. These are edge cases that can be dealt with by a library like React DOM that knows about these.
• Properties have the benefit that they can be reflected over. You can't detect if an attribute or event is accepted or not because they're all accepted so you can't add runtime warnings for wrong attribute names. You can also use that for workarounds, e.g. fallback to something else if a property is not available.

So if we only had one, I'd prefer it to be properties.

That leaves events. If we use a heuristic, that affects performance negatively since we have to create mappings for it at runtime. It also means that we're claiming a whole namespace. It means that custom elements can't provide an onFoo property if they wanted to. For example, with infinite scrolls there's a pattern like onCreateRow that isn't just a simple a event but a callback that's invoked to create a row for a particular index.

I think that would be unfortunate to claim a whole namespace prefix or type when the precedence of element.onclick = fn is a much simpler model.

Of course, that will still leave us "children" as special but that's kind of a unique property of React that children of components can be any type of value so we'll have to concede that one constrained special case.

[robdodson]

I took a stab at implementing the model discussed above. @sebmarkbage can you let me know if this matches your thinking?

class XCheckbox extends HTMLElement {
  connectedCallback() {
    this.addEventListener('click', this._onclick);
  }
  disconnectedCallback() {
    this.removeEventListener('click', this._onclick);
  }
  _onclick(e) {
    this.checked = !this.checked;
    this.dispatchEvent(new CustomEvent('checkchanged', {
      detail: { checked: this.checked }, bubbles: false
    }));
  }
  set oncheckchanged(fn) {
    this.removeEventListener('checkchanged', this._oncheckchanged);
    this._oncheckchanged = fn;
    this.addEventListener('checkchanged', this._oncheckchanged);
  }
  get oncheckchanged() {
    return this._oncheckchanged;
  }
  set checked(value) {
    this._checked = value;
    value ? this.setAttribute('checked', '') : this.removeAttribute('checked');
  }
  get checked() {
    return this._checked;
  }
}
customElements.define('x-checkbox', XCheckbox);

const props = {
  checked: true,
  oncheckchanged: function(e) {
    console.log('oncheckchanged called with', e);
  }
};
const customCheckbox = document.createElement('x-checkbox');
Object.assign(customCheckbox, props);
document.body.appendChild(customCheckbox);

One concern is that element authors have to opt-in to defining a setter to expose a handler for every event that they dispatch. That may end up bloating the elements, especially if they have a variety of events that they expose. Having React do element.addEventListener(propName, props[propName], false) might make element author's lives a bit easier. Just speaking personally, knowing the trade off between an event name heuristic and having to define setters for everything, I'd choose the heuristic.