> The intended guarantee is that Redux eventual...
# reduxa
andreworobator
08/28/2019, 5:24 PMThe intended guarantee is that Redux eventually calls all subscribers with the most recent state available, but not that it always calls each subscriber for each action. The store state is available in the subscriber simply by calling store.getState()This explanation is more about disallowing the action in the subscriber which i totally get and support. but having the most recent state in the subscriber could be easily solved with
(State) -> Unit🤔 1
p
Patrick Jackson
08/28/2019, 6:25 PMLooks like there is/was interest in changing this in redux. check out the thread https://github.com/reduxjs/redux/issues/1707
last comment is Dan Abramov
r
Robert Jaros
08/28/2019, 6:28 PMI think there is no point in keeping this similarity to JS redux. To have the state parameter would be just better solution.
a
andreworobator
08/28/2019, 6:30 PMThis has been discussed before: #303. subscribe() and getState() are orthogonal on purpose so if you “override” one in a store enhancer, you don’t need to override the other.
In any case, having just the new state is not very useful. You’ll probably want the previous state too. And not just the previous state—probably a specific part you care about. At which point you might as well write your own helper to do this.
See #303 (comment) for more details.From https://github.com/reduxjs/redux/issues/1513 This is the argument for keeping them separate, but I don't know enough about StoreEnhancers atm
andreworobator
08/28/2019, 6:34 PMThe people who made ReduxJs aren't dumb. They kept it separate for a reason, so I'd like to fully understand their reasoning before departing from their decisions
đź’Ż 1
p
patjackson52
08/28/2019, 7:17 PMAgree with that. Will continue to look at this going forward. I don't think it is a big difference for the client code either way, and I'm kind of indifferent. I do want to explore reduxkotlin + react before changing any type definitions.