Here is an approach that achieves a result that is very similar to #bloc with #flutter emit here works in a similar way to how to emit works on a Cubit, but without the complexity of streams. Check out the live sample here dartpad.dev/?id=2b21f5fb6e…
What complexity of streams is there still when you use cubits?
Streams are not necessary unless more than one thing is listening, and it means you've got to close something when it goes out of scope
But then you are talking about making things other then UI (other cubits ?) listen to cubits right? This is not something you have to deal with when you use the flutter_bloc widgets.
Check out the code sample on dartpad. Perhaps it can explain things better
So you give the VM a callback to do setState. So now you will always have to create a StatefullWidget, correct? How is this more convenient then using context.watch<CounterCubit>() in a stateless widget? Or a BlocBuilder for that matter?
Not necessarily more convenient, but it's a different approach, it works, doesn't require any packages and doesn't require a stream under the hood.
Interesting exploration. What do you think about ChangeNotifiers? Your solution looks like it but is limit to 1 'listener'.
ChangeNotifiers are built to deal with many listeners. If you use them, you need to add code to listen/stop listening 1/x
A lot of the time we don’t need to deal with many listeners. We just want to respond when the state changes. You might go down the path of using a ValueListenableBuilder on top, but have a look at what it does under the hood. 2/x
Ultimately, it’s just an elaborate and confusing way to call setState(). So why not just call setState() ? 3/x
Here is an approach that just gives your business logic / view model / state / whatever you feel like calling it the power to call setState() 4/x
Not saying this is the “right” way. But, the more I dig in to “state management” solutions, the more I start to wonder if they are anything other than elaborate ways to call setState() … 5/x
Even BlocBuilder is a StatefulWidget whose State ultimately calls setState() via BlocListener 6/x
All these state management solutions are the same shit with a different consistency. That’s my take.
But, another way of putting it is that they are all just different ways of calling setState() At least in my understanding so far…
The difference is WHICH setState they are calling. That's why all these solutions like Provider, Riverpod, Redux even, let you encapsulate specific parts of your tree. It's to Manage these States.
All the more reason to stay as close to setState() as possible so you've got the ability to decide which one gets called. However, getting caught up with shaving off the tiniest amount of processing is usually counter productive as well.
Then what prevents you from rebuilding the whole app everytime and remove Stateful widgets as a whole?
Using setState() in the place in the hierarchy which is farthest away from the root
Hmm, im curious what issues you might run into when your implementing your solution. Are you planning on using it soon?
I'm mostly just experimenting at the moment and looking for the simplest ways to deal with state. Everything I try ends up pointing in the direction of using StatefulWidgets directly.
All state management solutions are ultimately just stuff on top of stateful widgets anyway
Well, that's obviously true since that's how Flutter maintains state. I've build my first Flutter app with only setState back in 2018. It was rather small and worked just fine. I was passing needed info trough parameters. But this doesn't scale well.
When your widget tree is growing passing through params become a pain. Soon you'll naturally start using inheritedWidget. But these are also painful to use and require boilerplate to make useful. So this is what these packages are solving + build optimizations.
State management packages or #InheritedWidget has nothing to do with passing "data" deep down the widget tree, I can tell. You only need some classes to keep data/data streams, inject it into widgets using #DI tool like get_it, manage data if you want.
Most people use Getit as global state. Basically, that's cheating. If you want to put everything in the global state, you can use GetX. I haven't ruled out using global state but I'd prefer to avoid it until there are no other options
Global or not global depends on how you manage the lifecycle of your objects, it doesn’t relate to a DI tool at all. You can use factory to create objects to use in one or many places, the scope depends on you. 1/2
Well most of the ones I've used have some provider widget and consumer widgets which is exactly to pass down data.
I mean, passing down data is not the main purpose of state management packages. They're opinionated structures for our code base. So, the proper reason to use any package is that you want your code base to be structured like that package defined.
United States الاتجاهات
- 1. #UFCQatar 65.6K posts
- 2. Syracuse 5,085 posts
- 3. Harden 24K posts
- 4. Arman 19.6K posts
- 5. Belal 9,544 posts
- 6. Ian Garry 7,159 posts
- 7. Mizzou 5,847 posts
- 8. Fran Brown N/A
- 9. Makai Lemon N/A
- 10. Dan Hooker 5,829 posts
- 11. #GoIrish 3,540 posts
- 12. Mercer 2,621 posts
- 13. Mike Washington N/A
- 14. Deuce Knight 1,572 posts
- 15. Andrew Marsh N/A
- 16. Arbuckle 1,781 posts
- 17. Oklahoma 23.5K posts
- 18. Rutgers 6,607 posts
- 19. Mateer 2,630 posts
- 20. Tanook Hines N/A
Something went wrong.
Something went wrong.