feat: tree-item expanded state is confusing

[scomea]

How the expanded state of fast tree-items is managed is confusing and should be reviewed. Most notable the expanded property can be true even if the item is not actually able to be expanded because of not having tree-item children. For example a tree item with no children could have its public expanded prop set to true while also having an 'aria-expanded' attribute of false:

aria-expanded="${x =>x.childItems && x.childItemLength() > 0 ? x.expanded : void 0}"

Ideally the "expanded" prop and the "aria-expanded" attribute would be in sync.

[chrisdholt]

Thanks for the write-up, this is helpfu. I think here we would want to figure out if/how we would manage a controlled/uncontrolled state. To your point in discord, I think we may need an internal observable for tracking this as well as the attribute. That would allow us to default to a provided value in a controlled scenario, while doing the right thing if it's uncontrolled (similar to current behavior). With that though, I think we'd also have an issue where you end up with a "nested" scenario without tree items - would we want to show this as expandable if it doesn't have tree item children? That may be an added necessity as if we do not expand when it shows as expandable, that would be similarly confusing.

Thoughts?

Edit to add: One option here is to expand regardless and it'll illustrate a broken state - less than ideal, but that would signal to developers perhaps that it's "wrong". I'm in a toss up between moving that direction and doing what's right out of the box. It's nice to "cover mistakes" on one hand, but that can also come with unintended consequences.

[scomea]

Getter/setter logic on the expanded prop maybe?