This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-07
Channels
- # bangalore-clj (1)
- # beginners (255)
- # boot (29)
- # cider (16)
- # cljs-dev (13)
- # cljsrn (6)
- # clojure (200)
- # clojure-berlin (1)
- # clojure-dev (13)
- # clojure-dusseldorf (6)
- # clojure-greece (1)
- # clojure-india (1)
- # clojure-italy (1)
- # clojure-russia (33)
- # clojure-spec (28)
- # clojure-uk (27)
- # clojurescript (47)
- # cursive (32)
- # data-science (3)
- # datascript (1)
- # datomic (40)
- # emacs (39)
- # events (4)
- # fulcro (55)
- # graphql (16)
- # immutant (2)
- # luminus (2)
- # lumo (5)
- # off-topic (142)
- # onyx (50)
- # portkey (1)
- # re-frame (45)
- # reagent (80)
- # remote-jobs (2)
- # ring-swagger (3)
- # rum (9)
- # schema (3)
- # shadow-cljs (184)
- # spacemacs (3)
- # test-check (4)
- # unrepl (2)
- # yada (5)
@ericnormand Thanks, that’s a good suggestion! re-frame-async-flow-fx has been on my radar but I haven’t yet looked into the details, but it’s worth doing. Thus far, I’d been resisting adding a library (hoping to just find some conventions) but maybe it’s time to look again at a library solution.
metosin got some nice re-frame utils too https://github.com/metosin/re-fill
Just noticed that re-frame-trace pulls in D3, cc: @saskia
isn't this a pretty large dependency?
@pesterhazy Do you find that to be an issue at dev time?
good question
I just ran into an issue with applying simple optimizations:
SEVERE: file:/Users/me/.m2/repository/cljsjs/d3/4.2.2-0/d3-4.2.2-0.jar!/cljsjs/d3/common/d3.ext.js:670: ERROR - Object literal contains illegal duplicate key "scaleSequential", disallowed in strict mode
admittedly this was because re-frame-trace was (erroneously) being included in prod builds
I think there were some thoughts about removing the subvis tab and D3 as dependency, as it is still in an experimental stage
it's not a huge problem, but I personally try to keep these kinds of dependencies as lightweight as possible (even dev dependencies)
btw I've been enjoying the new re-frame-trace !
@pesterhazy the most recent version of re-frame-trace (maybe it’s still only on master) has fixed that, it was an externs error in an older cljsjs version of D3
has anyone else noticed their re-frisk css just disappear?
As far as I can make out, bootswatch changed their URL @andre from
to
or
thank you again @U051H1KL1 🍻
@bbrinck the Day8 libs are usually pretty solid. also, before re-frame for multi-step things, core.async has always been helpful
@ericnormand Thanks for the ideas! I’m not particularly worried about the quality of the library. Rather, I’m just weighing the tradeoffs of adding another declarative layer (which must be understood and learned) vs. just writing the code myself, especially in the case where we only have two steps, so rules+state-machine may be more power than we need.
OTOH, it’s good to understand re-frame-async-flow-fx because it might be a good fit now and certainly it’s a candidate if our sequences get more complicated. Thanks!
@bbrinck another option is to use alet
from funcool/promesa (or funcool/cats if you are already using that) - it's outside the re-frame flow, but it's great for programatically specifying async flows
@mccraigmccraig where do you put your alets
@mccraigmccraig I’m wondering the same thing. Would you do this within a single re-frame effect?
Here are two approaches I’ve seen (apologies for any syntax errors, it’s just an example for illustration, so I haven’t run it)
As you can see, in one approach, we use a single re-frame effect. In the other, we break it out into two different effects. I’m wondering if anyone has experience with either approach.
I will also be investigating using re-frame-async-flow-fx as an alternative to either of the above, but I’m still curious about the tradeoffs of single vs multi effects in these relatively simple 2-step examples
in a single effect @U051H1KL1 , with a dispatch to return values to re-frame
@mccraigmccraig Thanks, that makes sense
let-flow
might be useful too presumably binding subscription to the flow? https://github.com/ztellman/manifold/blob/master/docs/deferred.md
let-flow
is clj only though
ooo nice, i hadn't seen that
I remember reading that it’s best to keep effect handlers a simple as possible (by moving any complexity into the pure event handler). I recently saw a good presentation that also advocated keeping reagent components simple (and pushing the complexity to subscriptions), which makes sense. I wonder if there’s a corollary here about keeping event params simple i.e. don’t do much pre-processing before you dispatch an event, move that complexity to the pure event handler as well
Anyone have experience with moving complexity from dispatch call to event handler (or vice versa)?
@bbrinck absolutely, I recommend doing as much as is sensible in the event handler, rather than at the call site
Are there any examples of larger scale re-frame apps? I’m interested to see how complex components are managed and if reg-sub and re-event- are reused or created every time a component is reused.
Thanks, I’ll take a look now