Office Fabric UI I[component]StyleProp vs I[component]Styles interface use - reactjs

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.

Related

Refusing your app's TextStyle in a Glance widget

In a glance Text(), there's a style attribute, and this takes a glance TextStyle.
This TextStyle is different to the TextStyle you use in your MaterialTheme. So you can't reuse your app's TextStyles.
Is it possible to reuse your app's TextStyles in a glance app widget?
Note that MaterialTheme is designed for Jetpack Compose UI elements not for Glance. Given the limitations of AppWidgets (i.e no custom fonts) I would avoid reusing the theme.
We are working on a "theming" API for Glance, in the meantime you can keep the TextStyle as top-level variable and reuse it when needed.

In Material-UI v5, should I prefer the css prop over the sx prop or vice versa?

I believe these two props both use emotion under the hood and they seem to do much the same thing. I've been using the css prop because I prefer template tags and real css vs. javascript style names for css properties. Is there any reason to prefer one over the other given that they are basically interchangeable in terms of functionality?
I read the page about the new MUI styles system here: https://next.material-ui.com/system/basics/
And it feels to me that the main difference is the following:
The css prop lets you write something that looks like classic css, as you would do in actual CSS, or Less/Sass, or styled-components
The sx prop gives access to the 'system' which is a set of utilities to quickly access props with shortcuts, as well as theme properties, which already existed before v5, but are now even easier to use.... after some learning curve...
The above documentation page gives a lot of examples.

Material UI - Multiple makeStyles or one

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.

where can I find the list of allowable props or attributes for each component supported by styled-components

Starting our in react, it is easy to find tutorials that show how to start with react and styled components. I find it is easy, but it is hard to get the styling I want because I cannot find a dictionary equivalent that shows the allowable list of styled-components with a internal list of the allowable attributes or values.
For instance (only) the button component is very common, but none of the documentation shows the allowable values of say the type attribute. how would you know that the type attribute exists, and then know that there are only three allowable values button|onsubmit|reset.
Can anyone point me to a useful dictionary or cheatsheet for styled-components as used with React.
It seems you cannot find options through a typescript autocomplete method in vs code.
I realise that styled-components is a very useful layer over javascript over html and css, but is there a relevant and complete dictionary of allowed values and components - it does not seem to exist in styled-components documentation.
The lack of a reference doc for styled-component values makes it hard for me as a new starter.
While styled-components wraps CSS code it has no predefined components.
Utilising tagged template literals (a recent addition to JavaScript) and the power of CSS, styled-components allows you to write actual CSS code to style your components. It also removes the mapping between components and styles – using components as a low-level styling construct could not be easier!
Refer to MDN HTML elements reference for the list off all HTML elements and their properties.
Also, if you styling a custom component, you should be aware of its properties within the corresponding documentation (if the component from a library), or use PropTypes, Flow or TypeScript.

React component position styling best practice

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.

Resources