[maxthegeek1]

I disagree strongly. I think we'll see more and more developers moving towards Elm's model for exactly the reason you've mentioned. It's simple.

Not only that but having a single source of truth for your app's state, using only pure functions and non-stateful components to render your view allows you to do things like:

  - build a time traveling debugger

  - serialize your app's state and store it in your session so that users see exactly the same view when they log back in

  - trivially do server side rendering

I have yet to be convinced that stateful react/virtual-dom components and/or GraphQL add any tangible benefits in the majority of cases.

[lsdafjklsd]

Sorry if it wasn't apparent but I agree / advocate strongly for what you mention, and we use that model at my company. If you look at how Om evolved though, it started out with that simple model of passing the state object down to child components. Then cursors were implemented to make it easier to pass around parts of your global state without having components needing to know everything.

GraphQL doesn't mean moving to stateful components, it's just a nicer way to have a singleton data store because instead of chunking and passing a map around, components can declare which data they need. In that system components are still read only, and dispatch to external pure functions.

David Nolen does a great job talking about the trade offs and the evolution of everything in this talk https://www.youtube.com/watch?v=ByNs9TG30E8& I highly recommend it!