Flutter_bloc中嵌套PrepBloc与MainBloc的实现方式是否合理

你这种条件嵌套BlocProvider的实现是完全合理的，和你当前的业务场景匹配度很高。

核心优势 #

• 完全贴合你两个Bloc的先后依赖逻辑：PrepBloc没有完成准备工作之前，MainBloc本身就没有存在的必要，你这种ReadyState才挂载MainBloc的方式，比MultiBloc一上来就初始化两个Bloc的方案更省资源，也能从根源上避免MainBloc提前初始化拿不到前置配置的问题。
• 代码更精简：你不想用MultiBloc的顾虑完全成立，MultiBloc本来就是为无前置依赖的平级多Bloc场景设计的，硬套到你的场景反而要额外写很多MainBloc闲置状态处理、跨Bloc取参数的冗余代码，你的实现反而更直接高效。

注意避坑点 #

• 如果MainBloc初始化需要用到PrepBlocReadyState里的配置参数，直接在BlocProvider<MainBloc>的create方法里拿当前state的对应字段就行，比MultiBloc方案跨Bloc传参方便很多。
• 如果你的应用有退出登录、重置回到准备流程的需求，不需要额外手动销毁MainBloc，BlocProvider会在切换到NotReadyState、MainBloc对应的组件节点卸载时自动执行dispose逻辑，不会有内存泄漏问题。
• 进入ReadyState之后的所有子页面，都可以正常通过context.read()/context.watch()拿到PrepBloc和MainBloc的实例，不会出现访问不到的问题。

内容的提问来源于stack exchange，提问作者Thomson