This seems to be more than just a thin wrapper like https://github.com/rainerschuster/final-form-material-ui was. I kind of prefer the simplicity of focus of final-form-material-ui.

This appears to be attempting to do too much. Though if it gives you exactly what you want, great.

The callback seems to receive 2 arguments. e and reactChild

In the past I got the selected value using e.target.value This seems to work.

Not sure of the use of the reactChild element that the callback receives.

Another important note regarding recording the recorded value of the select is noted in the "value" prop explanition ( below, on this very page )

You might want to turn it into a span for any number of reasons. eg if you want one word in a sentence to be another color / style eg. I wear a red hat

<Typography component="div" > Contact Details : <Typography component="div" display="inline" variant="body2" color="black"> elroinoronha2@gmail.com </Typography> </Typography>

(copy it to a code editor for the code to make sense)

is a good solution since it defeats the "h1 cannot be a child of h1" DOM error + let us use the sx prop.

We would not be able to use sx prop to style the inline part if we would use the native <span> component ie. <Typography > yo mama <span> so fat </span> </Typography>

You would have to use inline style styling instead.

This <Box/> method is the preffered way of doing it. The <Paper/> method too is a good idea. The basic reasoning is that only MUI components support the sx prop ie. only they can fully use the MUI systems features. Thus, it doesnt make sense to use the native <img/> component in the markup, as it does not support sx

The SX prop does not work with non MUI components eg. native <img/> component. To style this, you will have to use the native inline styling ie. <img style=" ............". /> If you want to style the img and use some MUI system specific features, ie. you need to use sx ; do the following. Use <Box component="img" sx={{ }} /> instead. This supports the sx prop, thus your image will be customizable with sx prop.

The color prop does not support all MUI theme colors / their shades DIRECTLY through its color prop. Eg. The color prop supports primary but not primary.main/dark. It does not support the palette warning color at all.

To remedy this you have 2 options 1 BETTER -- give the icon the desired color through the sx prop OR 2. wrap the icon in a box and give the box to desired color

I guess this is what we would use for a popover, but why doesn't https://material.io/components/ (neither https://www.material.io/components/menus nor https://material.io/components/tooltips) say anything about popovers?

Looking for effective design solutions? We create simple, clean, and attractive mobile app designs for business.

These tags belong to entire page. This quote is just supporting evidence for the tags.

Too bad I have to choose between Material Design (Material UI) and https://www.ag-grid.com (which has a lot more features).

source code at: https://github.com/foxhound87/mobx-react-form-demo/blob/master/src/components/forms/FormRegisterMaterial.jsx

Example showing how to use inputRef on a <Select>

It's surprising that they show an example using styled-components, which is a competing style library to their own @material-ui/styles, and even admit that this might be preferred over using the classes API, which they admit may be cumbersome.

I like that they are open-minded enough to acknowledge that there are cases where built-in API may be too cumbersome, and even show examples of using styled-components.

Demonstrates how label text will wrap at a point that appears to narrow when shrunk (the label can't even be as wide as the input it is labeling!), and how to work around this problem by adding styles:

  '& label': {
    whiteSpace: 'nowrap'
  }

Of course, you would only want to do this if you are going to only be showing the label in shrunk state (which I think is safe to say is the case for date picker inputs), since it would look bad to actually have text overflowing outside of the input box. But if it's in "shrink" state, then it's actually above the input, so as long as there isn't another input/label directly to the right, and/or as long as we adjust the width so the right side of the label mostly lines up with the right side of the input, then I think we should be safe.

Reference

The input label "shrink" state isn't always correct. The input label is supposed to shrink as soon as the input is displaying something. In some circumstances, we can't determine the "shrink" state (number input, datetime input, Stripe input). You might notice an overlap.

To workaround the issue, you can force the "shrink" state of the label.

You need to make sure that the input is larger than the label to display correctly.