It doesn’t really relate to the Flux architecture directly. You could probably use something like Flux in addition to Omniscient. In the same way that Flux encourages a continuous loop with data from the top, Omniscient has a single direction of data flow. But you could easily use dispatchers with stores to communicate in the other direction, like with the Flux architecture.
Omniscient is a very small library, only providing a “smarter” shouldComponentUpdate for use with Immutable.js cursors and a wrapper for easily creating components with renderers and composability with mixins in focus. See the documentation to see more about Omniscients rationale: http://omniscientjs.github.io/documentation/
Yeah. The main part here is using immutable structures from the top, having cursors to sub-components with information about only the relevant data for that component, and have a way of re-start the loop when a data has changed.
Sometimes, though, we need to communicate to a parent or ancestor (e.g. to delete an item in a list). For that we can simply use events (or possibly callbacks) passed as statics to components. (Statics are values that doesn't trigger a component update when changed.)
Comments
How does this relates to the Flux architecture?
It doesn’t really relate to the Flux architecture directly. You could probably use something like Flux in addition to Omniscient. In the same way that Flux encourages a continuous loop with data from the top, Omniscient has a single direction of data flow. But you could easily use dispatchers with stores to communicate in the other direction, like with the Flux architecture.
Omniscient is a very small library, only providing a “smarter” shouldComponentUpdate for use with Immutable.js cursors and a wrapper for easily creating components with renderers and composability with mixins in focus. See the documentation to see more about Omniscients rationale: http://omniscientjs.github.io/documentation/
That was what I was expecting to hear.
We really don't need Flux (the listen-for-and-query-the-stores part of it) if we manage to wrap every data into a context with cursors, right?
Yeah. The main part here is using immutable structures from the top, having cursors to sub-components with information about only the relevant data for that component, and have a way of re-start the loop when a data has changed.
Sometimes, though, we need to communicate to a parent or ancestor (e.g. to delete an item in a list). For that we can simply use events (or possibly callbacks) passed as statics to components. (Statics are values that doesn't trigger a component update when changed.)