Feature/downshift select

[westwood846]

Closes #588

Progress is being tracked here: https://docs.google.com/document/d/18yPN0s17_vhNbIBPBHfQ0zFRtIGn81icPtAwVEmZeBE/edit

[westwood846]

There's an issue here that moves the cursor to the end of the input whenever the input is changed. This effectively prevents the user from editing anything in the middle of the input. This is a known, unsolved problem with downshift:

• Cursor jumps to end of input when inputValue is a controlled prop downshift-js/downshift#217
• [useCombobox] Cursor jumps to end of input when using controlled value downshift-js/downshift#1108
  It happens only for controlled inputValue, which is always the case for us. The suggested solutions in those two threads cause more problems than they solve.

[westwood846]

I tried making the async example more useful by accessing a public API, but I ran into CORS issues:

interface Issue {
  id: number;
  title: string;
  location: string;
}
const ItemWithLocation: React.FC<ItemProps> = ({ item, ...props }) => (
  <Select.Components.Item {...props} item={item}>
    {item.label} ({item.location})
  </Select.Components.Item>
);
export const AsyncItems: Story<Props> = () => {
  const [jobs, setJobs] = useState<Issue[]>([]);
  const [query, setQuery] = useState<string>('');
  const fetchJobs = async (query: string) => {
    const response = await fetch(
      `https://jobs.github.com/positions.json?description=${query}`
    );
    const jobs = await response.json();
    setJobs(jobs);
  };
  React.useEffect(() => {
    // if (query && query.length < 3) return;
    fetchJobs(query);
  }, [query]);
  const issueItems = jobs.map(issue => ({
    value: issue.id.toString(),
    label: issue.title,
    location: issue.location,
  }));
  return (
    <>
      <Select
        label="Jobs"
        items={issueItems}
        components={{ Item: ItemWithLocation }}
        // helperText="Search by assignee"
        transformFunction={items => items}
        onInputValueChange={setQuery}
        inputValue={query}
      />
    </>
  );
};
AsyncItems.parameters = {
  docs: {
    description: {
      story:
        'The Select is built with async items in mind. Just update the items at any time.',
    },
  },
};

[ritikamotwani]

4 commits are very less for this PR haha. Would have been easier to review by every commit. 🤔

[westwood846]

4 commits are very less for this PR haha. Would have been easier to review by every commit.

Yeah I know, but it wasn't really possible for me. There was almost no incremental work here. Either it worked or it didn't. Also this was very exploratory for me.

Just look at the final code.

[rosslo]

The name of NewSelect is a bit weird to me. Will name it AriesSelect or DownshiftSelect better?

[rosslo]

Problem: As a user, I cannot delete the input value from the middle.
Current behavior: The cursor will be automatically moved to the end of the input value.

[rosslo]

I think we can consider adding the following test cases:

• test disableTyping Prop
• test disable property of Item

[ritikamotwani]

Not sure if we should have a separate file for all these types?
Then Select.tsx can only have the Select component.

[westwood846]

It's only around 30 lines of code for the types. I don't think that would make it easier.

[ritikamotwani]

Oh not because of the number of lines of code. It might be a personal preference I guess. It helps in separating the responsibility of files. The types are kept in a separate file.
Something that can be decided for standardization of the codebase later.

[westwood846]

I see!

Actually I don't like separating stuff by "type" so much ^^ I think it's better to organize things logically, in modules. Like we're doing on an app level, with the module folders, where we've tried to move away from the whole "reducers", "selectors", "actions" and whatnot-folders.

[westwood846]

Problem: As a user, I cannot delete the input value from the middle.
Current behavior: The cursor will be automatically moved to the end of the input value.

See comment further up.

[ritikamotwani]

@westwood846 the code looks good. Thanks for all the storybook examples, they are like a good documentation to go through all the functionalities.

There are a couple of warnings, can be fixed before merging.