6 ms·

Nope. This is replacing composition with configs for no good reason. It's like the people who made Grunt and Webpack teamed up to ruin React for everyone.

Klathmon 7y ago
I really hate dismissive comments like this. They laid out pretty well what problems this is trying to solve, why they want it that way, the benefits it has, and some of the tradeoffs it makes. Saying it "replaces composition with configs for no good reason" is not only wrong (they still heavily use composition here, it even makes it more powerful in some ways from what I can tell so far), but also doesn't really mean anything on it's own (at least to me it doesn't).
- tomelders 7y ago
  Ok, fair enough. It was a drive by shooting of a comment. So here’s a more considered criticism. There’s already a way to overwrite props in react. Just use props. If you need to expose the native API of the underlying element, do this (does HN format code?)... ``` const {foo, ...native} = props; <label {...native}> <p>{foo}</p> </label> ``` Combine that with default props and you’re good to go. There’s already a way to allow components to take multiple types of children. ``` <Select render={ blah => { return <CustomOption>{blah}</CustomOption> }} /> ``` And there’s already a multitude of ways to adapt styles based on props, the most obvious of which is StyledComponents. In addition, this highlevel config is brittle. It means parents must be coupled to their children, and children coupled to their parents. And where does this config end? How deep does the nesting of this configuration go? Here’s my opinion; if you think you need this sort of configuration to properly wrangle your UI, then you’ve failed to grasp the point of React and the true power of composition. React components are just functions. Preferably pure functions. Once you strip away the JSX, you should be left with something that resembles functional programming (albeit taken to an extreme thanks to JSX’s goal of emulating HTML). Props are parameters. We’ve all come across code where functions take complex and convoluted objects as arguments that trigger an explosion of calls that are near impossible to track or reason about. This override solution is the first step in towards turning React into the kind of tool that it usurped. It has the stench of ExtJs and it’s ilk. This “solution” was created by people who believe all problems are better solved by abstraction. As programmers, our time is spent on the edge cases. Our text book prefect algorithms and mathematically sound functions are exposed as frauds the second they’re exposed to user input. Our carefully crafted UI libraries fall to pieces when the designers choose to break their own rules. For configuration to work, it requires god level foresight and will eventually become Turing complete in itself. Config is for the birds. Declarative code has always been the answer.
  - SubFuze 7y ago
    A big part of the goal with the overrides mechanism was to provide usable components out of the box that could optionally be modified if something needed to be changed for a given use case. You can use the components as is, using props if you're ok with the out of the box style/functionality/etc, without ever touching overrides. The overrides provide a standardized interface to changing the component internals across the entire component library. That approach may be overkill for simple components that are trivally composable (Card for example), but is incredibly powerful for a component like Datepicker where you may want to change styles or functionality of a deeply nested component without exposing a massive top level props interface.
    - tomelders 7y ago
      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 7y ago
        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 7y ago

Klathmon 7y ago

I really hate dismissive comments like this. They laid out pretty well what problems this is trying to solve, why they want it that way, the benefits it has, and some of the tradeoffs it makes. Saying it "replaces composition with configs for no good reason" is not only wrong (they still heavily use composition here, it even makes it more powerful in some ways from what I can tell so far), but also doesn't really mean anything on it's own (at least to me it doesn't).

tomelders 7y ago
Ok, fair enough. It was a drive by shooting of a comment. So here’s a more considered criticism. There’s already a way to overwrite props in react. Just use props. If you need to expose the native API of the underlying element, do this (does HN format code?)... ``` const {foo, ...native} = props; <label {...native}> <p>{foo}</p> </label> ``` Combine that with default props and you’re good to go. There’s already a way to allow components to take multiple types of children. ``` <Select render={ blah => { return <CustomOption>{blah}</CustomOption> }} /> ``` And there’s already a multitude of ways to adapt styles based on props, the most obvious of which is StyledComponents. In addition, this highlevel config is brittle. It means parents must be coupled to their children, and children coupled to their parents. And where does this config end? How deep does the nesting of this configuration go? Here’s my opinion; if you think you need this sort of configuration to properly wrangle your UI, then you’ve failed to grasp the point of React and the true power of composition. React components are just functions. Preferably pure functions. Once you strip away the JSX, you should be left with something that resembles functional programming (albeit taken to an extreme thanks to JSX’s goal of emulating HTML). Props are parameters. We’ve all come across code where functions take complex and convoluted objects as arguments that trigger an explosion of calls that are near impossible to track or reason about. This override solution is the first step in towards turning React into the kind of tool that it usurped. It has the stench of ExtJs and it’s ilk. This “solution” was created by people who believe all problems are better solved by abstraction. As programmers, our time is spent on the edge cases. Our text book prefect algorithms and mathematically sound functions are exposed as frauds the second they’re exposed to user input. Our carefully crafted UI libraries fall to pieces when the designers choose to break their own rules. For configuration to work, it requires god level foresight and will eventually become Turing complete in itself. Config is for the birds. Declarative code has always been the answer.
- SubFuze 7y ago
  A big part of the goal with the overrides mechanism was to provide usable components out of the box that could optionally be modified if something needed to be changed for a given use case. You can use the components as is, using props if you're ok with the out of the box style/functionality/etc, without ever touching overrides. The overrides provide a standardized interface to changing the component internals across the entire component library. That approach may be overkill for simple components that are trivally composable (Card for example), but is incredibly powerful for a component like Datepicker where you may want to change styles or functionality of a deeply nested component without exposing a massive top level props interface.
  - tomelders 7y ago
    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 7y ago
      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 7y ago