💡Added support to ModernTaxonomyPicker in DynamicForm - Fix 1275

[NishkalankBezawada]

Q	A
Bug fix?	[x]
New feature?	[ ]
New sample?	[ ]
Related issues?	fixes #1275

What's in this Pull Request?

Added support to ModernTaxonomyPicker control in Dynamic Form. This will be handled by a property useModernTaxonomyPicker

Property	Type	Required	Description
useModernTaxonomyPicker	boolean	no	Specifies if the form should render ModernTaxonomyPicker control for Managed metadata fields. If set to true, Dynamic form will render ModernTaxonomyPicker control. If set to false, Dynamic form will render TaxonomyPicker control. Default is false

By using this property, we ensure that both TaxonomyPicker control and ModernTaxonomyPicker control can be used. This will be automatically defaulted to use TaxonomyPicker control.

Guidance @joelfmrodrigues

Thanks,
Nish

[michaelmaillot]

Hello Nish, thanks for providing this PR.

Here's my two cents about this one, to go further this update. At some point, I was thinking about definitely replacing TaxonomyPicker by the ModernTaxonomyPicker in this control. But for the moment, the ModernTaxonomyPicker relies on the PnPjs v2 @sp/taxonomy package which uses v2.1 endpoint under the hood. But we'll problably update to PnPjs v4 at some point and this will involve to migrate from SP REST call to Graph call (or keep v2.1 REST call but having to overwrite existing calls to make explicit REST API calls instead of using PnPjs taxonomy calls).

From my perspective, with this PR we can let users choose to use the picker they want. But once we plan to update PnPjs version, we'll have to keep in mind that this will involve code base / documentation update regarding the ModernTaxonomyPicker.

[NishkalankBezawada]

Hello Nish, thanks for providing this PR.

Here's my two cents about this one, to go further this update. At some point, I was thinking about definitely replacing TaxonomyPicker by the ModernTaxonomyPicker in this control. But for the moment, the ModernTaxonomyPicker relies on the PnPjs v2 @sp/taxonomy package which uses v2.1 endpoint under the hood. But we'll problably update to PnPjs v4 at some point and this will involve to migrate from SP REST call to Graph call (or keep v2.1 REST call but having to overwrite existing calls to make explicit REST API calls instead of using PnPjs taxonomy calls).

From my perspective, with this PR we can let users choose to use the picker they want. But once we plan to update PnPjs version, we'll have to keep in mind that this will involve code base / documentation update regarding the ModernTaxonomyPicker.

Hey @michaelmaillot

I completely agree with your perspective. Allowing users to choose between TaxonomyPicker and ModernTaxonomyPicker for now makes sense, especially considering the future migration to PnPjs v4 and the potential shift to Graph API. To add to it, for the existing components, that uses IPickerTerms in TaxonomyPicker and it wouldnt be wise to change it to use ModernTaxonomyPicker.

In addition to this, I was also thinking to extend ModernTaxonomyPicker to support a more controlled approach, where we provide options to create and delete terms (But this would be in future after discussions). This enhances the flexibility and usability in various scenarios.

Looking forward to any further feedback!

Thanks,
Nish