You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Design system elements are more powerful when used together with proper Theming in a Flutter app. If developers simply use static properties like Color throughout a codebase, then those UI elements will not dynamically update on theme changes: for example, if a user switches from dark to light mode.
Enforcing strict usage of Themes throughout a codebase is necessary for these cases. Additionally, we'll need to consider use cases such as defining Theme extensions for custom Widgets (e.g MyPrimaryButton).
Text themes specifically are more prone to inline editing (e.g. adding boldness to a particular Text widget). We will need to understand if there's a non-inline way of modifying themes.
Another potential problem is that Material Theme has many fallback themes, in case one is not explicitly specified at the Widget or App levels. If we have an off-white in our design system, but we don't use that off-white anywhere in our App theme, do we throw a lint if a Text widget uses a white from the default Material Theme and not the off-white from our design system? We need to understand the inner workings of Theme and Material's fallback themes to come up with a sustainable solution.
The text was updated successfully, but these errors were encountered:
Design system elements are more powerful when used together with proper Theming in a Flutter app. If developers simply use static properties like
Color
throughout a codebase, then those UI elements will not dynamically update on theme changes: for example, if a user switches from dark to light mode.Enforcing strict usage of Themes throughout a codebase is necessary for these cases. Additionally, we'll need to consider use cases such as defining Theme extensions for custom Widgets (e.g
MyPrimaryButton
).Text themes specifically are more prone to inline editing (e.g. adding boldness to a particular Text widget). We will need to understand if there's a non-inline way of modifying themes.
Another potential problem is that Material Theme has many fallback themes, in case one is not explicitly specified at the Widget or App levels. If we have an off-white in our design system, but we don't use that off-white anywhere in our App theme, do we throw a lint if a Text widget uses a white from the default Material Theme and not the off-white from our design system? We need to understand the inner workings of Theme and Material's fallback themes to come up with a sustainable solution.
The text was updated successfully, but these errors were encountered: