Fork me on GitHub

@brycecovert by "bad trade" I meant "bad tradeoff" . Collocating queries with views is nice, but the tradeoff is that the views become imperative.


I have a data structure that looks like that that I’m going to use subs to pull the values out of. Would people recommend a sub for each value? Or a sub for each group (return a map), and then destructure the values in view code?


@caleb.macdonaldblack I have similar data structures in my app and I’m using to convert JSON data from server API into entities, and to pull them out of app-db. I like the fact that subgraph stores the entities fully normalized and builds the object graphs upon retrieval.


Are there any examples of re-frame and graphql? Looking specifically for how to keep graphql client state/caching in re-frame store or at least if separate somehow subscribe to events


I know there's this: but I haven't used it myself


We're using graphql on the backend but making requests using http-fx and storing the results in the reframe db


I used re-graph, it works great, including subscriptions.