First Feedback: There is NO CATEGORY for DISCUSSION or FLUTTER FEEDBACK.
Now, to my ACTUAL concern: Slivers are CONFUSING, implemented POORLY and don’t make sense as independent CLASSES.
My understanding of Slivers; correct me if I am wrong:
A Sliver is a slice of scrollable widgets. The two functions that Slivers fulfill (mainly) are:
- Enabling “on scrolling” behavior
- Lazy loading large collections of widgets
Now the reason Slivers are STUPID is because these functions should just be INHERENTLY PRESENT IN FLUTTER WIDGETS.
AppBar should just be able to react to scrolling. Having a SliverAppBar is COMPLETELY UNNECESSARY and just serves to confuse newcomers.
Any gridview should already implement scrolling behavior, same with Listview etc. There is NO REASON to have a “stupid” kind of grid that does “stupid scrolling” and a “smart” grid that does “smart” scrolling. What is ever gained by using a “box-rendering” kind of grid instead of one that “smart-renders” while respecting scroll (slivers)? Nothing. There is no reason to ever render something without at least CONSIDERING scroll. (I THINK).
In short: There is no reason to gatekeep scrolling behavior behind Sliver-Type widgets.
I am no Flutter-veteran, nor expert but if I am CORRECT in my position that the two aforementioned functions are at least 90% of what Slivers are for, there is really no reason (except development time and effort :P) why all widgets shouldn’t consider scroll parameters and lazy loading, since scrolling is a vital component of pretty much any app.
Thanks for coming to my ted talk
Ah yes, the valiant defender of poor design choices as “skill test”
Please, consider “thinking” the next time…
At first it didn’t make any sense to me either… Maybe they did it this way, because they thought most people won’t need dynamic lists and widgets that react to scroll and the framework can assume certain things about the “stupid” widgets for rendering. If all the widgets had these dynamic capabilities it would make it harder to implement simple non-changing layouts for the developers, you would have to do the same things as for slivers right now.
Unifying them would mean, that the framework has to figure out if a widget is dynamic or not and you would still need to do the same things you need for slivers right now if you need a dynamic widget.
Sorry for not being able to explain it better, I’m just a hobby flutter dev, but slivers make sense to me… and slivertoboxadapter is you friend.
edit: about every widget have having onscroll… It would complicate the widgets I assume, and I think they didn’t want to implement every possible behaviour on the base widgets to keep maintenance simple. The tools are available to make it act how you want it. Probably there’s already a package for the things you want.
also there are many dynamic or alternative listviews too on pub.dev
1 Like
For me this is purely a question of Design, my current project won’t even have any need for scrollable features (as of now.)
I want to reuse my SliverAppBar example to drive my point home.
What is SliverAppBar? It is AppBar + Scroll. So now, the framework contains two classes that are essentially identical except for (to my understanding) one (1) feature. This would typically be handled by class parameters.
The only reason to keep seperate classes would be, as you argue, if they were so different in nature that combining them would cause significant complications. In underlying implementation or, again, user experience.
Adressing implementation first, all widgets are already “dynamic” in the sense that they need to respond to changing parent constraints on rebuild. So the only relevant question is that of whether non-sliver widgets get significantly more expensive or clunky by adding scroll parameters and “onScroll” functions and I don’t think this is the case.
Really, any widget can have one of two behaviors regarding view size: Change size or become scrollable. And this question is, I think, much more fittingly answered by extra parameters instead of a whole family of duplicate classes. And this ties into user experience, as flagging lets say a List as “Scrolling” or “Resizing” is much more intuitive (I THINK) than having the same widget as “Scrollable” or “Resizable”.