You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've quite a few problems with the current implementation of RPS
Currently, disabling a particular option is done via disabled flag in the option. But, what if you need some conditional logic to disable the option like invoice.status === 'void. Same applies for optgroup.
Another main problem is generating a uuid while rendering the options list Fix indexed keys while rendering the Options #17 . Right now, the key is index-based which is an anti-pattern. I could foresee 2 options to solve this problem
a. introduce optionValuePath. (Unnecessary increase in api surface)
b. implement/use a guuid counter to generate the uuids. (But why when the consumer can dictate the unique field ?)
Proposal
The best option is to offload the looping of options/optgroups to the consumer end like we do for html selects.
In a better world, we can make use of the render props & children as function patterns to achieve the utmost composability without increasing the api surface.
With the above approach, we can deprecate optionLabelPath, optionComponent completely thereby achieving more composability with decreased api surface 🎉
The text was updated successfully, but these errors were encountered:
Problem
We've quite a few problems with the current implementation of RPS
Currently, disabling a particular option is done via
disabled
flag in the option. But, what if you need some conditional logic to disable the option likeinvoice.status === 'void
. Same applies for optgroup.Another main problem is generating a uuid while rendering the options list Fix indexed keys while rendering the Options #17 . Right now, the key is index-based which is an anti-pattern. I could foresee 2 options to solve this problem
a. introduce
optionValuePath
.(Unnecessary increase in api surface)b. implement/use a guuid counter to generate the uuids. (But why when the consumer can dictate the unique field ?)
Proposal
The best option is to offload the looping of options/optgroups to the consumer end like we do for html selects.
In a better world, we can make use of the render props & children as function patterns to achieve the utmost composability without increasing the api surface.
With the above approach, we can deprecate
optionLabelPath
,optionComponent
completely thereby achieving more composability with decreased api surface 🎉The text was updated successfully, but these errors were encountered: