I am not sure what the correct approach here is. Is it ok if I create styles with makeStyles per component or should I create one in the base component and pass down class names?
it is better to create the styles in their respective components. It'll be more manageable as all the styles don't sit in one place and will not become a huge file. Also passing down styles for each component from their parent component will create the issue of prop-drilling.
If you've some general common styles then add them to the theme file which will be more maintainable and easy to debug.
Another way to manage common styles to create makeStyles hook of common styles in a separate file and then import that hook and use it in the component wherever needed instead of passing through the prop.
Related
I am using the particles component from react-tsparticles and it takes in a props called styles and canvasClassName - where you can give it a class name (and not an object of styles).
I can use the makestyles to create a style class that I can pass to the canvasClassName however that is deprecated so what is the alternative for v5?
I need to use the theme values from mui so putting the styles into a .module.css file isnt an option
For example, if you create a makeStyles variable for a component (e.g. TableRow) and that component is called multiple times by a parent component (Table), each TableRow gets class names like “.mui-make-styles-column244” and “.mui-make-styles-column331”.
Is there a reason for this?
Can't tell if this number scheme is an optimization or if it indicates that I should be optimizing how I organize my styles.
I have two Material UI AppBars in my application. The first appbar is part of the layout of the page and appears first. However whenever the second one appears, it adds an additional style tag to the page which messes up the first AppBar and hence the page. The second AppBar is:
<AppBar position="static" color="default>
and the CSS it adds is like this:
<style data-jss data-meta="MuiAppBar>...</style>
Now there is already a style element in the header with the same CSS rules which get overridden by this.
I have tried using withStyle and className and putting the position prop as CSS to isolate the CSS rules for the second AppBar, however to no avail as the issue is with the props. What is the standard way of handling this? thanks.
Edit 1:
Upon revisiting the two components which are making use of AppBar I realized something. One was imported like this:
import AppBar from '#material-ui/core/AppBar/index'
and the other:
import AppBar from '#material-ui/core/AppBar'
When I removed the '/index' from the first, then it got fixed.
Can someone explain what is going on here? thanks.
import AppBar from '#material-ui/core/AppBar' is the correct way to import the component.
From https://material-ui.com/guides/minimizing-bundle-size/#option-1
Be aware that we only support first and second level imports. Anything deeper is considered private and can cause issues, such as module duplication in your bundle.
Adding /index turns it into a third-level import and results in module duplication and thus duplication of the styles.
In the Office Fabric UI documentation every component has two interfaces, for example
https://developer.microsoft.com/en-us/fabric#/components/nav
has
INavStyleProps interface
and
INavStyles interface
a component implementing INavStyleProps can take in any of the listed props to customize style, for example
I am wondering if there is any way to interact with INavStyles classes exposed through the documentation; essentially what does implementing the INavStyles interface guarantee to the consumer of the component, other than the listed classes and styles are implemented. Is there a way to override, customize, or otherwise interact with the classes exposed through this interface similar to how we can use props to interact with components implementing INavStylesProps.
Here is link showing the use of both interfaces for Nav. It's a how we give to Nav the default styles.
In order to override the default styles for any INavStyles area, you can use the styles prop and pass to it a styleFunctionOrObject. As you can see from the first link provided, INavStyleProps are used to pass some values to be used in the styling of the parts of the Nav or booleans to have some conditional styling. Also, that is how we pass the theme to the styles.
A style function you can pass to styles prop would look exactly as the one we use to provide the default styles minus the getGloballClassNames. Also if you want to style just one area the return type should be Partial<INavStyles> as all areas are required and it will complain if you don't provides styles for all of them.
Let me know if this cleared the confusion on how to make use of both interfaces.
I wanted to get an understanding on what people would consider best practice for layout of their react components, and if the layout styling should or should not be tightly coupled within the component itself.
Say I have a custom component that will be reused many times within the application, there may be times when I was them to be stacked Vertically down the page, with margin-bottom:20px;, whereas there may be cases I would like them spread out horizontally across the page with margin-right:20px;
It doesn't feel right if I were to have margins, or other layout attributes tightly coupled with the component? I would have thought that I should be able to render by component in isolation, without it having positional styling coupled along with it?
If you're using the component multiple times in one layout then of course the margin is not part of your component but the component that contains it.
You can use different methods to achieve your desired margin, for instance you have the css grid gap that defines just that.
However if you are using flex, you might have to pass the desired margin down to the component. So having something like this inside the component would be helpful in that case:
<div id="container" style={[styles.container, this.props.margin]}>
That way you can give it a default margin in the container style while still allowing yourself to pass a dynamic value through props when using in different places.
You could have a prop that defines the type of the component, let's say, a type prop. And you can apply the classes based on the type prop you receive with a default type.
static propTypes = { type: PropTypes.oneOf(['info', 'warning', 'error']) };
default propTypes = { type: 'info' };
and the render would look like this :
<div className={styles[this.props.type]}>content</div>
Or you can just have a single way your component look and add a className prop and/or just pass your custom styles as inline styles.
<MyComponent style={{ marginBottom: '30px' }} className="CustomStyleInClass" type="error" />
You could either use one, two or all. It depends on the component and the flexibility you need.