4 ms·

> Om Next moves away from cursors and towards something closer to GraphQL/Relay queries. Can you elaborate, I watched the Om Next talk i think you're referenci

> Om Next moves away from cursors and towards something closer to GraphQL/Relay queries. Can you elaborate, I watched the Om Next talk i think you're referencing and recall David saying this, but I do not really understand why or what Cursors have to do with GraphQL/Relay as they are separate concerns. (Cursors are a way to update deeply nested data structures and don't do I/O, GraphQL and Relay are ways to coordinate/sync state from backend to frontend and involve I/O.

drcode 11y ago
Both cursors and Relay involve syncing a "database" to a declarative view object- In Om Next, there will be a new query language that maps the database to the views, so it can be used both for in-browser data (like cursors) and server data (like Relay). What makes Om Next special (or so is the hope, very little specifics are available yet, but the author that makes these claims has a stellar reputation) is that the query syntax gracefully handles component composition and removes a lot of the "magic" of maintaining reliable link with data residing on the server.
- dustingetz 11y ago
  > Both cursors and Relay involve syncing a "database" to a declarative view object 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."
  - masklinn 11y ago
    GraphQL/Relay are not fundamentally bound to server state, they can be used to map client application state (from the "big atom") to components as well.
  - drcode 11y ago
    > 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.

drcode 11y ago

Both cursors and Relay involve syncing a "database" to a declarative view object- In Om Next, there will be a new query language that maps the database to the views, so it can be used both for in-browser data (like cursors) and server data (like Relay). What makes Om Next special (or so is the hope, very little specifics are available yet, but the author that makes these claims has a stellar reputation) is that the query syntax gracefully handles component composition and removes a lot of the "magic" of maintaining reliable link with data residing on the server.

dustingetz 11y ago
> Both cursors and Relay involve syncing a "database" to a declarative view object 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."
- masklinn 11y ago
  GraphQL/Relay are not fundamentally bound to server state, they can be used to map client application state (from the "big atom") to components as well.
- drcode 11y ago
  > 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.