Which UI Kit version is this bug for?
v5.x
Latest version
No Hitachi confidential content
Current behavior 😯
In a single select HvDropdown, when the user selects an option from the dropdown, the selected option is immeditately committed to the internal state of HvDropdown, and thus immediately changing the label rendered in the dropdown header.
Expected behavior 🤔
We should be able to use this component like a "controlled" input, where application state and application state alone is used as the selected option in HvDropdown. Just like if you use a normal "select" element in react, and you mange its state, the final value that's shown as selected will always use the application state.
This avoids mis-match between application state and UI in scenarios when some custom business logic decides not to update application state to the newly selected option immediately.
Steps to reproduce 🕹
Sandbox link:
Steps to reproduce:
- Render a simple single select HvDropdown
- Pass it a values list with one of the options marked as "selected: true"
- Implement an onChange handler that does not modify the application state at all
- You will see that the HvDropdown header shows the newly selected value even though application state is not updated
- If you were to trigger a re-render of the parent component now, things would go back to a synchronized state
Context 🔦
We have a scenario in our application where changing some dropdowns values, triggers a dirty-form check confirmation modal giving the option to user to either save their changes before proceeding or discard their changes to the form before proceeding with the dropdown value change.
eg. In a page where we have a large form with multiple inputs. Outside this form, there's a dropdown available to the user to go to an entirely different form. But if they choose to do so, we first check if the current form is dirty and show a modal giving the user options to "save" changes before moving to new form, "discarding" changes before moving to the new form, or "cancelling" the navigation to the new form itself.
If the user chooses to "cancel", they remain on the same form, and that's where we have a mis-match in HvDropdown internal state and application state.
The workaround we currently use is to trigger a re-render of the parent component by managing the expanded state of the dropdown in parent component. Thus whe user selects a dropdown option, the onToggle callback sets the parent state of expanded to false and will hence re-render the HvDropdown, synchronizing the state again. It would be nice to not have to do this though, we have comments in our code explicitly stating not to remove this managed state of dropdown expanded even though it doesn't seem to do anything special at first glance.
Your Environment 🌎
No response
Which UI Kit version is this bug for?
v5.x
Latest version
No Hitachi confidential content
Current behavior 😯
In a single select HvDropdown, when the user selects an option from the dropdown, the selected option is immeditately committed to the internal state of HvDropdown, and thus immediately changing the label rendered in the dropdown header.
Expected behavior 🤔
We should be able to use this component like a "controlled" input, where application state and application state alone is used as the selected option in HvDropdown. Just like if you use a normal "select" element in react, and you mange its state, the final value that's shown as selected will always use the application state.
This avoids mis-match between application state and UI in scenarios when some custom business logic decides not to update application state to the newly selected option immediately.
Steps to reproduce 🕹
Sandbox link:
Steps to reproduce:
Context 🔦
We have a scenario in our application where changing some dropdowns values, triggers a dirty-form check confirmation modal giving the option to user to either save their changes before proceeding or discard their changes to the form before proceeding with the dropdown value change.
eg. In a page where we have a large form with multiple inputs. Outside this form, there's a dropdown available to the user to go to an entirely different form. But if they choose to do so, we first check if the current form is dirty and show a modal giving the user options to "save" changes before moving to new form, "discarding" changes before moving to the new form, or "cancelling" the navigation to the new form itself.
If the user chooses to "cancel", they remain on the same form, and that's where we have a mis-match in HvDropdown internal state and application state.
The workaround we currently use is to trigger a re-render of the parent component by managing the expanded state of the dropdown in parent component. Thus whe user selects a dropdown option, the onToggle callback sets the parent state of expanded to false and will hence re-render the HvDropdown, synchronizing the state again. It would be nice to not have to do this though, we have comments in our code explicitly stating not to remove this managed state of dropdown expanded even though it doesn't seem to do anything special at first glance.
Your Environment 🌎
No response