Hacker News new | past | comments | ask | show | jobs | submit login

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.)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: