Hey ebo! I can tell I like your coding style. As you put it, a "well-defined interface of events and callbacks" is exactly what you need as the right abstraction.

In the case of the Table I described, the parent could easily do those "grander things" if it was getting well-defined callbacks. That wasn't the case.

We could also just hook into the related element (Chart) directly. I totally agree there's not a great need for a global state store in this particular case.

You've obviously documented exactly how the interaction works (from the "checked" state inside the Table on to the callbacks causing behavior).

Indeed, if I was still working on that project, I would consider your suggestion. It's possible to refactor so that all of the events are being handled well, with checked state inside the Table component.

I guess the idea is to consider something like "events that happen as a result of a checked action" when refactoring code that handles checked state.

Indeed, that's why I think some of the best abstractions in frontend development are presentational components, with business logic in certain parent components and/or custom hooks.

It sounds like you weren't "hasty" (beware hasty abstractions - BHA) with your own Table abstraction, and it's worked well for you. Awesome!