Material-ui: Migrate from findDOMNode to refs

[TrySound]

React team just finally announced deprecating findDOMNode.

https://github.com/facebook/react/pull/13841

Would be good to start providing better refs in each component to get rid from RootRef.

Edit @eps1lon: Hijacking OP to document progress.

If we need the DOM node we still use findDOMNode but we call it with refs. If the refs are attached to host components you won't get a strict mode warning. Only if they are attached to class components.

Strict-mode ready findDOMNode

• [x] [Slider](https://github.com/mui-org/material-ui/tree/next/packages/material-ui-lab/src/Slider/Slider.js)
• [x] [ButtonBase](https://github.com/mui-org/material-ui/tree/next/packages/material-ui/ButtonBase/ButtonBase.js)
• [x] [ClickAwayListener](https://github.com/mui-org/material-ui/tree/next/packages/material-ui/ClickAwayListener/ClickAwayListener.js)
• [x] [MenuList](https://github.com/mui-org/material-ui/tree/next/packages/material-ui/MenuList/MenuList.js)
• [x] [Modal](https://github.com/mui-org/material-ui/tree/next/packages/material-ui/Modal/Modal.js)
• [x] [Popover](https://github.com/mui-org/material-ui/tree/next/packages/material-ui/Popover/Popover.js)
• [x] [Portal](https://github.com/mui-org/material-ui/tree/next/packages/material-ui/Portal/Portal.js)
• ~[ ] [RootRef](https://github.com/mui-org/material-ui/tree/next/packages/material-ui/RootRef/RootRef.js)~ compat module
• [x] [Slide](https://github.com/mui-org/material-ui/tree/next/packages/material-ui/Slide/Slide.js)
• [x] [SwipeableDrawer](https://github.com/mui-org/material-ui/tree/next/packages/material-ui/SwipeableDrawer/SwipeableDrawer.js)
• [x] [TextField](https://github.com/mui-org/material-ui/tree/next/packages/material-ui/TextField/TextField.js)
  

[eps1lon]

I believe this would be a breaking change. The API allows in many cases that users pass a custom root component. We still need findDOMNode if those components don't forward their refs properly.

[oliviertassinari]

This is such a big move from React. For a long time, I thought they weren't going to execute on this. From what I understand, the motivation is around simplifying React internal core. This makes sense. Let's see how we can fulfill this new constraint.

[eps1lon]

React 16.6 will log deprecation warnings in strict mode about this. Will be good way to gauge the impact of this change

[TroySchmidt]

This is also important because React recommends passing StrictMode before enabling concurrent React. It is unstable right now but should be finalized this year.

[eps1lon]

This is also important because React recommends passing StrictMode before enabling concurrent React. It is unstable right now but should be finalized this year.

This is the actual driving factor for us. We've made some progress but react-transition-group will probably be the last remaining blocker. Unless we fork it but it's quite a bit of bundle bloat we would introduce if react-transition-group is used in other parts of the app bundle.

[eps1lon]

findDOMNode remains in the codebase for backwards compatibility with class components. If you forward refs to host instances where necessary you should get no more deprecation warnings in StrictMode.

For more details see https://material-ui.com/guides/composition/#caveat-with-refs

[NMinhNguyen]

@eps1lon

you should get no more deprecation warnings

Is that because findDOMNode(validElementRef) is safe?

backwards compatibility with class components

Can't class components be wrapped in forwardRef as well? Or do you mean that you don't want yet another breaking change and for existing class components (that do not correctly forward refs) to work?

[eps1lon]

Or do you mean that you don't want yet another breaking change and for existing class components (that do not correctly forward refs) to work?

Yes. Just reducing the amount of breaking changes.

Is that because findDOMNode(validElementRef) is safe?

At least for now. We're still waiting for an official confirmation but so far findDOMNode doesn't throw if called with host instances.