Ashby Design an API for a React Component Challenge

Last updated November 20, 2020

In this interview, we'd like to design an API for a React component (or a set of components) that enables developers to create different permutations of a dropdown and autocomplete.

Goal

At the end of this interview, we should have defined enough of the API such that a developer could build one of the examples below in pseudo-JSX (more in the "Instructions "section).

The features we'd like to support:

  • The trigger for the dropdown can be a button, a select box, or custom content. The trigger should not allow the user to input a search string.
  • The popover can contain:
    • A search bar (optional)
    • A list of results with custom content
    • Headers for groups of results (optional)
    • A control to add a new item (optional)

Here's a set of visual examples that cover the features (but not all permutations of those features):

Autcomplete permutations

Instructions

Predefined Components

We've already defined some components for you. You don't have to use them, and we don't expect you to:

  • <ChevronSvg> - It displays the chevron icon used above and can accept any <svg> attribute as a prop except children
  • <Button> - It provides default button styling, can accept any <button> attribute as a prop (including children)
  • <TextInput> - It provides default styling for a text input and can accept any <input> attribute as a prop (except type)

Constraints

  • Assume results will be available as an array in memory. Where they come from and how they're calculated should be irrelevant to your API.
  • For autocompletes, assume the results will change based on a search string. Your component(s) should allow the end-user to input the search string and the developer to get the search string as the end-user types (for example, via an onSearchTermChange handler).

We don’t expect (nor necessarily want) working code but we want to see pseudo-JSX to help understand usage of the component(s) in your API. An example for an imaginary modal:

1// Developers need to specify when the modal is open or not. When `doesDismiss...` 
2// is true, clicking outside the modal chrome will dismiss the modal
3<Modal isOpen={boolean} doesDismissOnClickOutside={boolean?}>
4    // When onDismiss is provided, an x is placed in the right corner 
5    // and when clicked calls onDismiss
6    <ModalHeader onDismiss={() => void}>
7        // Optional icon. You can pass a React component type that renders an icon
8        <ModalIcon icon={ReactComponentType}>
9        <ModalTitle>
10          // Anything can go here, but usually text
11        </ModalTitle>
12    </ModalHeader>
13    <ModalBody>
14        // Anything can go here
15    </ModalBody>
16    <ModalFooter>
17      // Evenly spaces children and aligns them according to the component name 
18      <RightAlign|LeftAlign|CenterAlign>
19        // Anything can go here, usually <Button>s
20      </RightAlign|LeftAlign|CenterAlign>
21    </ModalFooter>
22</Modal>

Pseudo-JSX is a construct we've come up with to separate API design from actual implementation. We've written a primer here to help you understand what we're looking for in the interview.

You can also define custom hooks or HOCs as part of your API.