add active id to accordion change event

[chrisdholt]

Pull Request

📖 Description

Adds information on the activeid for the accordion as part of the elements custom event.

🎫 Issues

closes #6130

👩‍💻 Reviewer Notes

📑 Test Plan

✅ Checklist

General

• I have included a change request file using $ yarn change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

Component-specific

• I have added a new component
• I have modified an existing component
• I have updated the definition file
• I have updated the configuration file

⏭ Next Steps

[EisenbergEffect]

Is this consistent with the way we handle it in other components? I don't recall seeing our code using the id in the event args before.

[chrisdholt]

Is this consistent with the way we handle it in other components? I don't recall seeing our code using the id in the event args before.

As @vnbaaij calls out, tabs does this exact thing. The delta here from other components is that activeid is internal to accordion and private, so passing it as part of the event should allow us to expose it gracefully.

fast/packages/web-components/fast-foundation/src/tabs/tabs.ts

Line 177 in 8387c74

this.$emit("change", this.activetab);

[EisenbergEffect]

Probably need to port this to the archive branch as well.

[EisenbergEffect]

I think we need to change this to "prerelease" also.

[chrisdholt]

yep, thanks

[chrisdholt]

Dangit - I missed pushing this...PR incoming

[vnbaaij]

After looking at the source again, I see the accordion-item emits the change event too. And that one has a public id. As he events bubble up (if I understood correctly), maybe it makes more sense to change it in the accordion-item itself?

[chrisdholt]

After looking at the source again, I see the accordion-item emits the change event too. And that one has a public id. As he events bubble up (if I understood correctly), maybe it makes more sense to change it in the accordion-item itself?

Eh, we could, but I wonder if that's enough in and of itself - that value is already available publicly in the event object I believe.

@vnbaaij - you might be able to get the event target in this scenario; I actually think this is a better and more aligned approach considering tabs and the fact that I want the activeid for accordion itself.

[scomea]

After looking at the source again, I see the accordion-item emits the change event too. And that one has a public id. As he events bubble up (if I understood correctly), maybe it makes more sense to change it in the accordion-item itself?

This is related. #6144 to "accordion" reacting to "change" events from items other than "accordion-item" . I have a local branch that adds checks to "accordion" to ensure it only reacts to these events from direct children but I do wonder if we should have more specific event names rather than so many "change" events (ie. "expanded").