Re:Application Architecture with React: Rethinking Flux
by drcode on Monday September 14, 2015 @04:05PM
(#10217155)
> What does this have to do with databases and declarative view objects?
Well, you can think of a cursor as a query into the state, with support for dependency tracking. I think your confusion is that you're asking "How is what you're describing like a cursor?" when I'm saying "Om Next is going to replace cursors with something very different."
...so you're right, it isn't the same as a cursor anymore, because swannodette is moving away from the cursor paradigm into more of a "querying" approach.
A cursor is something that implements the atom interface, and refine [1]. What does this have to do with databases and declarative view objects?
It would make sense if GraphQL/Relay were used to sync backend state to browser state, and then cursors are used to sync browser state to a view, but here, cursors are still part of the picture! Or is it that components will directly sync with the server, so no mechanism to sync browser-state to a view is necessary? What about application/UI state that doesn't exist on a server?
[1] From the OM wiki:
"In Om, you keep all your application state in a single atom (the root atom). Components, however, generally do not care about the entire scope of the application state, but focus on specific parts of it.
"Cursors are Om's way to manage a component's focus on just the state data that it needs to operate. Cursors split one big mutable atom into smaller sub-atoms that remain in-sync with the state held in the root atom. Cursors keep a path to the data within the root atom that the component needs to deal with. Sub-cursors are produced by refining the path."