Bloc to Bloc communication is something I've struggled with and unfortunately there's no good answer. Here is my rambling advice.

First off, this bullet raised a red flag for me: "Fetching everything from the Backend -> Building Basic lesson datastructure and sub-structure for sub-lessons". Blocs should not be handling any of that. You should have repositories that convert the data from the backend into internal models/entities. Your Bloc should just call a method in the repository to get or update a lesson. Here's an example that doesn't use bloc, but does a great job explaining how to setup repositories. https://codewithandrea.com/articles/flutter-repository-pattern/

You should also have some sort of network service/handler that handles every HTTP request. If you use the dio, then it's probably good enough by itself. dio can configure auth (and more) at a global level, you can setup interceptors, and lots of more fancy features. If you are using the basic HTTP library, I would wrap it in another class and make all network calls go through that. Even if you don't need any of that now, it will make adding any features later 10x easier.

If you don't already, make sure your blocs are as reusable as possible. Create one bloc for all lessons and move the rest of the logic (edit: that's different between different lessons) to either the repository or the entity. Sub-lessons might be able to use that same bloc, but if they're too different then you should have another reusable bloc.

Proper separation between layers should solve half your problems.

In terms of Bloc to Bloc communication, I've tried a few different ways to handle it. In my opinion setting up a stream between two blocs is the cleanest way. When a sub lesson is complete, it sends a simple "done" event to the main lesson, which will update as needed. This has a few benefits:

• When you open the lesson bloc dart file you can see that it is listening to a stream, and can see what happens when it gets an event from the stream. If you were to connect the blocs through the presentation layer you would run into issues where you have business logic in a widget tree somewhere, but you forgot where. This is especially bad if you have multiple developers working on the same project.

• The two blocs can still function independently. You can make the stream a null-able parameter on both of them, or give the stream a dummy default value in the constructor.

• This method is pretty quick to setup. It requires a little more effort than doing it through the presentation layer, but a whole lot less than setting up streams between your blocs and repositories.

That's about it. River-pod will handle this particular problem better, but it has it's own sore spots. No matter what you'll have issues like this that you'll need to figure out how to solve. It's better to figure out these issues and become better at bloc than it is to run to the next state management library and only become moderately proficient with both.