Closed MrCsabaToth closed 3 weeks ago
Comparison article of several state management tools: Provider, BLoC, GetX, Riverpod, WathIt (+GetIt) and MobX https://medium.com/@alvaro.armijoss/flutter-state-management-provider-bloc-getx-riverpod-getit-and-mobx-c9db3168a834
Testing with GetX: https://baguskto.medium.com/how-to-unit-test-in-flutter-using-getx-step-by-step-guide-7e183cc9d702
Besides the annoying restriction of context presence + only during build (Cubits) is that the general problem of await initialization. Several components require await-able initialization, while neither the initState is async nor most of the tools are ready to handle anything like that. For example Cubit needs to be initialized in the constructor super - but an awaitable initialization has a Future type, cannot be stuffed into a constructor call parameter. It's very hard to handle that and it leads to a solution similar to a Raygun olympic break dance: we are banding over backwards and flopping on the floor try to abide by the rules. Certain frameworks doen't make our life easier, but rather create too much friction and headache.
The "nice" and supposedly praised state managements (Cubit, RiverPod) suffer from these, while the supposedly no-no "very bad" GetX or WatchIt doesn't. At the end of the day all of the state management tools store globals or singletons, whether we like it or not, whether we admit it or not.
What matters is if a framework hinders test-ability or not. And of course if it supports async I described above.
There could be some challenges with tests, but I managed to pass at least the ones we have now
The Cubit poses a complication with the limitation that it can only be retrieved during build from the context. That's unusable with any callback type workflow, and made many code sections unnecessarily cumbersome.