> Trying to compare and contrast React with WebComponents inevitably results in specious conclusions, because the two libraries are built to solve different problems. WebComponents provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary; engineers can mix-and-match the technologies. As a developer, you are free to use React in your WebComponents, or to use WebComponents in React, or both.
"Note:
The programming models of the two component systems (web components vs. react components) differ in that web components often expose an imperative API (for instance, a video web component might expose play() and pause() functions). To the extent that web components are declarative functions of their attributes, they should work, but to access the imperative APIs of a web component, you will need to attach a ref to the component and interact with the DOM node directly. If you are using third-party web components, the recommended solution is to write a React component that behaves as a wrapper for your web component.
At this time, events emitted by a web component may not properly propagate through a React render tree. You will need to manually attach event handlers to handle these events within your React components."
It's worse than that, though. Web components that maintain their own state can be randomly squashed by React's virtual-DOM diffing algorithm because of the way elements are held in memory. They are just not compatible, and the React Core team has made no apologies about not agreeing with the overall concept of Web Components.
What I struggle to understand is why you would need need to 'sync' the DOM with your data?
If you're dealing with atomic values, you don't need to diff or 'sync' data. In Polymer, when you update data on the frontend,
it sends a CRUD update request to the server, the relevant field is then updated in the database, then a realtime notification is sent out to all frontends which
are subscribed to changes on that specific field.
Multiple fields might belong to the same 'object' but each field is atomic and can be updated independently of the whole object (without having to diff the entire object each time).
This is much more efficient on both the client and server because diffing is expensive and incurs a high latency and bandwidth overhead when you scale out.
Diffing is useful for collaborative editing of unstructured text documents, but it is not needed for structured (or even semi-structured) data.
https://facebook.github.io/react/docs/webcomponents.html