What you describe in the first paragraph is exactly what you can do with overrides as well. Again, it gives you access to any subcomponent in the component and you can replace it with your own component.
Note, that you can replace a single layer and pass the "children" through OR "replace the whole branch" of subcomponents when NOT passing the children through.
Also all overrides get various state props. For dnd-list, it can be something like $isDragged, so you can conditionally render different things.
At the same time, every Base Web component is exporting all these subcomponents. For example, component DND List also exports:
You are free to use these Styled subcomponents and recompose them any way you wish. You can build your own component from scratch (this approach works great for tables) or you can use overrides and utilize existing state handling etc.
Give me specific example: What customization of dnd-list you can't make with the existing overrides API and what other API would allow you to do that better.
That is not better. Just look at what you've created vs the idiomatic way of accomplishing the same thing with vanilla React. It's a new DSL on top of React that just adds unnecessary noise. It over complicates what should be a simple task.
Why do I have to specify "List" twice? And what sort of magic is "component" performing? What are children now? Do they not exist anymore? And what does "overrides" mean in this context? Passing children to a component is not an "override".
I think you're drunk on your own hype buddy. Maybe this all makes perfect sense to you, but it looks like garbage to me.
As a person reading this who was ready and waiting to celebrate a better standard way to override custom components... These two examples are night and day. Vanilla is way less convoluted. There better be a very convincing argument (and I guess I'll go read the official Uber reasoning) that explains why this extra magic is necessary.
I think you're being overly harsh. Literally the only difference is
overrides={{ Item: { component:
instead of:
renderItem={
(personally I'd probably have a shortcut to allow leaving "{ component:" off though)
I don't think that's a bad tradeoff to render props support (plus prop/style overrides) support across your entire component library in a consistent way.
Note, that you can replace a single layer and pass the "children" through OR "replace the whole branch" of subcomponents when NOT passing the children through.
Also all overrides get various state props. For dnd-list, it can be something like $isDragged, so you can conditionally render different things.
At the same time, every Base Web component is exporting all these subcomponents. For example, component DND List also exports:
- StyledRoot - StyledList - StyledItem - StyledLabel - StyledCloseHandle - StyledDragHandle
https://baseweb.design/components/dnd-list/#overrides
You are free to use these Styled subcomponents and recompose them any way you wish. You can build your own component from scratch (this approach works great for tables) or you can use overrides and utilize existing state handling etc.
Give me specific example: What customization of dnd-list you can't make with the existing overrides API and what other API would allow you to do that better.