MUI - Slow makeStyles if using props in methods - reactjs

I have an issue where I render lots of components, where each of these components have a useStyles. We want the components props to affect the styling, so we combine props and theme settings. Works fine, except that it's incredible slow and I have narrowed it down to it being caused by having prop methods in makeStyles.
It actually doesn't matter if the class is used or not. If all classes are static it's fast, but if I add an unused class that is a method it's slow. The prop doesn't matter either, like if I add test: { fontWeight: () => 'bold' } it's going to be slow again.
Very weird indeed. I'm using Material UI ^4.11.0. Not the latest version of v4. Bug? Anyone heard of this? Anyone got a better solution for adding prop based styles and using the theme at the same time? Anyone got a performance improvement by using useMemo or anything? (It had not effect when I tried).
const useStyles = makeStyles(({ typography }) => ({
fontFamily: {
fontFamily: ({ fontFamily }: any) => fontFamily,
},
fontFamilySecondary: {
fontFamily: typography.fontFamilySecondary,
},
...filterCustomVariants(typography),
bold: {
fontWeight: typography.fontWeightBold,
},
boldScondary: {
fontWeight: typography.fontWeightBoldSecondary,
},
italic: {
fontStyle: "italic",
},
thisIsNotEvenUsed: {
fontWeight: () => {
console.log("Running running running") // Runs many times anyway!
return "bold"
},
},
}))
And the implementation:
const styleProps = { fontFamily: fontFamily }
const classes = useStyles(styleProps)
EDIT: Here are a CodeSandbox that shows this behavour, using latest MUI v4 and without my Apps complexity: https://codesandbox.io/s/black-monad-tr05l?file=/src/App.tsx

