isak 2020-09-22T20:05:28.012800Z

For this part of the docs , I think you should also mention partial from reagent, which creates an IFn that can be compared


piggy backing on @dannyfreeman comment above ( - is there an architectural principle that can help us avoid being in this situation in the first place of wanting subscription logic from within an event?


i'm mostly concerned about having multiple places in the app that independently know how to do what a given subscription does, that sounds like a maintenance nightmare

restenb 2020-09-23T08:51:14.000500Z

the "need" to use subs inside of events has always seemed strange to me. what's wrong with just passing the result of those subscriptions as straight parameters to the event e.g. from the view?

restenb 2020-09-23T08:53:09.000700Z

if the subscription is just returning some calculation based on state, that calculation can easily be turned into a single reusable function that serve both purposes

restenb 2020-09-23T08:54:51.000900Z

i don't think i've ever had a case where either the event dispatcher (typically a view) doesn't know everything the event handler needs, or the event handler can't derive it internally from app-db state


extracting the sub's work into a function seems like a straightforward approach to me

isak 2020-09-22T22:06:20.015500Z

Maybe this: ( I know Mike likes that tweet, he put it into the re-frame docs )

isak 2020-09-22T22:07:09.015800Z

For re-frame, that would probably mean using interceptors to enrich the data you put into the db with derived state

isak 2020-09-22T22:08:07.016Z

But it isn't without drawbacks, so I'm interested to hear if someone has a better answer