https://www.reddit.com/r/FlutterDev/comments/pjj40p/riverpod_vs_bloc/

> Even though I could accomplish everything I wanted, it ended becoming messy with dependencies spread throughout the code. I don't know how many providers would I be able to manage at the same time before my head blows up and most of the providers don't make any sense on other 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.

https://www.reddit.com/r/FlutterDev/comments/kyd7zs/riverpod_a_better_state_management_solution_than/

> 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.

検索してランダムに選んだページだけでもこういう投稿があった
ネガティブな感想もやっぱりそれなりにあるってことかな
ここと違って人格否定とかされることはなく健全に意見を出し合ってていいな
異なる考えを示した人を異端扱いして叩いてたら偏るんだよなー