3 ms·

> Don't get confused by the myriads of state management solutions... > Evade everything with code generation... It is funny to see this theme getting repeated

by isoos 5y ago

> Don't get confused by the myriads of state management solutions... > Evade everything with code generation... It is funny to see this theme getting repeated in various domains: at the same time, you will get users who complain that there are not enough choices for them in domain X, while others complain that there are too many choices in the same domain X. And usually there is no single best solution to rule them all. E.g. in these specific items, I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv.

onli 5y ago
> I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv. YMMV definitely applies :) Since I have some experience with exactly that alternative: I see bloc + freezed as the antithesis to GetX. "Clean" abstraction over "simple" code. There might be more extreme example for both sides of course, but this has been my impression. We do use bloc + freezed for some specific flows in the app where the abstraction just fit better. A better fitting abstraction is a big plus on its own for those usecases. On the other hand, bloc had a bunch of breaking changes (nicely visible in https://pub.dev/packages/flutter_bloc/changelog https://pub.dev/packages/flutter_bloc/changelog), and that especially in combination with hydrated bloc has given us a bunch of grief. I hate breaking changes more than anything. It might still be a better solution - so really, YMMV - if your goal is maximum abstraction to be able to change frameworks (or in this case, I assume it would be about state management solutions), after all that's where the solution is coming from. For me, that was an anti-goal, abstraction = complexity, while minimal complexity with maximal development speed was what we needed. GetX fit perfectly for that. Admittedly, ignoring some things to learn with lists and at the beginning strange issues with Obx change detection, but the latter got better, either with bug fixes or experience. If Obx misbehaves now it has always been a clear fault on our side.

by isoos 5y ago

onli 5y ago

> I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv. YMMV definitely applies :) Since I have some experience with exactly that alternative: I see bloc + freezed as the antithesis to GetX. "Clean" abstraction over "simple" code. There might be more extreme example for both sides of course, but this has been my impression. We do use bloc + freezed for some specific flows in the app where the abstraction just fit better. A better fitting abstraction is a big plus on its own for those usecases. On the other hand, bloc had a bunch of breaking changes (nicely visible in https://pub.dev/packages/flutter_bloc/changelog https://pub.dev/packages/flutter_bloc/changelog), and that especially in combination with hydrated bloc has given us a bunch of grief. I hate breaking changes more than anything. It might still be a better solution - so really, YMMV - if your goal is maximum abstraction to be able to change frameworks (or in this case, I assume it would be about state management solutions), after all that's where the solution is coming from. For me, that was an anti-goal, abstraction = complexity, while minimal complexity with maximal development speed was what we needed. GetX fit perfectly for that. Admittedly, ignoring some things to learn with lists and at the beginning strange issues with Obx change detection, but the latter got better, either with bug fixes or experience. If Obx misbehaves now it has always been a clear fault on our side.