Is it too expensive to check if the instance shares some base class before switching to Polymorphic? What about patterns like this:

render(props) {

}

Can the render function be downgraded if it’s called with different prop object shapes?

This works for class/vtable based programming languages, but not for languages with prototypal inheritance like JavaScript. The "same base class" doesn't matter, since the methods are on different prototypes.

In #inline-cache-states is there any reason why A and B could not be considered as the same shape assuming that two inline objects a = {foo(){}, constructor(){}} and b = {foo(){}, constructor(){}} are.

The prototypes are part of the shape, so they can naturally not share the same hidden class.

"Write idiomatic JS" they said... 😉

Thank you for sharing the knowledge. Will try this out.

This doesn't change anything wrt. "idiomatic JavaScript". You cannot solve everything in the VM, sometimes you just hit the limits of the VM with your application, and then it's good to have a way out, which is what my post is all about. This is probably something that only very, very few people need to actively worry about.

Right. That's totally clear to me and I accept it. Sharing this knowledge is amazing, interesting and for some people very useful.

The slightly tricky part for the general reader is to tease apart universal/common best practice advice vs special-cases. Maybe there could be a disclaimer link or "nicheness" rating at the top of each article to express it as you just did now.

Makes sense, thanks. I added a "Disclaimer" to highlight that this is probably not going to affect the vast majority of developers. 😎

Is this something userland should fix/work on (e.g. using ESLint to check for that... if that's a thing) or should React's team be worry about it?

For most smaller applications, the VM will be just fine, as shown above. But we'll try to follow up with React folks on this.