Avoid:
1. Importing material.dart or using any material widgets
2. Inherited widgets
3. Platform views (HtmlElementView / VideoPlayer)
4. Too much logic in stateful widgets (controllers instead)
5. RawImage
8. Overlays (use OverlayPortal)
9. go_router
FFI isn't supported on web where these issues are really problematic. I actually had to contribute changes to the web engine to make it possible though.
Introduces runtime errors, doesn't play nicely with overlays (which some frameworks introduce), hides dependencies, and makes init / teardown a mess if your inherited widget needs any kind of subscribe / unsubscribe or you have more than one inherited widget referenced in your widget.
They are decent for theming, media queries, and UI framework concerns. Still tend to fall apart with overlays but the less of them you have to manually copy into a new tree when you need screenshots or use overlays, the better. Also can be an escape hatch when you don't own all the code.
Interesting. With overlays it's a problem of placement in the widget tree if I understand it correctly - so basically overlay has access only to things at app level, right?
Why hiding dependencies is bad? I think some parts of the app shouldn't know about impl specifics.
Unless you actually want your app to use Material styles there is a lot of friction changing the way it looks. Even if you want to use Material there is a lot of friction since Material doesn't ship things like Material Symbols and often doesn't conform to the latest material guidelines that well.
I've avoided BloC, GetX, Riverpod, and all of those weird state management packages from day one, so I should probably add that to the list since apparently that's not obvious to everyone 😂
I don't mind streams for data from servers, but for event streams I don't like the complication compared to JS EventEmitter.
I avoid ValueNotifiers because they are overly complicated to use for what they do. Controllers can definitely use ChangeNotifier if you don't need granular notifications.
Well it is, but if I see a widget with a bunch of value notifiers for every property I'm gonna think someone as putting way too much logic in their widget and they should have just built a controller class. It's hard to pass around groups of value notifiers, easy to pass around a controller.
Comments
1. Importing material.dart or using any material widgets
2. Inherited widgets
3. Platform views (HtmlElementView / VideoPlayer)
4. Too much logic in stateful widgets (controllers instead)
5. RawImage
8. Overlays (use OverlayPortal)
9. go_router
Why hiding dependencies is bad? I think some parts of the app shouldn't know about impl specifics.
For everything else we roll mix.
I avoid ValueNotifiers because they are overly complicated to use for what they do. Controllers can definitely use ChangeNotifier if you don't need granular notifications.
I'm interested in how you implement a controller 🤔
So what's your go to solution for event streams?