Fork me on GitHub
#re-frame
<
2017-11-07
>
bbrinck02:11:52

@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.

lovuikeng04:11:50

metosin got some nice re-frame utils too https://github.com/metosin/re-fill

pesterhazy10:11:18

Just noticed that re-frame-trace pulls in D3, cc: @saskia

pesterhazy10:11:41

isn't this a pretty large dependency?

curlyfry10:11:02

@pesterhazy Do you find that to be an issue at dev time?

curlyfry10:11:21

(just curious)

pesterhazy10:11:25

good question

pesterhazy10:11:11

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

pesterhazy10:11:59

admittedly this was because re-frame-trace was (erroneously) being included in prod builds

saskia10:11:55

I think there were some thoughts about removing the subvis tab and D3 as dependency, as it is still in an experimental stage

pesterhazy10:11:29

it's not a huge problem, but I personally try to keep these kinds of dependencies as lightweight as possible (even dev dependencies)

pesterhazy10:11:46

btw I've been enjoying the new re-frame-trace !

saskia10:11:20

cool, happy to hear that!

mhuebert12:11:13

@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

danielneal12:11:48

has anyone else noticed their re-frisk css just disappear?

danielneal12:11:08

As far as I can make out, bootswatch changed their URL @andre from to or

andre17:11:41

yeah it was not a good idea, i need to package all that stuff

andre18:11:16

fixed in 0.5.2

andre21:11:29

thank you again @U051H1KL1 🍻

ericnormand13:11:43

@bbrinck the Day8 libs are usually pretty solid. also, before re-frame for multi-step things, core.async has always been helpful

bbrinck14:11:27

@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.

bbrinck14:11:59

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!

mccraigmccraig14:11:57

@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

danielneal14:11:40

@mccraigmccraig where do you put your alets

bbrinck15:11:46

@mccraigmccraig I’m wondering the same thing. Would you do this within a single re-frame effect?

bbrinck15:11:21

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)

bbrinck15:11:54

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.

bbrinck15:11:26

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

mccraigmccraig17:11:28

in a single effect @U051H1KL1 , with a dispatch to return values to re-frame

bbrinck17:11:54

@mccraigmccraig Thanks, that makes sense

lovuikeng16:11:40

let-flow might be useful too presumably binding subscription to the flow? https://github.com/ztellman/manifold/blob/master/docs/deferred.md

mccraigmccraig17:11:02

let-flow is clj only though

mccraigmccraig10:11:16

ooo nice, i hadn't seen that

bbrinck17:11:25

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

bbrinck17:11:46

Anyone have experience with moving complexity from dispatch call to event handler (or vice versa)?

danielcompton23:11:35

@bbrinck absolutely, I recommend doing as much as is sensible in the event handler, rather than at the call site

caleb.macdonaldblack23:11:15

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.

caleb.macdonaldblack23:11:37

Thanks, I’ll take a look now