For this part of the docs https://day8.github.io/re-frame/on-stable-dom-handlers/#the-technique , I think you should also mention partial from reagent, which creates an IFn that can be compared
piggy backing on @dannyfreeman comment above (https://clojurians.slack.com/archives/C073DKH9P/p1600549561008300) - 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
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?
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
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
Maybe this: https://twitter.com/nathanmarz/status/879722740776939520 ( I know Mike likes that tweet, he put it into the re-frame docs )
For re-frame, that would probably mean using interceptors to enrich the data you put into the db with derived state
But it isn't without drawbacks, so I'm interested to hear if someone has a better answer