This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-13
Channels
- # aleph (1)
- # beginners (105)
- # boot (6)
- # cider (9)
- # cljs-dev (61)
- # cljsrn (59)
- # clojure (132)
- # clojure-germany (1)
- # clojure-italy (6)
- # clojure-russia (18)
- # clojure-spec (1)
- # clojure-uk (58)
- # clojurescript (56)
- # core-async (1)
- # cursive (17)
- # datomic (20)
- # docs (1)
- # duct (5)
- # editors (1)
- # emacs (7)
- # events (2)
- # figwheel (7)
- # fulcro (30)
- # graphql (8)
- # jobs (3)
- # leiningen (23)
- # luminus (14)
- # mount (6)
- # off-topic (41)
- # onyx (14)
- # protorepl (2)
- # re-frame (7)
- # reagent (32)
- # shadow-cljs (236)
- # tools-deps (92)
- # unrepl (8)
- # vim (60)
- # yada (1)
@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 https://github.com/vimsical/subgraph 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: https://github.com/oliyh/re-graph 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