Moving bloc in blocs app7/9/2023 If an event called asynchronous methods and took a long time to finish, the other events just queued up, patiently waiting for their turn. Prior to Bloc 7.2.0, events were processed sequentially, one after the other. In addition, if you run the app, you can examine the code for both the old and new blocs and see how they work with the same exact widgets. The code for each bloc is included twice: one uses the old mapEventToState approach, and the other uses the new event registration system. You can view the complete source code for all three scenarios in the accompanying code repository, which was created with Very Good CLI. To avoid making this article too long, we're showing only the relevant snippets of code which explain the concept. In total, we will demonstrate three different scenarios, each taking advantage of bloc's new concurrency features. In this article, we'll build each scenario the old way, using mapEventToState, before migrating it to Bloc 7.2.0's new event registration system. If you haven't designed your blocs with this in mind, don't worry! The rest of this article will demonstrate several examples using the old bloc syntax and show how they can be migrated to safely and effectively use Bloc 7.2.0. In Bloc >=7.2.0, whichever event finishes processing first in that particular moment will have its state overwritten by the event which took the longest. If they yield conflicting states, a race condition results. In the example above, both EventA and EventB will be processed concurrently. BlocProvider.of(context).add(EventA()).add(EventB())
0 Comments
Leave a Reply. |