1.0.0 ā€¢ Published 3 years ago

@nemethricsi/reach-ui v1.0.0

Weekly downloads
-
License
MIT
Repository
github
Last release
3 years ago

Welcome to Reach UI Development ā™æļø

Thanks for getting involved with Reach UI development!

Looking for the documentation?

https://reach.tech/

Getting Started

Reach UI is built and tested with Yarn. Please follow their install instructions to get Yarn installed on your system.

Then, run these commands:

git clone git@github.com:reach/reach-ui.git
cd reach-ui
yarn install
yarn build

Root Repo Scripts:

yarn build        # builds all packages
yarn start        # starts storybook server
yarn test         # runs tests in all packages

Running / Writing Examples

First do the steps in "Getting started", then start the Storybook server:

yarn start

Next, put a file in packages/<component-dir>/examples/<name>.example.js and make it look like this:

import * as React from "react";

// The name of the example (always name the variable `name`)
let name = "Basic";

// The example to render (always name the function `Example`)
function Example() {
  return <div>Cool cool cool</div>;
}

// Assign the name to the example and then export it as a named constant
Example.storyName = name;
export const Basic = Example;

// Default export an object with the title matching the name of the Reach package
export default { title: "Dialog" };

Now you can edit the files in packages/* and storybook will automatically reload your changes.

Note: If you change an internal dependency you will need to run yarn build again. For example, if working on MenuButton requires a change to Rect (an internal dependency of MenuButton), you will need to run yarn build for the changes to Rect to show up in your MenuButton example.

Running / Writing Tests

First do the steps in "Getting Started", then:

yarn test

Or if you want to run the tests as you edit files:

yarn test --watch

Often you'll want to just test the component you're working on:

cd packages/<component-path>
yarn test --watch

Development Plans

The components to be built come from the the Aria Practices Design Patterns and Widgets, with a few exceptions. Here is a table of the components and their status.

āœ… - Released šŸ›  - Building

StatusName
āœ…Accordion
āœ…Alert
āœ…Alert Dialog
āœ…Checkbox
āœ…Combo Box
āœ…Dialog (Modal)
āœ…Disclosure
šŸ› Hover Card
āœ…Listbox
āœ…Menu Button
šŸ› Radio Group
āœ…Slider
āœ…Tabs
šŸ› Toggletip
āœ…Tooltip

Releases

This is our current release process. It's not perfect, but it has almost the right balance of manual + automation for me. We might be able to put some of this in a script...

# First, run the build locally and make sure there are no problems
# and that all the tests pass:
$ yarn build
$ yarn test

# If you aren't already on the main branch, be sure to check it out
# and merge release changes from `develop`
$ git checkout main
$ git merge develop

# Generate the changelog and copy it somewhere for later. We'll
# automate this part eventually, but for now you can get the changelog
# with:
$ yarn changes

# Then create a new version and git tag locally. Don't push yet!
$ yarn ver [version]

# Take a look around and make sure everything is as you'd expect.
# You can inspect everything from the commit that lerna made with:
$ git log -p

# If something needs to be changed, you can undo the commit and
# delete the tag that lerna created and try again.

# If everything looks good, push to GitHub along with the new tag:
$ git push origin main --follow-tags

# Open up github.com/reach/reach-ui/actions and watch the build. There will
# be 2 builds, one for the push to the main branch and one for the
# new tag. The tag build will run the build and all the tests and then
# automatically publish to npm if everything passes. If there's a
# problem, we have to figure out how to fix manually.

# Paste the changelog into the release on GitHub. The release is
# complete ā€¦ huzzah!

You need to be careful when publishing a new package because the lerna publish on CI will fail for new packages. To get around this, you should publish a 0.0.0 version of the package manually ahead of time. Then the release from CI will be ok. This is really janky but AFAICT the only workaround.

Stuff I'd like to improve:

  • Automate changelog generation and GitHub release from CI
  • Document how we're using GitHub PRs to generate the changelog somewhere

Website

The website is a Gatsby app in the website directory. It automatically deploys to https://reach.tech/ when the website branch is updated.

Contributors

This project exists thanks to our contributors and financial backers.