epam
[PickerInput]: deprecated entity mode in flavor datasource.getById
To Do
Historically, the PickerInput component has supported the valueType='entity' prop, which enables PickerInput to accept the entire entity as a value/onValueChange. Previously, this was the only option to retrieve the selected entity from the picker without making an additional backend request.
However, this functionality can now be achieved using the datasource.getById('id') method, which returns the entity based on the provided ID.
Since the entity mode in PickerInput adds unnecessary complexity to its development and testing without offering significant user benefits, we propose deprecating it in favor of using datasource.getById.
Describe the solution you'd like (optional)
- Consult with current clients to identify any specific cases where they use
valueType='entity', and ensure that datasource.getById can cover these scenarios. - Deprecate the
valueType='entity'prop by displaying a console warning when it is used. Remove the use of entity mode from the UUI codebase and documentation. - Provide examples in the documentation on how to retrieve an entity using
datasource.getById.
How do you expect it to work with lazy/async trees when an item is not yet loaded? Async getById?
How do you expect it to work with lazy/async trees when an item is not yet loaded? Async getById?
The PickerInput already loads selected items by their IDs on the initial render, so those items will always be available in the DataSource after that. Therefore, this behavior is essentially the same as the current entity mode—once an item is selected, it will always be present in the DataSource.
As for using getById outside the context of PickerInput, I believe we can extend its functionality so that getById will also handle loading items asynchronously, similar to how it works within the PickerInput component.
We have a lot of cases, where instead of using just ids for picker, we going with entity 'cause API does not support requesting items by ids. Deprecating entity mode will be a breaking change for us forcing to update "a good amount" of endpoints. It's not that bad actually, but I'm afraid we wouldn't have enough capacity and it may be a blocker for future UUI updates.
We store entities (value + id fields) of selected values in Local Storage, so that we can
- Display the names of selected items, even though the data is not yet received. We have cases, when the data is loaded only when the picker input is opened, so using only IDs would initially display empty tags in the dropdown target, unless users manually associate names from an external source with IDs in
getName - Have a prepared structure for saving to Local Storage on change (
onValueChange) without necessity to find the entity by ID in the data source for each selected value manually
As far as I understand, removing "entity" support would require each user to do additional work on their side.
@vasilii-kovalev @cpoftea Thanks for sharing your cases, we will consider them when get this issue into work. Anyway, If we decide to proceed with this breaking change, we will do it smoothly by first adding a deprecation warning , that projects have time to move to the new approach. Also we will come up with some recommendations of how it can be done.