This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-27
Channels
- # adventofcode (1)
- # announcements (4)
- # beginners (120)
- # calva (5)
- # cider (12)
- # clara (3)
- # cljdoc (48)
- # cljs-dev (33)
- # cljsrn (4)
- # clojure (124)
- # clojure-dev (43)
- # clojure-europe (2)
- # clojure-italy (168)
- # clojure-nl (2)
- # clojure-spec (7)
- # clojure-uk (79)
- # clojurescript (50)
- # core-logic (6)
- # cursive (12)
- # datascript (1)
- # datomic (8)
- # devcards (2)
- # emacs (5)
- # events (2)
- # figwheel-main (6)
- # fulcro (18)
- # graphql (42)
- # hyperfiddle (3)
- # jobs (1)
- # luminus (2)
- # nrepl (5)
- # off-topic (59)
- # onyx (5)
- # parinfer (2)
- # pathom (10)
- # pedestal (2)
- # portkey (3)
- # re-frame (24)
- # reagent (6)
- # reitit (54)
- # remote-jobs (1)
- # ring (5)
- # shadow-cljs (75)
- # spacemacs (35)
- # sql (22)
- # tools-deps (16)
- # unrepl (10)
I'm open to variations on the theme, for example having the subscription fire events on creation and disposing, and letting those events control the polling. but that feels like "semantics"; it's essentially the same technique.
@mikethompson I'm able to give this question a chew now if you're around. not sure what time zone you're in and so on. (EST here)
I think usually the important thing for correctness is that the "startup" and "cleanup" code can be collocated
What are the tradeoffs b/w re-frame
and fulcro
? Which things are more decomplected here, and there?
re-frame separates data acquisition from rendering using subscriptions. However, data acquisition can fail (data has not yet arrived from backend, query to backend failed completely, ...). Is there a common pattern to handle these cases? "if subscriptions return nil, render this view, else feed the data from the subscriptions into that other view"?
That’s basically what I do: make a div
with a spinner or some other indicator that only displays when the subscription value is nil.
yeah, loads of my views are (if @the-sub [:div.real-view ...] [spinner])
What do you do if the query eventually fails? Do you have another (if @error [display-error] [spinner])
in there?
sometimes (when @error-sub [...])
depends on how the errors are to be surfaced.
I seem to have discovered one potential problem with the scheme we were discussing yesterday, of having subs drive the fetching of data.
and that is if multiple other subscriptions depend on the stateful one, it's sensitive about whether it's being run several times or just once.
@braden.shepherdson I enhanced the code by @oliy to store nil
in the target key, so that (if-not (contains? target-key) (... ::re-graph/subscribe ...) ...)
will not trigger anymore once the first subscription request is sent.
So there will not be any unnecessary network requests. I think re-graph would already discard the additional subscription requests, if it detects that they are duplicates of existing requests, so technically this is not necessary for correctness.
so, for some reason it looks that my events.cljs file is not running at startup and my event handlers are not being registered. What is the most commom cause for this?
neglecting to :require
the events, even though you don't call things in that file.
someone has to require them.
(if you prefer using ::namespaced-keywords
then that forces you to import your events and subs so you can ::subs/some-value
and such)
i think i deleted the requires because of the linter telling me that the imports were not being used
@mikethompson ping re: our discussion, if you've got time now.