Hacker News Reader

Comment by tomelders | Hacker News Reader

I didn’t propose the solution to a Select input that you said I did. There’s no need to define multiple render props since the most complex of selects is going to be a nested tree structure. Each node of that tree can be passed as an argument to the render prop, and the render prop itself can conditionally render any number of children types.

Everything is customisable without this override solution. And I’d argue that things become less customisable with it. What if the CustomOption component needs to be customised too? This solution makes a mess of that type of composition.

View on HN

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:

- 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.

You're out of your mind if you think that's an better way to compose components. How would you do something like this?

  <DNDLlist render={(listItem => {   
    switch(listItem.type) {   
      case 'foo':  
        return <FooListItem>{listItem.title}</FooListItem>;  
      case 'bar':  
        return <BarListItem>{listItem.title}</BarListItem>;  
      default:  
        return <ListItem>{listItem.title}</ListItem>;  
    }  
  })}>

https://gist.github.com/tajo/a84d96f248d454d1226e12bb07c8157...

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.

This thread was very entertaining. This "solution" is insane. How did so many engineers not realize they're just reinventing the wheel?

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.

Reply on news.ycombinator.com