@sproutsocial/racine

Racine

React components for Sprout Social's user interfaces

📖 View the documentation for Racine in Sprout's design system, Seeds ▸

🆕 Learn about what's changing in the CHANGELOG.md file ▸

🚧 Check out the project board to see what's in-flight and upcoming ▸

---

Installation

To work on Racine, you will need to set up your environment to use Artifactory.

Follow the instructions to do so on the wiki.

Then, copy the _auth and email settings in your $HOME/.npmrc into environmental variables in your shell's rc file (e.g. $HOME/.zshrc or $HOME/.bashrc), then re-source your rc file.

export JFROG_AUTH="_auth string goes here"
export JFROG_EMAIL="email string goes here"

Install Racine using npm or yarn:

$ yarn add @sproutsocial/racine react styled-components
# or
$ npm install @sproutsocial/racine react styled-components

You may also require specific peer dependencies when starting a new project or sandbox environment:

@sproutsocial/seeds-border
@sproutsocial/seeds-color
@sproutsocial/seeds-depth
@sproutsocial/seeds-motion
@sproutsocial/seeds-networkcolor
@sproutsocial/seeds-space
@sproutsocial/seeds-typography
moment
prop-types
react
react-dates
styled-components

Then, wrap your app's React root in Racine's ThemeProvider component:

import {ThemeProvider} from '@sproutsocial/racine';

const App = (props) => (
  <ThemeProvider>
    <div>your app here</div>
  </ThemeProvider>
);

Documentation

Racine is documented in Sprout's design system, Seeds ▸

Racine uses Storybook as a local development environment, and for running tests against components. Every component has a .stories.js file where developers can write "stories" to test components in isolation. Running yarn start will open the Racine Storybook in your browser so that you can see changes live as you make them. You can read more about writing stories on the Storybook website.

Local development

Racine uses Storybook for local development. Here's how to get started:

1. Clone this repo: git clone https://github.com/sproutsocial/racine
2. Follow these instructions to configure Artifactory for dependencies: https://sprout.atlassian.net/wiki/spaces/INFRA/pages/3380249272/Getting+started+with+Artifactory+for+NPM+Yarn
3. Copy the _auth and email settings in your $HOME/.npmrc into environmental variables in your shell's rc file (e.g. $HOME/.zshrc or $HOME/.bashrc), then re-source your rc file.

export JFROG_AUTH="_auth string goes here"
export JFROG_EMAIL="email string goes here"

1. Install dependencies: yarn
2. Run the dev app: yarn start

💡 If you need to test local Racine changes in another project, click here to learn how.

Test any local package in another project by utilizing yarn link. Below is an example workflow to link Racine to web-app-core.

1. Navigate to your local copy of Racine in a terminal window

$ cd ~/YourCodeFolder/racine
$ yarn link # only needs to be run once
$ yarn start

Note: This build task packages all Racine components into the bundle, not just the specific components you are adding or modifying. After yarn link succeeds and Racine is globally linked, you shouldn't have to run link again.

1. Navigate to the folder you wish to use Racine components in your terminal (such as web-app-core) and complete the link

$ cd ~/YourCodeFolder/web-app-core
$ yarn link "@sproutsocial/racine"
$ yarn start

1. You can now use any components from your local instance of Racine in your project. See below for an example usage

/* ~/YourCodeFolder/web-app-core/YourFile.js */
import {Icon} from '@sproutsocial/racine';
// ...
<Icon name="compose" />;

1. When you are done, be sure to unlink Racine so you are using the app's version of the package

$ yarn unlink "@sproutsocial/racine"
$ yarn

Contributing

The Design Systems team works on a regular two-week sprint cadence to iterate against Racine's roadmap and assist in any ad-hoc issues that may come up. That said, contributions to Racine are welcomed from any member of the wider Sprout org. Whether you're adding a new component or simply fixing a bug, every improvement to the library is future leverage for our peers, our product, and our customers.

When writing code for Racine, please refer to the code-guidelines.mdx story in Storybook.

🔍 Step 1: Find a way to contribute

There are a few ways to get involved:

• Join #design-systems on Slack to participate in discussions about Racine's development.
• Check out the issues tab of this repository. Issues contain community-collected bugs and features that need attention. If you're looking for an easy way to jump in, we have a label which shows issues that are good for first-time contributors.
• The Design Systems team uses Jira to track our backlog, in-flight changes, and future changes. It's a great way to get a broad look at what's happening in Racine, and tracks the squad's work from sprint to sprint, and release to release.

🗺 Step 2: Find your way around

Racine's file structure is set up like this:

• codemods - For major updates to Racine that have breaking changes, codemods are included for automatically handling component API updates.
• src
  • ComponentName - Every component in Racine has a folder within the src directory.
    • index.js - This file should export the component as its default export.
    • index.stories.js - Storybook stories can be written here.
    • index.test.js - All component tests live inside this file.
    • styles.js - Any style-specific components live here.
  • utils - This directory includes a set of common utilities and helpers that we use throughout Racine.

