Local component library
Welcome to the official component library for Local!
What's included in this component library?
We appreciate curious minds and that's a great question! Take a quick look at our living component documentation here.
In additional to a quickly growing set of React components, we also have SVGs, SASS partials, and more to come!
- Clone and pull down the latest from the repo
- Install dependencies using
The quickest way to work on
local-components is to leverage Storybook. Storybook is a
local development area that works well with React components and supports hot-module reloading.
To start Storybook, run
Developing within Local
If you wish to work on
local-components and see the changes within Local, you will need to run the following:
local-components(only needed one time or after unlinking)
flywheel-local(only needed one time or after unlinking)
- Start Local
- Make any necessary changes in
local-components. Note, Local does not support hot-module reloading in all locations so refreshing the UI in Local (Cmd + R) will likely be necessary.
Running both Storybook and Watch at the same time
If you wish to run both Storybook and the watcher for Local at the same time, you can run
yarn start. Note, this particular
script spawns two instances of Webpack and is very resource intensive.
local-components library can be broken down into 3 main parts:
These are the visual elements that make up both Local and its Add-ons.
There are currently 40+ React components in the library.
Each component consists of a
README.md and optional
Try it out for yourself!
- Make changes to the internals of a component through its
.sassfiles (they should live reload)
- Play around with the examples found in the
- Have an idea or bug fix? Submit a pull request.
Note: the entry point for all components and styles is
Several components leverage the
Container.tsx component to wrap their own implementation.
Container is a highly specialized component that can be toggled on (wraps contents in extra div) or toggled off (no extra div).
In addition, the Container wrapper adds convenience props that allow for easy one-off adjustments like adding 3px of margin without conflicting with the inner content's classes and styles.
Note: setting any of container's props will automatically toggle it on (disabled: false) thus wrapping the contents in the container wrapper.
Components are organized by type. These type groups can be seen when running Storybook.
Naming is hard. And there's no perfect system. That said, we have chosen Suit CSS for naming conventions.
Note: instead of dashes, local-components uses underscores due to a limitation of a legacy package.
The component library leverages CSS Modules to manage and scope styles.
These are considered local styles (not to be confused with the Local app
local-components and avoid collisions.
As wonderful as local styles are, there are instances where CSS needs to transcend a single component. For that, we make use of global styles. Global styles should be familiar to most as that's what the web largely used for 20+ years. Global styles are intended to be used sparingly as they introduce a lot of challenges when scaling an app with a library of Add-ons and Environments.
The following is an instance where a scoped component may use a combination of local and global styles to achieve a specific result:
This is something we try to avoid and are actively working to whittle down to the bare essentials.
If you'd like to learn more about scoped styles, please check out CSS Modules here.
SASS Partials, Mixins, and Functions
There is an extensive sass system in use that many -- if not most -- components leverage.
If you search for the
_partials directory, you will find variables, mixins, functions, and other shared resources.
If Local uses a color, it's defined as a variable within the
In addition, there are fonts, font sizes, font weights, and margin/padding preset values here.
Note: font sies and margin/padding uses t-shirt sizes to indicate relative sizing while adhering to strict design standards/values.
Local has both light and dark modes. Since this impacts every single components, the
_theme.scss file contains
mixins that simplifies the implementation of these variations in a repeatable and predictable way.
While you could leverage
if-theme-dark directly, most light/dark combinations follow a specific pattern and therefore have dedicated mixin.
For example, the
theme-color-black-else-white mixin applies the
color style of black (if light) otherwise white (if dark).
Another example, the
theme-background-green-else-graydark mixin applies the
background style of green (if light) otherwise graydark (if dark).
Note: light/dark mode styles are applied by toggling a class added to the
htmlelement (e.g. Theme__Light).