Filter component change API

[jamiek-acl]

@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:

data = [
  {colour: blue, animal: cat},
  {colour: red, animal: cat},
  {colour: orange, animal: cat},
  {colour: orange, animal: dog},
  {colour: orange, animal: eagle},
  {colour: orange, animal: dragon},
]

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):

<Filter
  options={{colour: [blue, red, orange], animal: [cat, dog, eagle, dragon]}}
  ...
/>

cc: @allison-c

[allison-c]

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