Fork me on GitHub
#re-frame
<
2020-09-22
>
isak20:09:28

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

Michael Stokley20:09:32

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?

thinking-face 3
Michael Stokley20:09:28

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

isak22:09:20

Maybe this: https://twitter.com/nathanmarz/status/879722740776939520 ( I know Mike likes that tweet, he put it into the re-frame docs )

isak22:09:09

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

isak22:09:07

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

restenb08:09:14

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?

restenb08:09:09

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

👍 9
restenb08:09:51

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

Michael Stokley13:09:36

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