[tomelders]

But you’re still creating a suite of components that can be composed to create a specific instance of a date picker. Except with the override config, you’re now complicating and limiting the simple and versatile concept of composition.

Your components now need to follow some pre established and short sighted rules in order to understand how to manage their own children.

To use the example in the article, lets say you have an Option component, but now you want a version of that component that takes two additional components under certain conditions. E.g, an icon, and a checkbox? But only when one specific Option has a specific combination of props?

How does this override system handle that? It doesn’t. Composition handles that. But if components are created with this override system in mind, they lose the ability to be composed in more complex ways than the designer of the override system imagined.

[tomelders]

It turns out I was wrong about this, but not in a good way.

It appears you can pass functions to the config that render components, which presumably can also take an override config which in turn can take a function to render components and so on. So it's basically negating the entire point of JSX. It's halfway between JSX and React.createElement. The worst of both worlds.

[Aeolun]

I don’t see the problem? Override the option component with a new one that adds a checkbox or radio if a specific combination of parameters is passed: