Closed VentuzTammoHinrichs closed 1 hour ago
Please try 10.8.4 you are using 10.8.2 and i think this was fixed?
Please fork the Stackblitz project and create a case demonstrating your bug report. This issue will be closed if no activities in 20 days.
I believe was fixed with this: https://github.com/primefaces/primereact/issues/7081
Please try 10.8.4 you are using 10.8.2 and i think this was fixed?
I'm sorry but the proposed fix for #7081 did sadly not fix our case (note that my source links are form 10.8.4):
optionValue
property there. If that property isn't set, and the component defaults back to "value", that isNotEmpty()
path still gets taken. Yes, we could work around that by specifying optionValue="value"
in all of our numerous DropDown incarnations, but I'd suggest changing this to something like typeof optionValue !== 'undefined'
to make the code behave like documented.getSelectedOptionIndex
still prohibits us from having a null value with a label.I'll try to create a repro case as suggested.
Oh in your printout above it says " primereact: ^10.8.2 => 10.8.2"
PR is welcome
I assigned to you if you want to submit a PR please
https://stackblitz.com/edit/vitejs-vite-da87c5?file=src%2FApp.tsx
Ok seems that the first part is indeed fixed in 10.8.4 (seems the optionValue prop is getting filled in with a default so it's always there. I didn't see that, sorry), but the second still remains - if you click on "Auto" in the Dropdown the selection is cleared instead.
OK cool fix is welcome!
Describe the bug
Before PrimeReact 10, the Dropdown component was able to handle option values like null or empty strings or array or objects, and they worked like any other value.
Since updating to 10, this isn't the case anymore:
ObjectUtils.isNotEmpty
call at https://github.com/primefaces/primereact/blob/99bc7769f4b7906424fa570c2c60f8a7ce8e02cf/components/lib/dropdown/Dropdown.js#L840 makes sure that this falsely also applies to null and otherwise empty but defined values.props.value
is null and so prohibits the user from having an option with a null value. I get the reasoning behind this but it would be wiser to do the check only if the search for the option fails, so a null option value would work again.Reproducer
No response
System Information
Steps to reproduce the behavior
Try a Dropdown with the following options:
Expected behavior
IMO null, "", [] and {} should be accepted as option values again - these are perfectly fine, distinct values, and needed in our use case. (as a workaround, I had add two functions that replace those values with dummy strings and then back, and you might agree that's not really elegant)