https://react-refs-cheatsheet.netlify.app/
First off, let me express that this is generally not the way to go about things in React land. Usually what you want to do is pass down functionality to children in props, and pass up notifications from children in events (or better yet: dispatch).
But if you must expose an imperative method on a child component, you can use refs. Remember this is an escape hatch and usually indicates a better design is available.
Previously, refs were only supported for Class-based components. With the advent of React Hooks, that's no longer the case
1.Modern React with Hooks
Documentation for useImperativeHandle() is here:
useImperativeHandle customizes the instance value that is exposed to parent components when using ref.
Adding Refs to Children Components
All examples so far assume that we needed to assign refs to native DOM elements, such as an input, and that those elements were visible to the render function. How do you proceed if that’s not the case?
One might be tempted to write something like this:
But this won’t work. The issue is that function components don’t have instances, and therefore any attempt to set a reference on it will fail.
The solution is fairly simple — although a bit odd. You define the component that should be “remotely operable” (thus forward his ref to his parent) by using a special API called forwardRef. This is especially handy when you create reusable components, as the docs point out.
Our initial example with forwardRef would look like this:
Notice that nothing changes in the parent component (besides switching from the native input element to CustomInput). The child element then uses the forwardRef API to make the input ref available to its parent.
This approach has a caveat — forwardRef only works with function components. This means that you can’t use any of the quirks that come with class components (e.g. state or lifecycle hooks) if you opt for forwardRef, unless you use Hooks.
If you really want to, you still can attach a ref to a class component. In this case you get the component instance, which means that you can call their methods from the parent. This pattern is exemplified here. Although this works, chances are that you don’t need it. Refs aren’t meant to be overused and exposing children refs to parents breaks encapsulation. The docs talk about this in greater detail.
2.Legacy API using Class Components
3.Callback Ref API
Callback-style refs are another approach to achieving this, although not quite as common in modern React:
Now, we also trigger a re-render when the state changes. This has the peculiarity of calling the callback twice: first time with null and then with the correct value.
The Case for Callback Refs
Sure, createRef provides a simple API. Still, callback refs weren’t deprecated. What’s good about them?
Consider the case when you need to create refs dynamically. Using createRef you first create and then assign the reference. This may put you in trouble when your ref does not share the same lifecycle as the parent.
Imagine a situation where the user can create a dynamic list of tasks, stacked upon each other, and each task has a button which when clicked scrolls to the task. In other words, you want this.
How would you do that?
Wrapping Up
as a rule of thumb:
Don’t overuse refs
Abolish string refs
Use callback refs when you have to dynamically set them
---When in a class component, use createRef in all other cases
---When in a function component, use useRef in all other cases
Use forwardRef when you need access to a child ref
---Use Hooks to empower your function component
---If the child ref must not be a function component, then use a custom method to trigger focus programmatically from the parent (remember you will get a component instance, not a DOM element)