Select & context menu improvements

• options are currently specified as { value: string, option?: string }. Actually, options are treated in the code as always specified, and there are runtime errors when they are omitted.
• we should consider removing options altogether, and have the component simply take a list of strings. This would make the component much easier to use, and leave the minimal responsibility of mapping the labels to raw values to the library user. If need be, they can produce a wrapper that restores the current API with very minimal code.
• a redesign to match DatePicker is in order, adding a minimum width to look good.
• when the values pop up, their design should match ContextMenu.
• redesign the label to be consistent with input and date picker.

[TejasQ]

I favor number 1 because it seems like better design and will provide two very well thought through, robust components to serve both purposes of Select and ContextMenu.

I favor number 2 because it delegates the power to ContextMenu, while allowing for something simpler if needed.

I favor both approaches and your engineering skills and literally cannot decide. Sorry I’m not much help, but if it was up to me, I’d say do whatever seems best to you. ¯\_(ツ)_/¯

[peterszerzo]

Maybe it’s helpful to write it out a bit better how you would use the new API in the mindset of the old one:

render() {
  const optionsByOldApi = [
    { value: "v1", label: "l1" },
    { value: "v2", label: "l2" },
    { value: "v3", label: "l3" }
  ]
  return (
    <Select options={optionsByOldApi.map(o => o.label)} onChange={(newLabel, newIndex) => {
      // Either find the value by matching against the label, or just go by index
      // Keep doing business as usual
    } />
  )
}

Select is easier to use now (<Select options={["apples", "other fruit"]} /> just works), the <option> tag still gets a semantic value, and you can map things back quickly.