5 ms·

Four approaches to implicit state in compound components, ranked

barbarbar 5y ago
It would be very nice to compare the solutions with a html approach like https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...
- rendall 5y ago
  Software is eating the world, and React is eating software
  - barbarbar 5y ago
    Yes you are right. I am trying to like React. It doesn't go too well. And when I look at it again they have invented a new concept. Like here useSomething or useThisOther.
    - rendall 5y ago
      I do not like React, but I recognize it as the tool it is. It is possible not to like it and still be competent in it.
- Blahah 5y ago
  The inclusive components approach is rather beautiful. No frameworks (so it works in all frameworks that are standards compliant), and it is accessible and semantic: - https://inclusive-components.design/collapsible-sections/ https://inclusive-components.design/collapsible-sections/. Github's elements collection (custom elements/web components) includes several beautifully implemented `details` based approaches to UI problem: - https://github.com/github/github-elements https://github.com/github/github-elements Doing this stuff in React is really quite over-complicating it (and making it practically less accessible/reusable). React is uniquely bad for the web among the most popular frameworks: - https://custom-elements-everywhere.com/ https://custom-elements-everywhere.com/
  - nawgz 5y ago
    > Doing this stuff in React is really quite over-complicating it (and making it practically less accessible/reusable) I find it hard to understand how implementing components within a framework your entire company presumably uses would "[make] it practically less accessible/reusable". I especially take issue with the word "practically", as I can see from some theoretical point of view that an HTML-only component would "enable reuse across all frameworks", but practically speaking I never see people mix frameworks, because that of course would be horrible for performance and real-world reuse.
    - Blahah 5y ago
      Good points, I was specifically thinking about open source components. I use Web components in various frameworks all the time. The crucial thing is that they aren't a framework - they are just a Web standard.
- runawaybottle 5y ago
  I’m going to sound hyperbolic, but your suggestion is profound. I mean, look at that thing, and look at the React examples.
  - jaywalk 5y ago
    They are barely the same thing.
- asah 5y ago
  Is this the same thing? I didn't see an obvious way to close the other details when one of them is opened...
camgunz 5y ago
This post feels a little odd. Spreading state across multiple (compound) components isn't wonderful; that's what controllers or stores are for. But also this example doesn't need to do that? All the complexity is from the contrived requirement that the accordion sections themselves can be arbitrary nodes. If you just said "this has to be text and we're wrapping it in a <p>", there's no need for a component tree here. And besides, it's not like you can just pop anything in there--you'll likely break your layout if you try.
- edoceo 5y ago
  The contrived requirement was just to provide an example with some state-y thing that is easy to grok.
- nawgz 5y ago
  > the contrived requirement that the accordion sections themselves can be arbitrary nodes Why is that contrived? I implement complex forms as data input for a workflow runner. Often, there are nested properties only relevant for certain branches of workflows, and to keep the new user's focus and eye, I put these properties within an Accordion. They include classic data inputs as well as tree-browsers for file or other tree structures, arbitrary lists of objects, etc.. It is quite graceful > it's not like you can just pop anything in there--you'll likely break your layout if you try And this is where I grow even further confused. It's exactly like you can pop anything in there - otherwise why did I implement an Accordion in the first place? My layout tracks the scrollHeight of the container node holding the children for each section and updates & animates its own size accordingly. It's of course just a flex-column, but maybe you can enlighten me on something I am missing with regards to your comment and this implementation.
  - camgunz 5y ago
    Well, I guess my response here is that you've got more of a show/hide multiple sections thing a-la Jenkins than an accordion--which is more of a "show one section at a time" thing. Thus there's no real top-level state to keep track of, each section knows whether of not it's displaying. And that's why I was saying you have to be careful about what you put in an accordion. It's (usually) not like section 1 is gonna be drastically different than section 8. I suppose my point, which I'm kind of getting a better grip on now, is that this post isn't so much about "implicit state in compound components" but rather "where does state live when components kind of depend on each other", which like, describes a web app. The compound components/accordion thing is a red herring; anything could go in here: form validation feedback, notifications, etc. etc. etc.
