Hi Ebo, it's hard to give an abstraction that's arbitrarily right. Warning signs for the wrong abstraction would be using antipatterns, like useImperativeRef im React or any types in TypeScript.

Another good clue that you've chosen the wrong abstraction is that the code doesn't work at all. The Table example from the article was supposed to allow pagination and selection of items between pages, but that feature was not compatible with the implementation.

Thus 50% of the core functionality the app didn't work. I would rather have had 9 duplicated Tables that still needed to be refactored than a single Table that didn't work at all.

It's such an unbelievably stupid example, but literally hundreds of hours of engineering time went into a solution. So if there's one takeaway it's that abstractions are always wrong if they don't support the required functionality.

Obviously that should have been caught during code review, QA, unit testing, integration testing, and even just from code comments in the Table component explaining the desired behavior.

But if you're not doing any of those things, then you really shouldn't refactor, especially not using any types in TypeScript.

You may also enjoy this article https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

😀