Hacker News Reader

Comment by miksuv | Hacker News Reader

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