Fork me on GitHub
#re-frame
<
2017-10-15
>
deg10:10:25

@mikethompson This dichotomy gets a little bit more complicated when data is coming in from external sources, e.g. databases. A subscription assembles these values nicely, for the sake of the views or other subscriptions. But, it is more awkward when an event has to model a user's intent where the behavior also depends on data from the external source. I'm still relatively new to re-frame, so I may have missed some better approaches. The best I've found so far is inject-sub from -utils for pulling data into events; or, for data that can be pushed, a subscription that copies the external values into the app db. Are there better approaches? Or, is my mindset that needs external data in an event fundamentally mis-using the re-frame philosophy?

deg10:10:31

Update: I just read https://github.com/Day8/re-frame/blob/master/docs/FAQs/UseASubscriptionInAnEventHandler.md carefully and understand better why my mindset ... mis-using ... re-frame philosophy. So, let me to reduce my question to: "is this a common enough pattern that the coeffect belongs in re-frame proper, rather than in -utils? Or is it an edge-case that I'm only seeing often because I'm mis-thinking something. And, if so, how can the docs be improved to help me"?

deg11:10:31

@lovuikeng Thanks! I actually had read that issue a few weeks back, but it makes much more sense now (guess I'm a bit older and wiser!) That discussion does a great job of pointing out subtleties and use-cases that I had totally missed. All that being said, it feels like the solution has ripened nicely. Maybe it's time to graduate it into the mainline re-frame code?