cmeeren
commented
7 years ago I think it makes perfect sense: The subscribers are interested in state updates, and are often registered as part of some UI init process, and would very much like to run the handler based on the current state without dispatching some fake event (which one couldn't depend on anyway - the store/reducers might not update the state or fire the event if nothing changes, and that would be just an implementation detail).
It won't break any clients because they must be prepared to handle updates immediately after subscribing. And it will always save you the trouble of dispatching fake actions to get the current state, which as described above wouldn't be reliable anyway.
Note that Redux.NET currently does this, too. Check the store constructor.
hey @cmeeren I was looking at your event implementation to try and do the same for redux.net and NRedux and I have a question. This line of the documentation https://github.com/cmeeren/yarni/blob/master/src/Yarni/IStore.cs#L19 says that the delegates are immediately called on subscription. Which I can see from https://github.com/cmeeren/yarni/blob/master/src/Yarni/Store.cs#L16. Is there a specific use case that you have for this that caused you to implement it this way? I am wondering if the same should be the case for redux.net. When looking at the src for redux don't see the handlers getting called at all until the first dispatch after they are subscribed. I'm just wondering why you did it this way and if you think it makes sense for redux.net to behave this way as well, or behave more like redux. Thanks!