Fork me on GitHub
#re-frame
<
2017-11-04
>
jeaye04:11:56

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.

jeaye04:11:35

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?

danielcompton07:11:28

@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

jeaye18:11:48

@danielcompton Good to know, thanks.

danielneal21:11:14

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

jeaye22:11:56

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

jeaye22:11:31

One thing the docs don't mention is where the data is stored in the app-db if it's not explicitly customized.

jeaye22:11:12

Oh, I see. It's stored in an atom if db-path isn't specified.