3 ms·

React components that take configuration rather than allowing you to compose smaller components are generally a bad idea.

crispyporkbites 9y ago
Why?
- mlevental 9y ago
  because dogma
- mattnewton 9y ago
  Speaking from experience outside of react, but I imagine it carries over nicely having done a little react myself: The configuration either doesn’t encapsulate you’re specific use case because it is kept simple, and you are stuck forking the component; or the configuration expands to be its own little akwards DSL with very surprising edge cases.
  - mattnewton 9y ago
    Oof, s/you’re/your
  - ikurei 9y ago
    (I commented on your grandparent) I agree that these are the main issues with using this kind of component. However, most of the time there is no need to fork the component and, if you actually need things that the component doesn't allow, then it's the time to do it yourself. Because that doesn't always happen, if the component is easy to use it often is worth to go with it and only do the additional work if you need it. > or the configuration expands to be its own little akwards DSL with very surprising edge cases. This is the crux of the matter. However with this particular library, the configuration is extremely reasonable, simple and readable. It would be no problem to refactor the code to use the very same configuration to create your own table.
ikurei 9y ago
Please try to explain further why something is a good or bad idea. Share your experience. I'm sure your criticism could be useful for many. In my experience with React, this kind of approach produces much more readable and elegant code. And also less code. And as long as the configuration objects are simple and readable like these, the problems with it are not serious. It's true though that when your needs get more specific and complex you will surely find you need something not included in the component's configuration options. In those cases some components will let you specify custom things, which may or may not be enough[1]. Then it's trivial to reuse that configuration and iterate over them creating the table yourself. Most tables I've done could easily be written with this component. Most of the time I actually do something very close to its configuration objects, and then iterate over them with a `map` to create the `td` and `tr`. This allows me to separate concerns more clearly. (I don't know about using css-grid instead of the old tables. Really, I don't know css-grid well enough.) [1] The OP's let's you specify a custom renderer for particular columns. That won't solve everything, but will do for many cases.

crispyporkbites 9y ago

Why?

mlevental 9y ago
because dogma
mattnewton 9y ago
Speaking from experience outside of react, but I imagine it carries over nicely having done a little react myself: The configuration either doesn’t encapsulate you’re specific use case because it is kept simple, and you are stuck forking the component; or the configuration expands to be its own little akwards DSL with very surprising edge cases.
- mattnewton 9y ago
  Oof, s/you’re/your
- ikurei 9y ago
  (I commented on your grandparent) I agree that these are the main issues with using this kind of component. However, most of the time there is no need to fork the component and, if you actually need things that the component doesn't allow, then it's the time to do it yourself. Because that doesn't always happen, if the component is easy to use it often is worth to go with it and only do the additional work if you need it. > or the configuration expands to be its own little akwards DSL with very surprising edge cases. This is the crux of the matter. However with this particular library, the configuration is extremely reasonable, simple and readable. It would be no problem to refactor the code to use the very same configuration to create your own table.

ikurei 9y ago

Please try to explain further why something is a good or bad idea. Share your experience. I'm sure your criticism could be useful for many. In my experience with React, this kind of approach produces much more readable and elegant code. And also less code. And as long as the configuration objects are simple and readable like these, the problems with it are not serious. It's true though that when your needs get more specific and complex you will surely find you need something not included in the component's configuration options. In those cases some components will let you specify custom things, which may or may not be enough[1]. Then it's trivial to reuse that configuration and iterate over them creating the table yourself. Most tables I've done could easily be written with this component. Most of the time I actually do something very close to its configuration objects, and then iterate over them with a `map` to create the `td` and `tr`. This allows me to separate concerns more clearly. (I don't know about using css-grid instead of the old tables. Really, I don't know css-grid well enough.) [1] The OP's let's you specify a custom renderer for particular columns. That won't solve everything, but will do for many cases.