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
Is your feature request related to a problem? Please describe.
If you have a theme object which uses breakpoints, like so:
{
box: {
px: ["10px", "20px", "30px"]
}
}
Then the theme will implicitly use the default breakpoints. But those defaults are not made available through the theme object. In other words, code like this will crash at runtime:
I either have to define the breakpoints in the theme object, or use the same logic as internally by theme-ui to fall back to defaultBreakpoints.
Describe the solution you'd like
Material-UI solves this nicely by fully initializing the theme config that is provided to the context so that what is made available to components at runtime contains all standard fields. The split between the theme config and the actual theme object provided at runtime is explicit. Theme config has no required fields, everything is optional and overrides the defaults. Then the theme object at runtime includes all standard fields.
It would also simplify the theme-ui internal code because you would no longer have fall back to any defaults throughout the code (for example here.
Or, at least provide a makeTheme() function that will extend the theme object with defaults, where necessary:
Is your feature request related to a problem? Please describe.
If you have a theme object which uses breakpoints, like so:
Then the theme will implicitly use the default breakpoints. But those defaults are not made available through the theme object. In other words, code like this will crash at runtime:
I either have to define the breakpoints in the theme object, or use the same logic as internally by theme-ui to fall back to defaultBreakpoints.
Describe the solution you'd like
Material-UI solves this nicely by fully initializing the theme config that is provided to the context so that what is made available to components at runtime contains all standard fields. The split between the theme config and the actual theme object provided at runtime is explicit. Theme config has no required fields, everything is optional and overrides the defaults. Then the theme object at runtime includes all standard fields.
It would also simplify the theme-ui internal code because you would no longer have fall back to any defaults throughout the code (for example here.
Or, at least provide a
makeTheme()
function that will extend the theme object with defaults, where necessary:Describe alternatives you've considered
Alternative 1: define the breakpoints in my theme object
Alternative 2: copy logic from theme-ui
Both require mit to import the defaults from the theme-ui package.
The text was updated successfully, but these errors were encountered: