Rather than passing parts of the model to the children (as you'd do with React props), you pass lenses into said parts.

It enables child components to read/write to the global store without knowing its structure. As long as it receives an appropriate (set of) lens(es) it is happy.

So, for example, if you have a list of strings, rather than passing the nth string to the nth component, you'd pass a lens to the nth string. The component can then not only read but also write to its slot.

Lenses can also be composed, so you can create them on the go as you'd pass sub-props to grand-children.

https://github.com/calmm-js/partial.lenses <= a comprehensive lens library

http://ramdajs.com/ also has lenses.

These libs are strongly influenced by the FP world. The underlying data structures are immutable, writing to a lens creates a new version of the store (as efficiently as possible, by recycling intact objects).

However, recently I discovered Halogen [0]. It is very similar to Elm Architecture, however, every component has its own _internal_ state, so you do not have to thread all state changes to the top-level component. It does this by existentially quantifying over the State [1].

Halogen is written in Purescript, which is a transpiler for javascript (yes transpiler, not compiler). Which means you basically get javascript semantics with a haskell typesystem + very good interop with JS, and no runtime system. The code purescript generates is actually readable. [2]

[0] https://github.com/slamdata/purescript-halogen/tree/master/d... [1] https://wiki.haskell.org/Existential_type [2] https://purescript.org/ [3] http://try.purescript.org

The idea is that you declare read/write optics than you then compose and reuse.

But on a web app, say, in how many places can you update a person's address?

Writing non generic code that update it in a non generic way (throw away code) is much less ceremony than defining an optic and only using it once.

[0] https://github.com/zrho/purescript-optic-ui