What is the common practice when a parent component needs to update its state when there are events in the child component that happened (mouseover, clicked)? A Should the parent pass its state to the child through props, and then child will simply update the state when event happened? B The parent will pass callback event handlers to the child through props, and then the child will call the event handlers that the parent passed? Then the event handlers of the parent will be the one updating the state? (this seem like more of react model) Or is there another way?

B for sure

A couples the childs code to the parents state. if you want to re-use the child somewhere else, you would have to ensure that wherever you use it passes in the state the same way. And if you want to change the parent, you need to change the child as well

using callbacks allows the child to declare its interface, and then whoever uses it can structure their state however they want and pass in callbacks to map back to their state

I agree. I am also in favor of B To put it in context. I am creating an audio player component. The audio player has child component progress bar , and I'm thinking the progress bar is tightly related to its parent audio player. It feels like I'm moving the progress bar as separate component just for readability purpose (I could be wrong). In this context, do you think option A makes more sense?

The events so far are, when the progress bar was clicked, move the current time of the audio relative to the position where it has been clicked.

I still don’t, because if you decide to rewrite the your audio player parent, you shouldn’t have to have to rewrite your progress bar as well

at the end of the day, you can try it out and see how it works. I don’t think it will make your project untenable. But if we’re bikeshedding, I think it should be B 😄

😄 yeah, thanks a lot. It's good to know how others are doing it

I humbly submit that this A vs B topic isn't bikeshedding. In my job we have a handful of global dev teams, 5-10 devs per team, working on (among other things) a large SPA that's been around over 10 years. It's extraordinarily hard to keep control over keeping everybody consistent in our approach to "component architecture" I guess you'd call it (we're using a Model View Presenter approach that predates React/Vue/Angular by some years). The moment some developer sneaks in something like A, which is basically a "tight coupling" violation, it's flabbergasting how bad code examples spread like a damn virus. So even when making a small app, personal project, pet learning hobby, etc., I really like to keep things nicely architected. You never know when you're going to go back to that example to make something more important. 😄

thank you for sharing. It's hard to find info about this topic through google search.