Bloc: Change the parameters of mapEventToState

[JohannesKlauss]

Is your feature request related to a problem? Please describe.
The Bloc class type signature as well as the onTransition method is <E, S>. But the mapEventToState parameters are (S, E).

Describe the solution you'd like
It would be more consistent if the mapEventToState method would follow the signature of the rest of the package and also have (E event, S state) instead of (S state, E event).

[felangel]

Hi @JohannesKlauss, thanks for the feedback.

The reason the mapEventToState signature is (S state, E event) is because the state parameter is referring to the current state rather than the new state.

In onTransition as well as the Bloc class type signature the state is referring to the next state (the output of the Bloc).

Also, mapEventToState is inspired by Redux Reducers whose function signature is (S previousState, A action).

A Bloc is described as converting Events to States (<E, S>) ; however, mapEventToState takes the current state and event and returns the new state (S currentState, E event).

Thoughts? Does that help clarify why it's written the way it is?

[felangel]

@JohannesKlauss closing this for now.
Feel free to respond with any comments or concerns and I'll gladly reopen the issue.

[ThinkDigitalSoftware]

OK, came to report this as well. It was confusing. Can you add in the docs what the generic types are for? I figured them out, but not after digging.
Like It's not clear what E is, and what S is until later down the code

[felangel]

@ThinkDigitalRepair sure I can definitely update the docs. Do you think it makes sense otherwise or do you still feel strongly that it doesn't make sense as is?

[ThinkDigitalSoftware]

Well making sense is relative to the one understanding. The way I view it,
the event should be on the left, cause input is generally considered to be
coming from the left side, and whatever is going out to the stream should
go out to the right. Cause we're not actually mapping anything to (AKA
changing) the state, we're creating a new state object and sending it out,
correct?

If so, then it would make sense to have

(E event, S state)

[felangel]

Yes I agree that generally input is coming from the left side but the way I view it is in this case we have two inputs and we're creating a new state object. The two inputs are S currentState and E event. I personally thought it made sense in that order because the currentState precedes the event. Thoughts?

[ThinkDigitalSoftware]

Wait. If state is the current state, then it makes sense because it exists before the event does. I really need to study this function

[ThinkDigitalSoftware]

It would be very clear if the variable was named currentState or oldState, etc

[felangel]

haha yeah I will rename it and add the documentation for the generic types

[felangel]

changes included in bloc v0.7.4