This is not a bug, makeStyles in v5 behaves the same way. The dynamic styles using callback is a JSS feature. But JSS dynamic performance has been known to be pretty terrible (see the performance section for more detail, it's about 6 times slower than emotion). That's one of the reason the MUI team decided to abandon it in favor of emotion in v5 which uses dynamic styles heavily.
And yes, it always invokes the callback even if you don't pass anything inside and don't make use of the classes object. It traverses the style object and invoke every callbacks it found when you call useStyles. For more detail about how makeStyles works, I recommend you reading this answer from Ryan.
const useStyles = makeStyles({
thisIsNotEvenUsed: {
fontWeight: () => {
console.log("Running running running"); // Runs many times anyway!
return "bold";
}
}
});
const unusedClasses = useStyles(); // generate the styles
There are some strategies to improve the performance. The easiest one (depend on the situation) is to upgrade to v5 to leverage emotion and its capability to generate dynamic styles efficiently. Another approach is to use the inline styles:
<Typography style={{ fontWeight: props.fontWeight }}>
But if you don't want to pollute your component with inline styles, you can still use makeStyles using the 'style injection' method by creating a nested styles in the container that holds a large amount of elements inside (Grid, List, Stack...)
const useStyles = makeStyles({
root: {
"& MuiTypography-root": {
fontWeight: () => 'bold'
}
}
});
<div className={classes.root}>
{[...Array(100)].map((_, index) => {
return <Text key={`text_${index}`}>Text Component</Text>;
})}
</div>

Related

MUI v5: How to generate style classes for interop with other libraries?

I am using MUI v5 together with Quill in React.
I can pass a className prop to the ReactQuill component and change it's styling:
const useStyles = makeStyles((theme) => ({
editor: {
'& .ql-editor': {
border: 'none',
// and so on...
}
}
}))
<ReactQuill className={classes.editor} ... />
Now with MUIv5 and its migration to emotion, this is not possible anymore. My workaround currently is to wrap the ReactQuill element inside a div like so:
const ReactQuillContainer = styled('div')(({theme}) => ({
'& .ql-editor': {
border: 'none',
// and so on...
}
}))
<ReactQuillContainer>
<ReactQuill ... />
</ReactQuillContainer>
But this changes the underlying DOM structure.
Is there a way to achieve the old result in the new way? I know about the css function, however I need the theme for styling and I don't think that is possible.
I also don't want to inline all those styles.
Have you solved this yet? I'm facing a similar issue, where I'd like to programmatically set MUI TextField styling on a Quill editor.
If not, have you tried passing Quill itself to styled? This works for me, though it doesn't solve my core problem. I'm also not sure it will allow you to set styles on child classes, but that may not be an issue.
const StyledQuill = styled(ReactQuill)(({ theme }) => ({
color: theme.palette.warning.main,
// and so on...
}));

Bordercolor override in Select component material ui on error

I need to override select component with border color to orange on error. Globally the outlined input bordercolor within my application is provided green. Only on error the border color has to overridden
import { FormControl, makeStyles, Select, withStyles } from '#material-ui/core';
const useStyles = makeStyles((theme) => ({
select: {
'&:before': {
borderColor: 'red',
},
'&:after': {
borderColor: 'red',
},
},
}));
const CustomSelect = ({
id,
value,
name,
variant,
onChange,
error,
priceType,
}) => {
const classes = useStyles();
return (
<FormControl size='small' error width='154px'>
<Select
id='price-type'
value={priceType}
native
name='priceType'
variant='outlined'
onChange={onChange}
error={true}
inputProps={{
style: {
width: '154px',
},
}}
className={classes.select}
>
<option value={''}></option>
<option value={'Retail'}>Retail</option>
<option value={'X-East'}>X-East</option>
</Select>
</FormControl>
);
};
export default CustomSelect;
General approach
Usually in MaterialUI when we want to override MaterialUI styles that are applied conditionally, we may use the classes prop:
classes={{ root: <class to apply always>, error: <class to apply in error state>}}
You can read about the CSS API and which classes are applicable for a given component at the bottom of its API page.
Alternatively, we can use a more elaborate approach and simply apply a rule whenever the component is in error state:
className={ error ? <class to apply in error state> : undefined }
The Select component
The Select component seems to be written at another time than most of the other MaterialUI input components. This is my intuitive impression based on API and code style but I might be wrong. Nevertheless, the Select component uses one of Input, FilledInput or OutlinedInput depending on the value of the variant property. Since you use outlined, I will continue this answer with OutlinedInput in mind. I will also use the color green for the border instead of orange because its distinction from red is more clear.
Naively, I would tackle the problem by looking at the CSS API of the Select component, and then also look closer at the OutlinedInput to which remaining properties of the Select component are spread. No applicable CSS API class exists on the Select component to reach your goal, but the OutlinedInput has a class error with the following description:
Pseudo-class applied to the root element if error={true}.
If we inspect the OutlinedInput in the development tools, we can see that the element that has the border is a fieldset residing inside the root element of the OutlinedInput (note: not the root element of the Select). If we use the error class, we will end up with an additional class applied to the root element of the OutlinedInput which is not what we want. Nonetheless, we could apply a class that refers to the aforementioned child element... this would work.
There is also a css class notchedOutline which we can see is applied to this fieldset resulting in the border. The dilemma here is that if we would be able to add some css to this class, then it would be applied at all times on the fieldset, but we want to apply it ONLY in error state.
This gives us four possible strategies to affect the css via the CSS API:
Add css conditionally (when in error) to the root class of the underlying OutlinedInput that targets child notchedOutline.
Add css to the root class of the underlying OutlinedInput that targets error state and child notchedOutline.
Add css to the error class of the underlying OutlinedInput and target child notchedOutline.
Add css conditionally (when in error) to the notchedOutline class of the underlying OutlinedInput.
Note that the second one and third are preferable in that they do not require us to add a class conditionally; this is handled by MaterialUI.
In the best of worlds, I would want the Select component to forward all of its non-existing props to the element it uses internally, in this case an OutlinedInput, but apparently, it does not forward portions of elements that it partially supports (the classes prop). This means that if we supply classes.error or classes.notchedOutline, MaterialUI will complain with
Material-UI: The key `XXXX` provided to the classes prop is not implemented in ForwardRef(Select).
instead of forwarding the prop to the underlying OutlinedInput. I do not know if this is a bug or not, but this is how it works currently.
This implies that we can not use any of the above four strategies via the classes prop of the Select component. A workaround is to use the Select className prop which is forwarded to the OutlinedInput which in turn forwards it to InputBase which forwards it to the native element, which is the same as the root element of the OutlinedInput. So, if we could access the underlying OutlinedInput itself, we could use all of the above strategies, otherwise only the first two (and then via className prop of the Select).
The solutions
1. Set the global error color of the entire app
If you want the error color to be something else than red for the entire app, then provide a theme which changes the color used for errors. This is the best approach since it also changes the color of helper texts and labels which would otherwise have a different color than the border of your Select input.
import green from '#material-ui/core/colors/green';
const theme = createTheme({
palette: {
error: {
main: green[500]
},
},
});
This is a clean and non-hacky way to do it and the one I recommend. However, if you DON'T want the general color for errors to be changed, this might not be a good solution, even though you could wrap just a local part of the app in a theme of its own.
2. Override the class used for notchedOutline in error state
This is a broad way to solve it since you can do this in several different ways using the four strategies described above. The downsides with all the solutions are that they are more or less hacky and that they only affect the border of the Select, implying that helper texts and labels will be differently colored than the border when the component is in error state (you could add styles to them too, making all of this very elaborate and hard to achieve).
2.a Global override / default for OutlinedInput
We can create a theme with a global override for the OutlinedInput. Since we then manipulate the OutlinedInput itself, we may use all four strategies from above.
Global override / default for OutlinedInput for root class targeting notchedOutline child
This theme would have to be applied conditionally only when the component is in error state. This is elaborate and not a good alternative.
Global override / default for OutlinedInput for root class targeting error state and notchedOutline child
const themeWithOverrides = createTheme({
overrides: {
MuiOutlinedInput: {
root: {
"&$error": {
"& $notchedOutline": {
border: "1px solid green"
}
}
}
}
}
})
This one works well and targets the OutlinedInput root class with css that applies only when it is in error state and applies to its notchedOutline child. The selectors refer to the css classes already defined by default in the theme for this component.
Global override / default for OutlinedInput for error class and notchedOutline child
const themeWithOverrides = createTheme({
overrides: {
MuiOutlinedInput: {
error: {
"& $notchedOutline": {
border: "1px solid green"
}
}
}
}
})
This solution results in an error message from MaterialUI
Material-UI: The `MuiOutlinedInput` component increases the CSS specificity of the `error` internal state.
which in turn recommends us to use the previous solution targeting the root class instead.
Global override / default for OutlinedInput for notchedOutline class
const themeWithOverrides = createTheme({
overrides: {
MuiOutlinedInput: {
notchedOutline: {
border: "1px solid green"
}
}
}
})
This will apply the style at all times which we don't want, so the theme has to be applied conditionally which is a hassle so this solution is not recommended at all.
2.b Css classes for Select component
Here we could also, in theory, use all of the four strategies described above. However, since we are not manipulating the OutlinedInput itself, and since MaterialUI doesn't forward the classes props that are not defined for the Select to the underlying component, only two remains.
Adding css class conditionally to className prop of the Select which is applied to the OutlinedInput root component targeting child notchedOutline
const useStyles = makeStyles((theme) => ({
errorState: {
"& .MuiOutlinedInput-notchedOutline": {
border: "1px solid green !important"
}
}
}))
...
<Select
...
className={ errorFlag ? classes.errorState : undefined }
...
</Select>
This solution both uses literal MaterialUI css classes and requires us to conditionally add the class. Finally, we have to use the !important modifier to override the specificity of the MaterialUI default behaviour. All in all, this has a slightly hacky flavour to it.
Adding css class to className prop of the Select which is applied to the OutlinedInput root component targeting child notchedOutline only in error state
const useStyles = makeStyles((theme) => ({
errorState: {
"&.Mui-error": {
"& .MuiOutlinedInput-notchedOutline": {
border: "1px solid green"
}
}
}
}))
...
<Select
...
className={ classes.errorState }
...
</Select>
This is slightly better because we don't need to conditionally apply the style. Also, as long as this style is injected after the MaterialUI default style, we can omit the !important modifier since this rule achieves the same specificity as the MaterialUI default behaviour. This method is absolutely preferable over the previous.
2.c Css classes for underlying OutlinedInput component via input prop on Select
The Select component takes a prop input which lets you define your own input components to be used. Here we can use a custom component that returns an OutlinedInput with the modifications you want.
export default function CustomInput(props) {
return (
<OutlinedInput
{...props}
<CHANGES HERE>
/>
)
}
Since we here can work directly towards the OutlinedInput, we can use its CSS API and thus use all the four strategies described earlier.
Note that to do it by the book, you should merge incoming classes.error and classes.notchedOutline with the classes you assign by default as well.
Adding css class conditionally to classes.root prop targeting child notchedOutline
Since we now have access to the classes.error prop, providing this class conditionally would not be a smart option.
Adding css class to classes.root prop targeting state error and child notchedOutline
Similarly, since we now have access to the classes.error prop, providing a class here targeting error state instead of targeting it directly would be an extra workaround and is not recommended.
Adding css class to classes.error prop targeting child notchedOutline
const useStyles = makeStyles((theme) => ({
error: {
"& .MuiOutlinedInput-notchedOutline": {
border: "1px solid green !important"
}
}
}))
export default function CustomInput(props) {
const classes = useStyles()
return (
<OutlinedInput
{...props}
classes={{ ...props.classes, error: classes.error }}
/>
)
}
This is a good alternative that allows us to leave the decision of whether the component is in error state or not to MaterialUI. Slightly hacky to use the literal MaterialUI css classes and that we have to provide the !important flag to override the higher specificity of the MaterialUI default behaviour.
Adding css class conditionally to classes.notchedOutline prop when in error state
const useStyles = makeStyles((theme) => ({
errorOutline: {
border: "1px solid green !important"
}
}))
export default function CustomInput(props) {
const classes = useStyles()
return (
<OutlinedInput
{...props}
classes={{ ...props.classes, notchedOutline: errorFlag ? classes.errorOutline : undefined }}
/>
)
}
This is equally good as the previous. It saves us from using literal
MaterialUI css classes but it forces us to add the class conditionally. Also here we have to provide the !important flag to override the higher specificity of the MaterialUI default behaviour.
Conclusion
It's a shame that it seems to be quite complicated to change such a simple thing. Nonetheless, the best solutions seem to be:
Use global error color override if you want to have a robust solution with uniform appearence for all inputs in your app that harmonize with labels and helper texts.
import green from '#material-ui/core/colors/green';
const theme = createTheme({
palette: {
error: {
main: green[500]
},
},
})
Use global override for OutlinedInput if you want a uniform error color across all OutlinedInputs and if you're ok with labels and helper texts that don't harmonize.
const themeWithOverrides = createTheme({
overrides: {
MuiOutlinedInput: {
root: {
"&$error": {
"& $notchedOutline": {
border: "1px solid green"
}
}
}
}
}
})
Use a custom input which conditionally overrides the classes.notchedOutline when the component is in error state if you need a one-time change on a single or couple of Selects / OutlinedInputs and if you can accept labels and helper texts that don't harmonize in color. I prefer this solution because I don't like to use literal MaterialUI css classes in my code.
const useStyles = makeStyles((theme) => ({
errorOutline: {
border: "1px solid green !important"
}
}))
export default function CustomInput(props) {
const classes = useStyles()
return (
<OutlinedInput
{...props}
classes={{ ...props.classes, notchedOutline: errorFlag ? classes.errorOutline : undefined }}
/>
)
}
...
<Select input={<CustomInput error={errorFlag} />} />
...
Here is a code sandbox with some of these recommended examples
You can use this styles
const useStyles = makeStyles((theme) => ({
select: {
borderColor:'#f00',
'&:focus': {
borderColor: '#f00',
},
},
}));

How can I consistently overwrite JSS styles which have indeterminate suffixes?

I’m looking for advice around #material-ui/core in react,
TLDR;
I would appreciate a consistent approach for handling CSS-in-js generated classNames which have indeterminate numeric suffixes, while still using #material-ui/core's styled() function if possible.
Specifically
“the class names generated by #material-ui/core/styles are non-deterministic” (https://material-ui.com/styles/advanced/#class-names), but so far at my company the projects I’ve been on have used the styled() function for wrapping components to apply styles.
It works great, until I want to overwrite how one of the pseudo-classes applies to the root element that I’m styling. At which point, if I try to use a regular old class-selector to take control of the styling in ta specific state, it’ll work if there’s no suffix on the class, but as soon as the JSS generated className has a numeric suffix, it breaks.
When I say "suffix" I'm referring to how a component's root className might be .makeStyles-root but when the className is generated for that specific instance, it likely has a numeric suffix appended: .makeStyles-root-123
For example:
Component: InputLabel https://material-ui.com/api/input-label/#inputlabel-api
I want to fiddle with the transform that happens, which comes from .MuiInputLabel-formControl, but then that transform is overwritten by .MuiInputLabel-shrink.
If I try using a regular class selector:
export const InputLabel = styled(MuiInputLabel)({
`&.MuiInputLabel-formControl`: {
transform: 'translate(2px, 8px) scale(1)',
},
`&.MuiInputLabel-shrink`: {
transform: 'translate(0) scale(0.6)',
},
});
It works only if the JSS class doesn’t have a suffix,
and if I try using the rule names (I don’t think it’s actually supported with styled())
export const InputLabel = styled(MuiInputLabel)({
formControl: {
transform: 'translate(2px, 8px) scale(1)',
},
shrink: {
transform: 'translate(0) scale(0.6)',
},
});
It just applies invalid rules to the element:
formControl: [object Object]
shrink: [object Object];
I've also tried passing classes (but that didn't seem to work at all)
export const InputLabel = styled((props) => (
<MuiInputLabel
classes={{
formControl: {
transform: 'translate(2px, 8px) scale(1)',
},
shrink: {
transform: 'translate(0) scale(0.6)',
},
}}
{...props}
/>
))({});
Further Notes
I don’t want to use a theme override (which I imagine would enable the use of those rules here) because I don’t want this styling to apply to all instances of a InputLabel
so that leaves me leaning towards using the hook api / makeStyles() : https://material-ui.com/styles/basics/#hook-api
But that doesn’t lend itself well to current patterns with style files.
Related
I've seen these similar questions:
jss to override a material-ui nondeterministic class
How override material ui style with hooks
the difference is that I'm trying to avoid using the hook api if possible.
As far as I can tell, it isn't possible to do this with styled(),
so I've just gone with what other posts have suggested and used makeStyles().
However I have used a bit of a mash-up of the two, so that I can still keep my styling in a separate file.
const useLabelStyles = makeStyles((theme) => ({
root: {
color: theme.text.primary,
},
formControl: {
transform: 'translate(2px, 8px) scale(1)',
},
shrink: {
transform: 'translate(0) scale(0.6)',
},
}));
export const InputLabel = styled((props) => {
const theme = useTheme();
const classes = useLabelStyles(theme);
return (
<MuiInputLabel
classes={classes}
{...props}
/>
);
})({});