deleted 5y ago
[deleted]
stupidcar 5y ago
These are all terrible, and they all stem from TypeScript's inability to properly restrict the type of JSX children. Something that's been an issue for years with no sign of resolution, because the proposed fix (from a member of the TS team) has terrible performance: https://github.com/microsoft/TypeScript/issues/21699 https://github.com/microsoft/TypeScript/issues/21699 But since React is a such a minor part of the JS/TS landscape, who can really blame the TS team for not prioritising this, right!?
- ssijak 5y ago
  Are they really that terrible?
runawaybottle 5y ago
It’s scary that the author examined four ways to do a pretty simple component. Nothing wrong with that, but the horror happens when a more abstract component falls into the lap of a React developer. The permutations in which one can build a app specific component (not a baseline ui component) is a pretty large number. If we start applying our perceived values to anything more complex, we increase complexity (death via virtue). I’d argue that we should seek out a scaleable virtue system. While some of those cases that were grade A can be proven to be proper in simple components, they become unwieldy in larger component systems if we pursue righteousness like zealots.
- asah 5y ago
  omg this. But I'm curious, you got any nice counter-examples of lively ecosystems that maintained a reasonable number of permutations? (I do agree that JS has been the wild wild west for a decade too long, and the mobile revolution is no excuse for silliness that should've been resolved in the 2000s)
  - runawaybottle 5y ago
    But I'm curious, you got any nice counter-examples of lively ecosystems that maintained a reasonable number of permutations? Nope. We all suffer together.
svieira 5y ago
Doesn't include the seapig approach! Using the grading framework here, it's probably a C. Looks good, lots of flexibility for the component consumer. Bad TS support, plus the same problems as cloneElement. But I think it's a nifty pattern anyway. https://github.com/enkidevs/seapig https://github.com/enkidevs/seapig
- runawaybottle 5y ago
  Seaping looks pretty good, thanks for sharing.

It would be very nice to compare the solutions with a html approach like https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

rendall 5y ago
Software is eating the world, and React is eating software
- barbarbar 5y ago
  Yes you are right. I am trying to like React. It doesn't go too well. And when I look at it again they have invented a new concept. Like here useSomething or useThisOther.
  - rendall 5y ago
    I do not like React, but I recognize it as the tool it is. It is possible not to like it and still be competent in it.
Blahah 5y ago
The inclusive components approach is rather beautiful. No frameworks (so it works in all frameworks that are standards compliant), and it is accessible and semantic: - https://inclusive-components.design/collapsible-sections/ https://inclusive-components.design/collapsible-sections/. Github's elements collection (custom elements/web components) includes several beautifully implemented `details` based approaches to UI problem: - https://github.com/github/github-elements https://github.com/github/github-elements Doing this stuff in React is really quite over-complicating it (and making it practically less accessible/reusable). React is uniquely bad for the web among the most popular frameworks: - https://custom-elements-everywhere.com/ https://custom-elements-everywhere.com/
- nawgz 5y ago
  > Doing this stuff in React is really quite over-complicating it (and making it practically less accessible/reusable) I find it hard to understand how implementing components within a framework your entire company presumably uses would "[make] it practically less accessible/reusable". I especially take issue with the word "practically", as I can see from some theoretical point of view that an HTML-only component would "enable reuse across all frameworks", but practically speaking I never see people mix frameworks, because that of course would be horrible for performance and real-world reuse.
  - Blahah 5y ago
    Good points, I was specifically thinking about open source components. I use Web components in various frameworks all the time. The crucial thing is that they aren't a framework - they are just a Web standard.
runawaybottle 5y ago
I’m going to sound hyperbolic, but your suggestion is profound. I mean, look at that thing, and look at the React examples.
- jaywalk 5y ago
  They are barely the same thing.
