3 ms·

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 e

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.

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.