This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-18
Channels
- # aleph (4)
- # announcements (2)
- # babashka (48)
- # beginners (59)
- # calva (5)
- # cider (14)
- # clj-kondo (4)
- # cljs-dev (3)
- # clojure (77)
- # clojure-europe (6)
- # clojure-italy (6)
- # clojure-nl (5)
- # clojure-spec (4)
- # clojure-uk (67)
- # clojurescript (19)
- # clr (3)
- # cursive (7)
- # datomic (36)
- # duct (33)
- # events (3)
- # figwheel (1)
- # fulcro (4)
- # funcool (2)
- # graalvm (3)
- # jobs (1)
- # joker (25)
- # kaocha (1)
- # leiningen (45)
- # malli (17)
- # off-topic (103)
- # quil (1)
- # re-frame (16)
- # reitit (1)
- # rewrite-clj (27)
- # shadow-cljs (39)
- # spacemacs (3)
- # sql (11)
- # tools-deps (14)
- # vim (41)
Has anyone used Apollo with reframe?
on my last project, I used apollo alongside re-frame. apollo dealt with fetching data and re-frame dealt with UI state
Do you know of any code references publicly available? I think it’s pretty straight forward but would love to see how someone else did it.
the idea is to wrap the apollo-client
observable in a Reaction and then return that
Awesome. Thank you. I’ll take a look sometime tomorrow. I’m seeing if I can convince the start up I am on to switch to cljs. Key things I need is Material design and Apollo and the switch will likely be pretty easy.
Wondering if anyone here might have any guidance/tips on dynamic subscriptions. I have tried to stay away from them for a while after reading in the docs that they are bad. It isn't clear now though if that's the case. Best I can see now you can have dynamic subs which take another sub as an arg? What about a dynamic sub that takes a none re-frame/reagent atom/reaction?
@jon693 I haven't had any problems with them, and use them all the time. I'd stick to just passing paths though, not instances of subscriptions or atoms. It is hard to give good advice on it, because you kind of have to make guesses about what parts of the app-state/subscription structure graph are unlikely to change. (The ones that won't are the ones that are unlikely to cause problems when referred to in dynamic subscriptions).
then when I want to render some indication of that I'm on the fence about passing the subscribed set down the tree and just check if each id is in it or create a sub where I pass the id and do that in the rf handler
Oh, I guessed wrong - I thought you were worried about the problems dynamic subs might cause if you overuse them and then want to refactor. For performance, I've had a similar situation to what you are describing (I think). I made a dynamic subscription (A) that used another subscription (B), where B computed something (like a map) that made it so A was trivial to compute. Still a good amount of subs, but each was quick. Not sure if that is applicable in your case, hard to say without knowing what is involved.