540 名前： screens so it gets messier to locate the ones you are looking for when names are similar.
> FutureProvider which worked fine for simple examples to a StreamProvider. But I need to keep track of those loaded which were previously loaded so I could keep adding when scrolling. So I had to move to a StateNotifierProvider with all the data or keep several providers very closely coupled so when the stream loads data it loads it into another provider. In the end, the complexity of using Bloc or Riverpod ended quite similar. But with Bloc I would have been able to extend functionality without refactoring so much.
> Not personally a fan of riverpod as I feel it encourages a bad antipattern of scattering shared state all throughout your widget tree. This can lead to code being very hard to find (non-centralized), and makes debugging harder to follow as there are excessive dependency chains and couplings between providers.
> the 'compile safety' of Riverpod, allows developers to safely do something that really is not a good thing to do when it comes to maintenance and debugging.
