Fluentui: Custom Persona Types

[Adjective-Object]

Say I'm a consumer of this API that wants to, in a type-safe way, use a Picker component to pick personas for my application.

Say that persona type has some field not present on the Persona object that I would like to use in one of the callbacks (e.g. it's a user group and it has some ID I need for the onExpandGroup call in the SelectedPeopleList).

Right now I have to, on all of these callbacks, cast the type to my situation-specific type before operating on it. What's the reasoning behind not parameterizing SelectedPeopleList/PeoplePicker/ExtendedPeoplePicker/ on your application's specific people data type?

[aneeshack4]

Hi @Adjective-Object, the BasePicker is very generic and not parameterized for application data type so you can use that.

[Adjective-Object]

But what's the reason for not parameterizing it? Are the Persona-custom components (e.g. SelectedPeopleList, ExtendedPeoplePicker, etc) meant to be used only with the exact Persona type in Fabric?

If so, are library consumers expected to rewrite all the Persona component containers in order to maintain type safety?

[Vitalius1]

@Adjective-Object
I've done some work with converting the pickers (PeoplePicker and TagPicker) to CSS-in-JS and had the same questions. My understanding is that we have BasePicker as a ground from which you build any picker you like with any types of Personas (maybe not even Fabric ones). And then we have PeoplePicker which is using the Fabric Persona and it was really built with a lot of product (ODSP) specific scenarios. So unfortunately if you need more properties on a Persona you will have to do what you mentioned in the post above. I might be wrong but this is how we ended up having a bunch of pickers in the repo (FloatingPicker, ExtendedPicker, pickers folder) which have a lot in common but still are separate. They even have lots of copy/paste things and some files differ only in 1-2 lines.
@joschect might give you more history and reasoning why this was done.

[Adjective-Object]

ExtendedPeoplePicker is built with a lot of Outlook-specific scenarios in mind, and our Persona type is different 😛 . It shouldn't be that much of a functional change to parameterize the People* components on some <TPersona extends IPersonaProps = IPersonaProps>.

I'd be willing to put up an RFC on this since it's related to a lot of the work I'm already doing on ExtendedPeoplePicker. I'd really like that surface to be typesafe both from an API ergonomics point of view & a correctness point of view.

[Vitalius1]

Feel free to assign this issue to yourself so that people know someone is or will be working on this.

Also, as a side note... If you already are doing a lot of work in ExtendedPeoplePicker, we would appreciate a lot if you could find some time and have it converted to use CSS-in-JS pattern 😄 . A bigger project would be to consolidate all the pickers under one package and have them reuse all of the common stylings and functionality. Like I said... as of today there is still some copy/paste code in between all them when they diverged in product-specific scenarios, but this is something that needs a little more investment and more participants)))

[Adjective-Object]

hmm idt I have issue-assign privileges but feel free to put this on me.

[aneeshack4]

Thanks for taking this on @Adjective-Object! We look forward to looking at a PR for this.

[xugao]

looks like this is done in PR #8720. closing