3 ms·

It works perfectly for us - in a professional app nonetheless - and has not been restricting at all. No bad design or anti-pattern bit us, and it does not get c

by onli 5y ago

It works perfectly for us - in a professional app nonetheless - and has not been restricting at all. No bad design or anti-pattern bit us, and it does not get cleaner or more expressive than Obx with a controller. This is unlikely to change, the process where our app got more and more complicated has already stopped. > If you go for Flutter job it's best to not mention GetX either. I wouldn't work for an employer that does not let me pick the right tool for the job, so there is no danger there.

Comevius 5y ago
Not to get on your nerve, but GetX is basically a toy API, and the codebases that use it tend to evolve in the heap of spaghetti direction, but if your app is simple enough you can get away with it and save time, so who am I to knock it.
- onli 5y ago
  Na, it's okay, if you really feel that way you should comment accordingly, especially given my strong blanket recommendation. I see it exactly the other way around, but defining things like "clean" are hard to do and we might just have completely different positions. Maybe to make it as constructive as possible, why don't you link to what is your preferred alternative approach? I assume it's not setState :)
  - Comevius 5y ago
    Riverpod is pretty good, and using the Bloc pattern without any Bloc libraries, just with StreamBuilder or your own abstraction is pretty good. The rest is just using the Flutter API as intended. https://riverpod.dev/ https://riverpod.dev/ I personally also like to practice data-oriented design, write most of the logic in C/Zig with a functional reactive Dart API, and then share the streams with Riverpod. I keep most of the state in C/Zig, but that should be a Dart-only library, I just use C/Zig because I need the core functionality of my app to be portable, for example to use it with Vue.js, or even FreeBSD, which Dart don't even support, but if that's not the case a Dart-only library for the core functionality is the way to go.

by onli 5y ago

Comevius 5y ago

Not to get on your nerve, but GetX is basically a toy API, and the codebases that use it tend to evolve in the heap of spaghetti direction, but if your app is simple enough you can get away with it and save time, so who am I to knock it.

onli 5y ago
Na, it's okay, if you really feel that way you should comment accordingly, especially given my strong blanket recommendation. I see it exactly the other way around, but defining things like "clean" are hard to do and we might just have completely different positions. Maybe to make it as constructive as possible, why don't you link to what is your preferred alternative approach? I assume it's not setState :)
- Comevius 5y ago
  Riverpod is pretty good, and using the Bloc pattern without any Bloc libraries, just with StreamBuilder or your own abstraction is pretty good. The rest is just using the Flutter API as intended. https://riverpod.dev/ https://riverpod.dev/ I personally also like to practice data-oriented design, write most of the logic in C/Zig with a functional reactive Dart API, and then share the streams with Riverpod. I keep most of the state in C/Zig, but that should be a Dart-only library, I just use C/Zig because I need the core functionality of my app to be portable, for example to use it with Vue.js, or even FreeBSD, which Dart don't even support, but if that's not the case a Dart-only library for the core functionality is the way to go.