[CR] Different API for `<Select>` component for Grommet 2

Could we make the Select component work more like the native select and option combination in Grommet 2?

Today value on a <Select> can either be a string or object, and it will set the “selected” item to that string/object(even if it doesn’t exist in the options). Also, in the case of options being an array of objects, each of these objects look similar to this { label: 'label', value: 'value'} but in the onChange callback label is irrelevant. What you really care about is the value and/or the index of the element that was clicked.

In short something like this would(imho) be preferred:

const users = [{name: 'johndoe', id: 0}, {name: 'janedoe', id: 1}]

return (
  <Select onChange={(event, index, value) => console.log(users[index], value)}>
    {users.map(u => <SelectItem value={u.id}>{u.name}</SelectItem>)}
  </Select>
)

In this case it’s very similar to a native <select><option></select> and the onChange callback gets passed event, index, value (both index and value could be valuable). Arguably passing an array of objects to options vs mapping over an array to <SelectItem>'s could be seen as the same, but i think that having the <SelectItem>'s make it more similar to how it works natively, and therefore easier to understand.

Expected Behavior

As described above, open discussion

Actual Behavior

Today there are some catches(some mentioned above) to <Select> which can be unintuitive

URL, screen shot, or Codepen exhibiting the issue

Here the issue with how the value prop works today is shown: https://codepen.io/anon/pen/dzpjyx?editors=0010

[karatechops]

This seems like a more declarative way of of composing the Select component, I dig it. Related to #1484

[L0ZZI]

It’s a question for @alansouzati and @ericsoderberghp. Above my pay grade.