asah 5y ago
Is this the same thing? I didn't see an obvious way to close the other details when one of them is opened...

camgunz 5y ago

This post feels a little odd. Spreading state across multiple (compound) components isn't wonderful; that's what controllers or stores are for. But also this example doesn't need to do that? All the complexity is from the contrived requirement that the accordion sections themselves can be arbitrary nodes. If you just said "this has to be text and we're wrapping it in a <p>", there's no need for a component tree here. And besides, it's not like you can just pop anything in there--you'll likely break your layout if you try.

edoceo 5y ago
The contrived requirement was just to provide an example with some state-y thing that is easy to grok.
nawgz 5y ago
> the contrived requirement that the accordion sections themselves can be arbitrary nodes Why is that contrived? I implement complex forms as data input for a workflow runner. Often, there are nested properties only relevant for certain branches of workflows, and to keep the new user's focus and eye, I put these properties within an Accordion. They include classic data inputs as well as tree-browsers for file or other tree structures, arbitrary lists of objects, etc.. It is quite graceful > it's not like you can just pop anything in there--you'll likely break your layout if you try And this is where I grow even further confused. It's exactly like you can pop anything in there - otherwise why did I implement an Accordion in the first place? My layout tracks the scrollHeight of the container node holding the children for each section and updates & animates its own size accordingly. It's of course just a flex-column, but maybe you can enlighten me on something I am missing with regards to your comment and this implementation.
- camgunz 5y ago
  Well, I guess my response here is that you've got more of a show/hide multiple sections thing a-la Jenkins than an accordion--which is more of a "show one section at a time" thing. Thus there's no real top-level state to keep track of, each section knows whether of not it's displaying. And that's why I was saying you have to be careful about what you put in an accordion. It's (usually) not like section 1 is gonna be drastically different than section 8. I suppose my point, which I'm kind of getting a better grip on now, is that this post isn't so much about "implicit state in compound components" but rather "where does state live when components kind of depend on each other", which like, describes a web app. The compound components/accordion thing is a red herring; anything could go in here: form validation feedback, notifications, etc. etc. etc.

deleted 5y ago

[deleted]

stupidcar 5y ago

These are all terrible, and they all stem from TypeScript's inability to properly restrict the type of JSX children. Something that's been an issue for years with no sign of resolution, because the proposed fix (from a member of the TS team) has terrible performance: https://github.com/microsoft/TypeScript/issues/21699 https://github.com/microsoft/TypeScript/issues/21699 But since React is a such a minor part of the JS/TS landscape, who can really blame the TS team for not prioritising this, right!?

ssijak 5y ago
Are they really that terrible?

runawaybottle 5y ago

It’s scary that the author examined four ways to do a pretty simple component. Nothing wrong with that, but the horror happens when a more abstract component falls into the lap of a React developer. The permutations in which one can build a app specific component (not a baseline ui component) is a pretty large number. If we start applying our perceived values to anything more complex, we increase complexity (death via virtue). I’d argue that we should seek out a scaleable virtue system. While some of those cases that were grade A can be proven to be proper in simple components, they become unwieldy in larger component systems if we pursue righteousness like zealots.

asah 5y ago
omg this. But I'm curious, you got any nice counter-examples of lively ecosystems that maintained a reasonable number of permutations? (I do agree that JS has been the wild wild west for a decade too long, and the mobile revolution is no excuse for silliness that should've been resolved in the 2000s)
- runawaybottle 5y ago
  But I'm curious, you got any nice counter-examples of lively ecosystems that maintained a reasonable number of permutations? Nope. We all suffer together.

svieira 5y ago

Doesn't include the seapig approach! Using the grading framework here, it's probably a C. Looks good, lots of flexibility for the component consumer. Bad TS support, plus the same problems as cloneElement. But I think it's a nifty pattern anyway. https://github.com/enkidevs/seapig https://github.com/enkidevs/seapig

runawaybottle 5y ago
Seaping looks pretty good, thanks for sharing.