bloc
bloc copied to clipboard
feat: An eventHandlerTransformer to control how multiple event handlers emit their values
Description
Hello, I ported my blocs to the new on<Event>() API and things mostly worked :) However I was also affected by the issue raised in #2790 since my blocs expect event handling to be done sequentially. Setting all handlers to sequential() wasn't enough because handling between multiple event handlers is always done concurrently (right?)
The suggested solution to use a single on<BaseEvent>() handler with a sequential transformer worked, but it does take away from the elegance of the new API imo
Proposal
It would be cool if the event handling order could also be configured. Perhaps an eventHandlerTransformer (that gets passed into the constructor?) which lets you configure whether two or more event handlers are run concurrently, sequentially, etc.
So for example, a Reload event handler could be droppable, so multiple Reload events added in quick succession will only process the first one and drop the succeeding ones. But on a bloc level, inter-event handling could be sequential, so multiple Reload events followed by an Upvote event in quick succession will result in one reload that finishes (others dropped), followed by the handling of the upvote event after the reload.
Hi @felangel,
First of all, thanks for this great set of packages, we use them as the state management solution in our app and we are very happy with it!
Regarding the problem/proposal above, I think the new logic (concurrent handling between multiple event handlers) might be pointed out more in the migration doc. If someone follows the guide and replaces _mapEventToState to on* functions then the new bloc will behave differently from the old one.
My understanding is that currently the only way to keep the sequential ordering between different event types is to implement one on<Event> function with sequential transformer and move the _mapEventToState logic into the new function. Am I correct or is there any other way to keep the old bloc behavior?
Hi @gyenesandras π Thanks for the positive feedback!
The migration documentation has been updated to call this out more explicitly with an example of how to maintain the previous sequential processing.
My understanding is that currently the only way to keep the sequential ordering between different event types is to implement one on function with sequential transformer and move the _mapEventToState logic into the new function. Am I correct or is there any other way to keep the old bloc behavior?
That is correct and weβre exploring ways to support grouping multiple event handlers so that you can apply transformers across independently registered handlers.
Sorry for any inconvenience and hope that helps π
Sorry for any inconvenience and hope that helps π
Yes, thank you!
Is there any new information on this? @felangel