☂️ Reinforcement: Refactor widgets from design into the core before decoupling #53059
Description
This issue tracks the essential refactoring work required to strengthen the core widgets library before decoupling the material and cupertino libraries (#101479).
We will prioritize net-new additions after decoupling.
🔍 For feedback on net-new widgets to strengthen the core, see: link
Our goal is to identify and move foundational, style-agnostic logic out of the existing design system libraries and into the core framework. This will ensure the core is robust enough to support multiple high-quality design systems and will provide a richer set of primitives for all developers.
Note
It is important to note that not everything in the design libraries will be refactored into the core. Some widgets are too heavily tied to their design language to extract a meaningful, un-opinionated API that would satisfy developer needs. One of our guiding principles is to avoid the "lowest common denominator" problem, ensuring that any new core widget is genuinely powerful and flexible.
Community Feedback Needed 🗣️
This is a critical opportunity for community input. Please use this issue to provide feedback and suggest other widgets or functionalities you believe are fundamental and should be moved into the core widgets library before the main decoupling occurs.
Widgets we are investigating/refactoring before decoupling:
- Move platform specific page transitions outside of Material and Cupertino #172929
- Evaluate decoupling text stack from Material and Cupertino #172930
- Evaluate a basic color set for Flutter #172931
Widgets that are unlikely to be refactored, will migrate as-is:
- ColorScheme
- Very material, uses material color utilities package to generate material spec color scheme.
- InkWell
- Relies on Material ancestor to paint, too complex to refactor to a basic component that paints in response to a gesture, which could be done in a different/simpler way
- Scaffold
- Very material specific for layout. We discussed focusing on simple app bar, bottom bar widgets might be nice to have instead with built in safe area handling. A column could compose something similar to a Scaffold layout if the simple *bar components handled things like SafeArea out of the box. Simple composition from the widgets layer is still our focus.
- SliverAppBar
- Highly complex and material-specific
- SliverPersistentHeader, its base class is already in widgets, We added several atomic sliver header widgets last year that are meant to replace the SliverAppBar behemoth through composition in the widgets layer.
- SliverResizingHeader: Pins its child and resizes it from its max extent to its min extent when scrolled
- SliverFloatingHeader: Hides the child when the user scrolls backwards and shows its child when the user scrolls forward
- PinnedHeaderSliver: Keeps its child pinned to the top of the scroll view.
- TabBar
- Does not implement navigation, instead a scrolling PageView under the hood. Could develop something simpler in the widgets layer, but the current material implementation does not appear to have a clear common base. Very specific to material design (similar assumptions in AppBar, SliverAppBar) with regards to preferred size. We should consider the opportunity for a net-new base component in ☂️ Reinforcement: Add more basic components to the core framework #97496.
- Theme, TextTheme
- We discussed a new base theme object as making sense. Added to net-new issue for consideration later (☂️ Reinforcement: Add more basic components to the core framework #97496). For use in the WidgetsApp, containing:
- ThemeExtensions, or something similar
- High contrast (a11y)
- Brightness (dark mode)
- defaultTargetPlatform
- Font family and fallback
- Perhaps others…
- We discussed a new base theme object as making sense. Added to net-new issue for consideration later (☂️ Reinforcement: Add more basic components to the core framework #97496). For use in the WidgetsApp, containing:
To consider - provide feedback and we’ll add to this list:
- Tooltip
- Indicators - progress, linear, refresh
- Date pickers - parts of
OP
Use case
The number of platforms that Flutter officially targets to a reasonable level of stability has grown beyond just Android and iOS to include the web, Windows, macOS, and Linux. Yet most of the widgets the SDK provides are still tied to the design guidelines/systems of those two mobile OSes. This seriously impacts the out-of-box usability of the widget library for developers who are using Flutter for other platforms/who do not necessarily prioritise mobile.
I think there is a strong case to be made that there are a lot of widgets in flutter/material and flutter/cupertino that really should be/be based on flexible, extensible widgets in flutter/widgets so that developers can take direct advantage of logic that's often hidden away in private classes and hardcoded constants, rather than having to duplicate it.
Proposal
Much like with the new plugin system, I think it would be a great idea if certain Material/Cupertino widgets were rewritten to decouple the general "behaviour" of the widget from design-specific guidelines (and probably make more use of delegates and painters). A prime candidate would be Slider and CupertinoSlider, for example.
One set of widgets that I think already does this decently well is the set of Scrollbar (from flutter/material), CupertinoScrollbar (from flutter/cupertino) and ScrollbarPainter (from flutter/widgets). With the latter it is easy to build a custom scrollbar without having to think too much about (or copy the logic of) how a scrollbar should work, and you also have built-in scrollbars that follow Material guidelines or HIG if that's what you want. The only thing I would change about this set is to update the documentation of ScrollbarPainter with a minimal example of how to put together a scrollbar with it.