Dynamic values in material ui's makeStyles

I have some styles stored in a database so users can restyle their components - along the lines of:
const stylesFromDatabase = {
backgroundColor: "blue",
color: "red"
}
Is it possible to bring these styles into material UI's makeStyles - perhaps something like this?- edited -
const useStyles = makeStyles(theme => ({
textField: stylesFromDatabase => ({
width: "100%",
...stylesFromDatabase
}),
Alternatively, is there anything I can use to smoosh together the classes generated by makeStyles and a javascript object?
Yes, It's absolutely possible to include a JavaScript object into makeStyles.Thanks to the spread operator.
Advice is to spread over the object first, so that you can easily override any styles.
Therefore it's preferred to do as follows.
const useStyles = makeStyles(theme => ({
textField: {
...stylesFromDatabase, // object
width: "100%",
color: "green", // this would override "red" (easier fine tuning)
},
});
For the benefit of future posters, the code in my original post worked perfectly, I just had something overriding it later! (Without the callback function it was undefined) – H Capello just

material-ui: AppBar: strategy for restricting an image height to AppBar height?

can anyone provide guidance around an idiomatic way to place an image in an AppBar and have it be restricted to the standard material height (e.g. 64px for a desktop)?
i'm currently using material-ui#next (1.0.0-beta.2 currently).
i have found that something like:
<AppBar>
<Toolbar>
<IconButton color="contrast" aria-label="Menu">
<MenuIcon />
</IconButton>
<img src={logo} style={{height: 64}}/>
<Typography type="title" color="inherit">
React Scratch
</Typography>
</Toolbar>
</AppBar>
works well.
the actual logo is a png file with a height greater than 64, so if i don't ratchet it down, it expands the height of the AppBar out of Material spec.
in the current master branch version of src/styles there is a getMuiTheme.js which seems to deliver this height readily, but in the #next version i am looking at, that file doesn't even exist and tbh, i can't easily determine how that height is being set anymore.
i found that the AppBar is currently being renovated for composability, so that churn might make it challenging to answer this question, but just in case anyone has a good handle on this, i figured i would toss the question out there.
thanks!
In all cases I've seen, an AppBar is implemented with a Toolbar as it's first child. The Toolbar's stylesheet dictates it's height based on the breakpoints defined in the theme.
Take a look here: https://github.com/callemall/material-ui/blob/v1-beta/src/Toolbar/Toolbar.js
You can use a similar approach to define a stylesheet with a class for your AppBar images that varies the height for the applicable breakpoints. Then when rendering the component, apply the class to your image.
Note: if you use the withStyles HOC, as is done in the Toolbar, AppBar etc, the classes defined in that stylesheet will be available through a prop named classes.
You are right about the AppBar's need for composability, but that issue has not been solved yet, and this is the beta branch anyway. When it is solved, there should be a better solution that would be worth migrating towards.
I hope this answer helps. I would have added code samples but I am answering from my phone while waiting in a grocery store parking lot. If I get a chance I will update this answer.
Here's one approach, duplicating the styles in a new reusable component:
import createStyleSheet from 'material-ui/styles/createStyleSheet';
import withStyles from 'material-ui/styles/withStyles';
// define these styles once, if changes are needed because of a change
// to the material-ui beta branch, the impact is minimal
const styleSheet = createStyleSheet('ToolbarImage', theme => ({
root: {
height: 56,
[`${theme.breakpoints.up('xs')} and (orientation: landscape)`]: {
height: 48,
},
[theme.breakpoints.up('sm')]: {
height: 64,
},
},
}));
// a reusable component for any image you'd need in a toolbar/appbar
const ToolbarImage = (props) => {
const { src, classes } = this.props;
return (
<img src={src} className={classes.root} />
);
};
// this higher order component uses styleSheet to add
// a classes prop that contains the name of the classes
export default withStyles(styleSheet)(ToolbarImage);
Another approach is to add the standard toolbar heights to the theme as business variables, override the root class for all Toolbars so that it makes use of them, and use the theme whenever you need to reference them again:
// define the standard heights in one place
const toolbarHeights = {
mobilePortrait: 56,
mobileLandscape: 48,
tabletDesktop: 64,
};
// create the theme as you normally would, but add the heights
let theme = createMuiTheme({
palette: createPalette({
primary: blue,
accent: pink,
}),
standards: {
toolbar: {
heights: toolbarHeights,
},
},
});
// recreate the theme, overriding the toolbar's root class
theme = createMuiTheme({
...theme,
overrides: {
MuiToolbar: {
// Name of the styleSheet
root: {
position: 'relative',
display: 'flex',
alignItems: 'center',
minHeight: theme.standards.toolbar.heights.mobilePortrait,
[`${theme.breakpoints.up('xs')} and (orientation: landscape)`]: {
minHeight: theme.standards.toolbar.heights.mobileLandscape,
},
[theme.breakpoints.up('sm')]: {
minHeight: theme.standards.toolbar.heights.tabletDesktop,
},
},
},
},
});
Then you can reference these heights in any stylesheet you create because they're part of the theme.
UPDATED FOLLOWING THE RELEASE OF 1.0.0-beta.11:
There is now a toolbar mixin available on the theme that provides the toolbar minHeight for each breakpoint. If you need to style an element relative to the standard height of the AppBar component, you can use this object to build your own styles:
const toolbarRelativeProperties = (property, modifier = value => value) => theme =>
Object.keys(theme.mixins.toolbar).reduce((style, key) => {
const value = theme.mixins.toolbar[key];
if (key === 'minHeight') {
return { ...style, [property]: modifier(value) };
}
if (value.minHeight !== undefined) {
return { ...style, [key]: { [property]: modifier(value.minHeight) } };
}
return style;
}, {});
In this example, toolbarRelativeProperties returns a function that will return an object that can be spread into your style object. It addresses the simple case of setting a specified property to a value that is based on the AppBar height.
A simple usage example would be the generation of a dynamic CSS expression for height calculation, which is depending on the standard height of the AppBar:
const componentStyle = theme => ({
root: {
height: toolbarRelativeProperties('height', value => `calc(100% - ${value}px)`)(theme)
}
});
The generated style definition might look like this:
{
height: 'calc(100% - 56px)',
'#media (min-width:0px) and (orientation: landscape)': {
height: 'calc(100% - 48px)'
},
'#media (min-width:600px)': {
height: 'calc(100% - 64px)'
}
}

Resources