Relay-like GraphQL integration

[charypar]

I'd like to start this as I feel like it'll take some time to come up with the right solution. I think we can do something similar to what Relay is advertised to do and put the results of the query in the app-state cursor, possibly a new top level key.

If my thinking about this is right, what we need to do is extend certain components with lifecycle hooks and collect their GraphQL fragments as they come into the DOM, fetching data as the full query changes. We might even be able to use the cursor to store the queries and observe the changes, collecting and fetching the query.

A good start would probably be collecting what we know about Relay and at the same time thinking about what we'd feel is the best way of doing the component data dependencies.

[robbiemccorkell]

I watched David Nolan's talk earlier, and I didn't understand how he could get rid of cursors entirely. All of his examples involved state derived from server data, but he didn't show how you could store simple UI state without a global data store and cursors.

If we adopted relay architecture, do you think we could get rid of cursors entirely?

[charypar]

I have yet to watch the entire thing, but from the beginning it didn't seem like he would talk about cursor replacement at all. Is Om Next public yet?

[JoeStanton]

He says so near the middle of the talk - and yes Om Next is here: https://github.com/omcljs/om. Think it's been merged to the master branch recently.

[charypar]

I finally watched the whole thing and I think the answer is actually yes, @robbiemccorkell. It's still a bit vague in my head, but this is how I imagine it: Once you describe what your component wants from the data tree, you can do all of the things cursors do without needing them. Ignore all the things about querying an API, that same concept works locally with a central state store.

It's doing the same thing cursors do, just explicitly and declaratively - rather then doing all your .gets at runtime, you declare the paths ahead of time. It's a sort of an inversion of control for data. And then you can somehow (imagine I wave my hands a lot here) mutate them too and the central state gets updated. Best thing is your component work with plain data and you can also use the declared dependencies to fetch parts of it from wherever (over GraphQL for instance).

[robbiemccorkell]

So are you thinking that all components will request their data in a graphQL way, but that data might be a mix of server provided data, and general UI state data. So I guess when you resolve the collated graphQL schema, you make the decision there as to where the data comes from. Either straight from the local data blob with a default value if one exists for local UI state, or straight from the same local data blob with a server request if the data doesn't exist (or the cache has expired) for server provided data.

[charypar]

I'm thinking fetching from server and putting stuff into the local store is a secondary concern, but yes, you could use the declared dependencies of the current render cycle to fetch stuff from somewhere and put it into the central store.

It may even end up that state observers will basically be like components, just without any rendering, i.e. they will also declare their data dependencies.

But all this is still very blurry for me, need to properly think about it :)