☂️ Reinforcement: Add more basic components to the core framework #97496
Description
This issue tracks proposals and development for net-new widgets and functionalities to be added to the core widgets library.
This effort is the other side of the coin to our reinforcement work, see the refactoring side as well. While the refactoring issue focuses on moving existing code, this issue is dedicated to identifying and building new, foundational, style-agnostic primitives that are missing from the core widgets library today. The goal is to fill gaps in the core and make it an even more powerful foundation for building any design system.
Note
Some of these may be best informed by a UXR study. Before considering contributing one of these net-new widgets, reach out to the team on Discord to confirm.
Propose a New Core Widget! 💡
What foundational widget or capability do you wish existed in Flutter's core? If you have an idea for a new, un-opinionated "headless" widget that would be broadly useful, this is the place to propose it. Please provide a clear use case and rationale for why it belongs in the core framework.
Last update Mar 4, 2026
So far, we have investigated many of the existing design components to determine if any refactoring can be done before decoupling, moving existing APIs to the widgets layer to a common surface (which is tracked in #53059). In some cases, we have decided not to break widgets in the design libraries to try to accomplish this, which leaves the opportunity for new, more generic APIs to be introduced in the widgets layer later.
As we have been focused on the opportunity to refactor existing widgets (#53059) ahead of actually separating the libraries, expect this work of adding new widgets to continue after the design libraries land in their new packages, which is what this issue is meant to track.
To check out all the issues and aspects of the decoupling effort, see the github project, and the root parent issue: #101479.
Status:
- What's landed or being worked on wrt raw widgets:
- Menus
- Radios
- Tooltips
- Page transitions
- Other
- What's been looked into and will revisit after decoupling lands:
- TabBar
- Move TabBarView (and friends) to flutter/widgets.dart #175592
- Navigation oriented, or still scrolling PageView
- We found this API has a lot of material baked-in. Rather than breaking it, after decoupling lands, we'll revisit a generic TabBar in the widgets layer.
- Theming
- Investigate adding theming options to the Widgets library #177932
- design doc, we'll revisit this after decoupling lands.
- We discussed a new base theme object as making sense. For use in the WidgetsApp, containing:
- ThemeExtensions, or something similar
- High contrast (a11y)
- Brightness (dark mode)
- defaultTargetPlatform
- Font family and fallback
- Perhaps others…
- Text input and selection stack
- flutter.dev/go/decoupling-design-from-text
- Evaluate decoupling text stack from Material and Cupertino #172930
- We discussed:
- The future of SelectableText
- Here we discussed the state of text selection components in the widgets library without SelectableText after decoupling Material and Cupertino from the framework.
- The recommendation here was to move forward with SelectableText leaving the framework with Material, and to continue working on fixing critical bugs in SelectableRegion + Text.
- Design agnostic text selection UI
- This discussion was around whether it was feasible to move text selection UI such as context menus and selection handles to the widgets library.
- The recommendation here was to not move forward with text selection UI in the widgets library at this time due to the heavy dependencies on Material and Cupertino. Bringing these components into the widgets library would result in a less stable framework as it will still be susceptible to design changes.
- The default out of the box experience for text
- Here we discussed the API usability between the framework’s text and text input offerings with Material and Cupertino’s. Specifically we looked at EditableText vs TextField and SelectionArea vs SelectableRegion.
- We are not making any changes at the moment but have identified some areas to explore after decoupling.
- The future of SelectableText
- Colors
- TabBar
- What's also up for consideration (want to add to the list? Add a comment with a suggestion!):
- Basic Button (wrapper)
- Functionality, semantics over style, for use in composing anything to be a button, would contain:
- Focus
- Semantics
- Gestures
- MouseRegion
- Related: TestButton
- Functionality, semantics over style, for use in composing anything to be a button, would contain:
- Bottom bar
- Similar to BottomAppBar/BottomNavigationBar, simpler generic interface, safe area handling
- Top bar
- Similar to App Bar, simpler generic interface, safe area handling
- Basic Button (wrapper)
Raw- widgets that pre-date this effort
This is not an exhaustive list of components available in the widgets library, but specifically those with Raw prefixes. 🙂
OP
Hi, It's been 2 months since I've ditched HTML, CSS, and JS for Flutter and I haven't looked back. I love the declarative style of Flutter and Dart itself.What's the problem?
What really bothers me is I find it hard to implement completely Custom UIs. I mean even when I wanted to use a custom font, I had to depend on material.dart and use Scaffold to make it work. I don't even want to start talking about the frustrations of theming a material app in flutter. But this was not a problem using HTML, CSS, JS. They basically give you simple and minimal elements and then let you do whatever you want with them or use whatever UI package you want, such as Tailwind, MUI, etc.
So, It's either a matter of Flutter lacking documentation on Custom UIs or me not reading enough docs about them.
Any other problems?
Well, if you just take a look at the reported issues, they're mostly about material.dart and cupertino.dart. I feel like Flutter Team is spending most of their time, effort and energy on these two UIs instead of the framework itself. And still, Flutter is far behind from Material 3 spec (and even Material 2, because material.dart uses 2014 typography by default.).
My Ideal Flutter
So my ideal is:
- The main Flutter package should contain and export basic widgets of the framework (
GestureDetector,StatelessWidget,StatefulWidget, etc.). These can be currently found inwidgets.dart. This way, Flutter Team's efforts are concentrated on the framework itself. materialandcupertinoshould come in seperate packages (and export the main Flutter package) and be maintained by Flutter community more.- More tutorials and docs should be provided on making UIs with the main Flutter package rather than making them with
materialorcupertino. This way more people will know how underlying widgets ofmaterialandcupertinowork and can take part in maintaining them or even make their own UIs in their apps and packages.
This way we will be able to see more Flutter UI packages and a more diverse set of Flutter apps in terms of UI on the market.
After all, these are just my ideals and may be far from reality but I really like to see some discussion on this matter and finding the best solution to it.