Dart: Streams vs ValueNotifiers

Question

I'm working on a team that is developing an app which needs to work with sensors to represent a vehicle's state. This state can either be represented through values given by external hardware sensors or work minimally through a mobile device's own sensors. And we want the ability to swap sensor packages (switch between mobile or external sensors). We also want these values to be shown asynchronously and we are researching Streams and ValueNotifiers in Flutter/Dart.

What's the best way to go (Stream vs ValueNotifier)?

Claudelle

Just a follow up, anyone interested in working with streams, should really read this interesting article: medium.com/flutter-community/… – Claudelle

Answer 1

ValueNotifier are very lightweight and this is why the Flutter framework uses them.
They didn't want to impose any performance penalty no matter how small if it can be avoided.

Streams are much more powerful, expecially their composability that makes it easy to use high-level functionality like the ones provided by https://pub.dartlang.org/packages/rxdart.

Using ValueNotifier in your custom code for the same performance considerations made by the Flutter team is probably premature optimization.

I'd suggest streams for business logic.

Laspisa

Fully agree with the answer. ChangeNotifier tends to be abused by developers. They keep on adding logic and data inside of it until it becomes a maze of trouble. Streams force you to slice your state in discrete packages that are easy to reverse engineer and maintain. Of, course, streams cam be abused too, but it takes more effort. It will feel bad sooner than later if you attempt to push silly stuff into streams. – Sirree

Answer 2

I'm going to hop in on this conversation even though I'm late to the game. I think there is a tendency for developers to overhype Streams/BLoC/RX/etc. Sure, the BLoC architecture is powerful but to me it seems to offer a lot of boilerplate compared to something like ScopedModel - essentially what appears to be a version of a ValueNotifier inside of an InheritedWidget.

The ScopedModel is nice because you can just place a widget inside of a ScopedModelDescendent (obviously this is placed within the ScopedModel) and let the value you're changing in the actual ScopeModel update the children whenever you call the notifyListeners() method. Or you can use it as a way to grab some simple data or call a function by using the .of(context) -- which is more expensive since it travels up the widget tree to find the ScopedModel, so I use that for things like sending alerts or initializing a component that needs data from within the scope before calling build.

Though, take my advice with a grain of salt. I'm just a noob with an opinion. Which may also help explain my disdain for Streams/BLoC. I really just like simpler solutions rather than the more powerful ones. If I need more power for a situation then I tend to just build out a custom solution. Just like in all things, there is a use case for each of these patterns.

Coextensive

Adrian, thank you for the consideration. You got me down the rabbit hole of refactors, and I also found states_rebuilder which may be even more helpful. I wish this article was around when we started developing: medium.com/flutter-community/… – Claudelle

The states_rebuilder is new to me so thanks for pointing that out. I like that it has more granular control over individual widgets within its scope and has a built in init. I actually use a pattern similar to that by creating a mix of ScopedModels/StatefulWidgets/ValueNotifiers, each doing different jobs for different components, so it's nice to see something like that all wrapped up in a singular package. – Coextensive