I mean, as pointed out in the comments it’s fairly pointless (there is no need for the child). And you’re deliberately using inheritance, which is not a thing you should be using unless absolutely necessary. Inheritance is very useful, but in OO programming composition is normally preferable (by normally, like 99% of the time). In React, which is not based so much on OO patterns, and where component composition is absolutely central to it working, that’s closer to 100% of the time. As you say, you can memoise to get around the rerendering-all-the-time issue, but all that means is that you’re patching an issue you’ve caused. React already provides a hook (useImperativeHandle) for safely doing what you’re trying to do.
I you have explained nice, but it does not touch the intent of question.
I specifically want to understand, can we get into some trouble using that pattern.
Well, it goes against how React normally works, you’re inheriting a direct reference to a parent component. You can keep doing it: various things will break from time to time because you’re attempting to bypass how React handles things, but it’ll probably work most of the time. And you’ll have to memoise everything, because otherwise you’re going to force everything to rerender every time anything changes. You wouldn’t have the same issue all the time by sticking to how React is set up to work (you may need memoisation some of the time, but that’s par for the course). There is no good reason to do this, particularly as React already provides a safe method of doing what you’re trying to do, but go for it if you want. As a general programming truism: unless someone is holding a gun to your head saying “you need to use inheritance” then don’t use it
there is no need of memoizing specifically because of passing parent component reference, since it will not change even if the parent rerenders.
So I guess, this pattern is good enough to be followed
They aren’t complicating things, [for the third time] they already provide this functionality as part of the library, you haven’t discovered a great new method. It’s a code smell, that’s all. If you really really have to imperatively access a parent, you can use refs, that’s what they’re there for, as an escape hatch. And
useImperativeHandle makes this simpler if you are just trying to do exactly what you’re doing.
In OO programming, directly mutating properties of one object from another object (rather than via a defined interface) is a huge code smell. React isn’t so much OO, but same principle applies.
I am thankful for you giving your time,
do you mean to say, with useImperativeHandle or with ref we can achieve same feature of my example, even if yes, it looks extra complicated things being added, what could have been simply done.
See I am really not the person, that I won’t understand what other person is trying to explain, if you please can you add example for your explanation, I am not demanding, I simply feel, it’s not an easy way.
Regarding code smell, only because one class is modifying other class’s properties. We have to think twice.
the whole concept of state is there so that it can be modified internally,
whether a class itself modifies or it gives right to some child to modify – it’s kind of similar thing, it’s only delegation that is the addition
Always to note, that the parent has full control over child. if child is not acting as per parent, the child can be replaced by parent.
To add one more point, we are anyways giving every component the right to modify whole redux store by useDispatch, thus argument of code smell doesn’t hold so strong for React per se
Again I am thankful for your answers