5 ms·

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

• tomelders 7y ago
  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.
  • dogcomplex 7y ago
    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.
  • IceDane 7y ago
    This thread was very entertaining. This "solution" is insane. How did so many engineers not realize they're just reinventing the wheel?
  • tlrobinson 7y ago
    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.
• deleted 7y ago
  [deleted]