And you can interact with Racine via the command line with these commands:

• yarn new - This command will prompt you for the name of your component, and then generate all of the boilerplate you need to create the component.
• yarn start - This will watch the Racine package for changes, and also run Storybook locally so that you can see your changes as you go.
• yarn change - This command will generate a changeset file that is used to document changes to the Racine package. If you are making a PR to Racine that should result in a version bump to the package, you will need to run this command to add a changeset. You can learn more about this command in step 3.
• yarn build - Generate production builds for the Racine package.
• yarn test - Run Racine's test suite. Note: yarn start must be run before yarn test to build generated files and directories
• yarn clean - Delete all generated files and directories.
• yarn release - This will trigger the release process for creating a new version of the Racine package on npm. Only Racine administrators can perform the release process.

✅ Step 3: Make your changes

Cut a feature branch off dev and start coding! As updates are merged into dev by other developers over time you'll want to pull those updates into your branch, ideally via rebase, to avoid any conflicts when you open a pull request.

Need to make an urgent update? Branch off main instead of dev, and open your PR later against main. We consider this a hotfix and only support it for critical time-sensitive updates, so check with the Design Systems team prior to making this kind of contribution.

We use a visual regression testing suite to capture any unintended changes during development. After running yarn build you can run the suite locally with yarn backstop-test, which will open a report in your browser to show you what passed and what failed. If any fails are actually intentional visual changes you can run yarn backstop-approve to approve those changes as new reference images and include them in your PR.

As you develop you'll want to track the scope of the changes you make. Racine supports this with a tool called changesets to automatically pick new version numbers and update the changelog whenever we publish a new version of the package.

Run yarn change to generate a changeset that will be used to derive the next version number for Racine from your changes.

We use semantic versioning for the Racine package, which allows users to understand the scope of a package's changes based on the version number, which is in the format major.minor.patch.

When running this command, you will be asked to select whether your change is a patch, minor, or major change.

• patch changes are for bug fixes, and they bump the last digit in the version number (x.x.0)
• minor changes are for new features or improvements, and they bump the middle digit in the version number (x.0.x)
• major changes are breaking changes, and they bump the first digit (0.x.x). These types of changes are rare and should be coordinated in advance with the Design Systems team.

The changeset CLI will also ask you to input a message detailing your changes. The completion of the command will generate a new changeset markdown file. You are more than welcome to edit this file after it has been generated, so don't get hung up on trying to write the perfect text from the command line. Aim to make the text of the changeset file(s) as descriptive and informative as possible, as they will be used to build a changelog file when the new version is released. Check out our documentation for the Seeds Release Process for examples of what makes a good or bad changeset.

You can add as many changesets to a PR as you would like. If your PR makes several distinct changes to Racine, you should create a changeset detailing each one individually.

🗣 Step 4: Create a pull request

Once you're ready to submit your changes for review, open a PR against the dev branch. A few things will happen:

• The Racine maintainers will be tagged to review your code. Feel free to additionally tag any specific individuals who you think should take a look.
• Visual regression testing will run against your PR, and the results can be found in the "Report" artifact on the summary page for the associated Github Action run. html_report/index.html in Report.zip will show you what passed and what failed.
• Racine's test suite will run via CI, and the status will be reported on the PR. You can run yarn test to run these tests locally. If there are any issues, they will need to be resolved before the PR can be merged.
• Netlify will create a preview deploy of Racine's Storybook and include a link to it in a comment on the PR so you can see your changes and share them with others.
• A Racine package snapshot including your changes will be published to Artifactory and included in a comment on the PR so you can install it locally or in a web app PR/snapshot in order to test your changes.

You may be asked to make changes to match Racine's contribution guidelines, so expect to keep attention on your PR for a little bit. Once your tests are passing and you have at least one approving Design Systems review, a member of the Design Systems team will merge your changes for inclusion in a future release of Racine! Please do NOT merge your own PR unless expressly told to, since commits to dev end up in the next release, and the Design Systems team needs to make sure they have the bandwidth to validate any contribution before it releases.

☁️ Step 5: Changes get published to Artifactory

When the Design Systems team prepares the next Racine release, changsets will generate a PR called Version Packages. This PR will detail all of the changes that have been made to the package since the last publish. Merging this PR will release a new version of Racine.

When the PR is merged, GitHub will kick off a publish of the new version. There will be a notification in #design-systems in Slack when the new version is available.

✍ Step 6: Document your changes

Racine components are documented in Seeds, Sprout's design system. You can open a PR to the Seeds repository to add or edit component documentation. It's a good idea to have documentation changes ready to go at the same time your Racine contributions are deployed, so start early! Reach out to the Design Systems team if you need help getting started.