From using the Flux architecture on fairly big projects, we generally follow the rule that any re-usable component (such as a datepicker, custom select box, modal etc) can internally do whatever they want with regards to state and data binding. These components interact with their parents using callbacks, it's these callbacks that interact with Flux. This feels fairly compatible with Web Components.

For example, say you have a custom select box. You don't want to fire a flux action when a user clicks on an option. You want that click to be handled by your select component, and be interpreted as an intent to change the value. Your select component then triggers its onChange (or onSelect, doesn't really matter) callback if it has one. The parent of the select component is then responsible for saying "actually the rest of the page should know about this value change, i'll trigger a flux action".

The end result is that your reusable widgets/components have no knowledge of flux, but the implementation of a particular page or piece of functionality does.

I started on a project to port the paper elements from material design to react components (https://github.com/OlavHN/react-paper), but the paper elements I ported all seemed really stateless. More like high level input elements. Now I'm hoping that they can be used directly by mapping custom element attributes to react props or maybe they would work with a small wrapper. Needs more experimentation ..