Short Answer: This approach in your scenario is alright. Just re-visit it when your scenario get change.


It's not an anti-pattern in your scenario. It will be consider an anti-pattern, if you are controlling behavior of child component through ref.

React suggest to avoid such anti-patterns as general advise to avoid edge cases where your component become unstable as it get controlled by different source of truth. But, in the scenario like yours where you are sure about why you are using it, it's fine.

For example, React advise not to populate state from props. This is true because then you have two source of truth and you need to sync them otherwise your component will not behave properly. But, If you are sure that, your props (specifically data) will not be going to change, it's no longer an anti-pattern because, you are now seeding state from props but then it continue to manage at state level only.


Short answer


Long answer

From React's doc on refs:

In the typical React dataflow, props are the only way that parent components interact with their children. To modify a child, you re-render it with new props.

Your first inclination may be to use refs to “make things happen” in your app. If this is the case, take a moment and think more critically about where state should be owned in the component hierarchy.

Refs were created to access the DOM in specific use cases (focus, text selection, media playback, third party libs, etc), but they shall be avoided when trying to make other components execute actions.

So of course you can have a React app that works while using refs to call child component method, but yes, it is very anti-pattern.

Related Query

More Query from same tag