We appreciate contributions of all kinds -- whether that is a bug fix, or a new component.
Before making a PR with a brand new component, hook or feature, it may be helpful to consider whether it solves the following:
- Can the feature be used across multiple MongoDB Products?
- Is it abstracting logic that many developers or components could utilize?
- Have you considered how to make this as generalizable as possible?
If you're interested in contributing, and want to know what projects we have on deck, check out our roadmap here.
LeafyGreen uses TypeScript, to help make consumption of this library as intuitive and error-free as possible. If you're new to TypeScript, these resources may be able to help you get started:
For styling, we use the CSS-in-JS library, Emotion. To get started with Emotion check out their documentation here.
We've created a wrapper around the Emotion library, which can be brought into new components as such:
import { css, cx } from @leafygreen-ui/emotion
When using the library, you must use our Emotion instance, because of constraits over how styles are injected into the page.
As far as design patterns leveraged by our components we tend to favor:
- Functional components over class-based components
- Creating abstractable hooks where possible, that can be used across multiple components
- Native Array methods to bringing in other libraries, such as Lodash
- Using default exports over named exports
Approaching components in an accessible manner is something we take seriously on this team. That being said, we have some technologies in place to enforce that new components, or updates to existing components, are being developed with these standards in mind.
eslint-jsx-a11y
This is a static AST checker for accessibility rules on JSX elements.
@storybook/addon-a11y
We have an accessibility addon in our storybook, next to the knobs tab, which checks for a11y violations in components. While developing, please be sure that your component does not fail any accessibility checks here.
To note: The addon is not able to detect information on the DOM that is portaled. Therefore, if working with a portaled component, please be sure to test the component’s accessibility without portaling the content.
When you run the scaffold script, a README file will appear, which is a template for how we document our components. Beyond just README documentation, we use @ts-docs to self-document each component. Please follow this pattern when creating new components or adding props to existing components.
We use @testing-library/react for writing tests locally. This library helps mock out user interactions with components. You can run all tests by running yarn test or turn on watch mode with yarn test --watch.
We also have a link script, such that you can test components that are in development in environments beyond Storybook. To do so, run yarn run link -- [path-to-application].