React and WebComponents

I see a lot of questions, blog posts and discussions around React and WebComponents, but none of them are actually an official statement from Facebook that could clarify whether or not React will going to implement WebComponents W3C specs in the future.

There are also quite a few GitHub Issues around this subject, like “Enable rendering into shadow roots” #1167, “Allow rendering into a document fragment” #840, “Track upcoming DOM technology upgrades” #2836, “Proof of concept: Shadow DOM support” #1877, “Support for custom DOM elements & attributes” #2746, “Templates?” #2286, “Add naive custom element support” #1249, “Add support in the future for custom elements” #1214 etc.

Nevertheless there are some open-source projects that allows React to be WebComponents-aware, like https://github.com/Wildhoney/Maple.js, https://github.com/wix/react-templates or https://github.com/PixelsCommander/ReactiveElements

As for WebComponents, it seems that the reconciliation between HTML Imports and ES6 Modules is inevitable, thus the HTML Imports part of the spec might need to change in order to be widely accepted among the open-source community and browser vendors https://bugzilla.mozilla.org/show_bug.cgi?id=877072 Until then, wrapping components and importing them as ES6 Modules is as good as including them in HTML pages and importing them with <link rel="import" />

The Custom Elements are more or less about defining new markup that you can interact in the same way as with native HTML elements, allowing you to extend existing native HTML elements and giving you some lifecycle methods. This is already possible with React and JSX, even though JSX’s XHTML-like syntax transpiles to JavaScript which ultimately becomes HTML through the Virtual DOM.

Shadow DOM is hard and in some cases even impossible to be polyfilled. This is the reason why Polymer is using Shady DOM https://www.polymer-project.org/1.0/articles/shadydom.html With the current browser support http://caniuse.com/#feat=shadowdom, adopting BEM conventions or even inline styles backed by JavaScript objects, which is what React is doing, remains a viable alternative but still is different from Shadow DOM.

Templates are really pointless without data binding. Two-way data binding is slow because the Object.observe polyfill (https://github.com/Polymer/observe-js) is slow. Also, two-way data binding is about code complexity and the fact that the more dependencies you have between between components, the bigger the complexity grows, as opposed to unidirectional data flow. React’s one-way data flow with immutable data structures has the potential to scale and be highly performant, especially if we think about large-scale applications and complex interactions between thousands of entities.

Even though the open-source community is looking both at React and WebComponents, in the end the developer experience is what matters most and drives adoption. No doubt standards are having their own place in this.

Therefore, my question is: what is React’s strategy for WebComponents?

@sebmarkbage any thoughts?

[sebmarkbage]

The primary component strategy for React will never be Web Components. It runs counter to functional paradigm of React by providing a mostly imperative API. It doesn’t help solve any of the problems we have building apps. In fact it makes it more difficult. It does little to nothing to solve the integration problem with other libraries. It doesn’t have a solid story around server-side rendering. It doesn’t help at all for cross-platform environments like React Native because the overhead of implementing a full DOM spec that we’re then going to have to side-step anyway.

It is unlikely that Facebook will ever use Web Components at scale and therefore unlikely it will be a priority for us. There has been a lot of excitement about Web Components as an interop layer. Mostly unwarranted IMO.

However, we like to support our users so we’ve made a best effort to try to support interop in the edges. We would like to support as much as possible without compromising the API and vision of React itself.

It has turned out that the spec is incomplete with regard to things like event delegation and there are still major changes being pushed from various sides, such as Mozilla. What was in Polymer/Chrome is not the final incarnation so we’ve had to revert some of the support that we already added (e.g. support for event handling in shadow trees).

In terms of strategy, we’ll go forward with as if it didn’t exist and try to improve interop at the React or React-like component layer instead. I’ve talked with members of other popular UI frameworks and they seem to feel the same. In fact, we probably have a better chance at implementing solid interop in user land.

[treshugart]

Related, we have a wrapper that can convert a web component into a React component: https://github.com/webcomponents/react-integration so you can use a web component as a first-class citizen within React components.