Closed egli closed 2 years ago
coeffects aren't as complicated as they sound, but on the other hand I don't think using subscriptions inside event handlers is necessarily a problem. re-frame is quite opinionated on these things because that's what re-frame is, a set of opinions.
What you can do is split the subscriptions into a function that takes a db, and the actual subscription, so you can call the function elsewhere, if that makes sense for these subscriptions.
I think theoretically there might be a possibilty of inconsistencies, where the values you get from these subscriptions are based on a different db instance than the one your event handler sees, but in practice given that JavaScript is single threaded I don't actually think it's a problem.
Coeffects are indeed not that complicated, but according to the docs they are for things other than the app state (such as localstorage). Another down side of coeffects is that we'd define the path to the data in the app state twice still: first in the subscription and second in the coeffect which grabs the data out of the app db and adds it to the coeffects.
The other idea of splitting the subscription into an accessor function and the actual subscription seems more simple and keeps the path info really in one place.
According to this re-frame FAQ there shouldn't be any subscriptions inside event handlers. The present code base contains numerous such subscriptions.
I can see that a subscription is not needed here as we are not reacting to an event. Instead they are more used as getters into the global db and I was under the impression that this would be better than reaching into the global db with
(get-in db [:foo :bar :baz])
.An alternative would be to define functions that abstract the path into the db away but from reading Day8/re-frame#255 I get the impression that this is also not kosher:
They recommend to use coeffects but that seems pretty complicated for such a simple problem,