This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-04
Channels
- # beginners (56)
- # boot (11)
- # cider (1)
- # clojure (112)
- # clojure-denmark (4)
- # clojure-russia (7)
- # clojurescript (45)
- # component (1)
- # cursive (19)
- # data-science (10)
- # datacrypt (1)
- # datascript (22)
- # datomic (3)
- # defnpodcast (2)
- # emacs (4)
- # fulcro (26)
- # hoplon (21)
- # jobs-discuss (5)
- # klipse (5)
- # onyx (8)
- # portkey (1)
- # re-frame (8)
- # reagent (17)
- # ring (7)
- # shadow-cljs (14)
- # spacemacs (9)
- # vim (4)
Why is re-frame-async-flow-fx
so focused on booting? There's doesn't seem anything about it which is particularly limited to boot sequences.
I'm primarily interested in using it to coordinate sequences once running; is there anything I need to look out for when not using this for booting?
@jeaye only cause we wrote it with booting as a core use case. You’re right that it can be used generally, I don’t think there’s anything that’s problematic in other uses
@danielcompton Good to know, thanks.
@Jeaye one of the things to watch out for with async flow fz outside of a boot context is scoping. Reframe async flows are global - they will react to any event of the given event keyword which can be a problem if two flows that depend on the same event occur concurrently. In that case you need to provide some kind of id to differentiate between them. This is a possible gotcha if you are used to promises or core asybc where the events aren't so 'global'
@danieleneal Thanks. That shouldn't be an issue for me and I've read about the :id
and agree it'd be good to specify for each of my flows, since I plan to have multiple going at any given time.