The Bloc generally contains state, but the implementation does not use a StatefulWidget to hold the bloc. I understand the reasoning is that we want the fast lookup that we get from InheritedWidgets and more easily injected values than if we used the InheritedWidget + StatefulWidget combination that a lot of people suggest. But isn't it bad design to have state outside of stateful widgets?
I know, for example, that this route causes state to be lost when we do a hot reload. Don't we effectively lose a lot of the benefit of hot reload this way?
krusek
All 3 comments
It appears there has already been discussion about why you are using an inherited widget. I'm still concerned about hot reload being broken and I don't see that being addressed, but feel free to close this issue if you want to move along.
krusek
on 9 May 2019
Looking at the sample code, it looks like the recommendation would be to have some parent widget that is stateful that creates and holds a reference to the bloc.
krusek
on 9 May 2019
Hey @krusek 馃憢
Can you please provide an example of a case where hot reload is broken? The BlocProvider widget is meant to make the bloc available to the subtree but it is not responsible for creating/disposing the bloc. The creation and disposal of blocs should always be done in StatefulWidgets which should address your concerns.
Let me know if that helps and great question 馃憤
felangel
on 9 May 2019
Related issues
ctippur
路
3Comments
RobPFarley
路
3Comments
nhwilly
路
3Comments
komapeb
路
3Comments
nerder
路
3Comments
Most helpful comment
Looking at the sample code, it looks like the recommendation would be to have some parent widget that is stateful that creates and holds a reference to the bloc.