Concepts

Easy To Use

We've found that good component libraries are easy to use and limit the learning curve of new APIs.

In our components, we've tried to limit the complexity to prevent developers from having to learn a list of 12 possible props that a component can accept.

// No one enjoys looking these up
<Modal
  title="Complex Modal"
  body="Modal Body Content"
  onModalClose={...}
  modalHeaderStyles={...}
  modalFooterStyles={...}
  modalButtonText="Submit"
/>

This example could have up to 8 or 10 props and would quickly grow in complexity over time.

Instead, we prefer to follow the guidelines of Reach UI and maintain a one-to-one mapping of components to DOM elements:

<Modal onClose={...}>
  <ModalHeader fontSize="lg">Complex Modal</ModalHeader>
  <ModalBody>
    Modal Body Content
  </ModalBody>
  <ModalFooter backgroundColor="#e3e3e3">
    <Button onClick={() => setOpen(false)}>Submit</Button>
  </ModalFooter>
</Modal>

In this example, our <Modal /> component only needs two props: onClose and isOpen. Our modal is only concerned with these props because they're the only two things our modal needs to control.

If you want to style an inner component, you can find the inner component and style it directly.

By keeping control over the content entirely with the developer, you spend less time tinkering with the limited controls you get from props like modalFooterStyles.

Unopinionated

We've found that the more presets a component library has, the more you end up having to fight against.

Tools like Bootstrap are excellent for developers who want to put together a straight-forward app without overthinking the design.

But when building a UI with a custom design, you end up not only overriding included CSS, but adding extra CSS to your bundle that never gets used.

However, we don't want to provide unstyled components for those who do want to start a project quickly. We export a defaultTheme that you are able to overwrite and manually style every component in the library.

In addition, we also feature many examples of common UI patterns that are built with Minerva.

These are designed to be copy / pasted into your codebase to help you get started, allowing you to easily customize anything you need to down the road.

Accessible

We believe web UIs should always be accessible, even if you don't think your audience "needs" it.

Accessibility could be important for someone who prefers tabbing around a form on their keyboard or for someone who sustained a recent hand injury.

In addition, accessible rules are rules that people come to expect from a UI. One of the rules for a Modal or (Dialog) is that pressing esc should close the modal.

But when you ignore this rule and someone presses esc, user can frustrated because it's a behavior they've come to expect from accessibility compliant websites.

In this library, we try to leverage the great work in Reach UI as a foundation for making our components as WAI-ARIA compliant as possible.