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.)
4 comments
[ 1.8 ms ] story [ 30.2 ms ] threadOmniscient 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/
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?
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.)