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
@AndreyChernykh had some concerns with the design of the <Filter /> component's API.
Imagine a Filter that can filter on two drop-down fields: favourite colour (options are: blue, red, orange) and favourite animal (options are: cat, dog, eagle, dragon).
The data prop that is passed into <Filter /> is an array of objects, where each option must exist in the array or it will not be an <option> in the <select>. So you must pass in at least this data:
I see, and I agree, at the begining the data prop is only for the front-end filtering logic, it's also optional, if the consuming app decided to use back-end filtering logic, they can leave data prop empty, and the default value is null. It's not a good idea to use data to generate the options in the dropdowns.
I agree with adding a options prop (or maybe reuse the columns prop) and use that to generate dropdown options instead of using data
@AndreyChernykh had some concerns with the design of the
<Filter />
component's API.Imagine a Filter that can filter on two drop-down fields: favourite colour (options are: blue, red, orange) and favourite animal (options are: cat, dog, eagle, dragon).
The
data
prop that is passed into<Filter />
is an array of objects, where each option must exist in the array or it will not be an<option>
in the<select>
. So you must pass in at least this data:This can be a pain for cases like mine, where I have to filter on five (and soon eight) drop-down fields, and each could have dozens of options.
Andrey was thinking instead the API could incorporate
options
, so they don't have to be duplicated over and over again (like "orange" is above):cc: @allison-c
The text was updated successfully, but these errors were encountered: