patio-ui v0.1.3

Instalation

🚧 This is still in an experimental phase so please do not try at home! 🚨

  yarn add @wizeline/patio-ui

Usage

🚧 This is still in an experimental phase so please do not try at home! 🚨

  import { Button } from '@wizeline/patio-ui';

  /* ... */

  <Button variant="primary" onClick={...}>
    Hello
  </Button>

Contributing

The following contributing guide will help you learn about the development process, patterns and best practices guides that we follow in the Patio team, as well as teams across Wizeline.

The Tech Involved

We try to utilize the fact that this is a side-project for most of us and use cool 'modern' technologies that we want to learn or think that can be useful for us to learn.

For this project, we use:

• ⚛️ React with Typescript
• 💅🏻 styled-components & styled-system to add personality to our components
• 🎨 Storybook to display our components and documentation
• 🛠 Jest & react-testing-library for unit testing

We use Storybook to develop and showcase our components and their docs, you can see below to learn about useful commands:

Running Storybook Locally

Install the project's dependencies:

yarn install

After installing the dependencies, run the following command to run Storybook on your computer:

yarn sb

Run the following command to run the tests for the components or follow the instructions on screen to run the tests for a particular component:

yarn test

We encourage you to run the test command when developing or working on an existing component to make sure nothing breaks. (We are adding a pre-push hook to run tests before pushing to the repo, but you can never be too safe 😉).

Build Storybook (crates a folder named static containing the static assets generated to display a page):

yarn build-storybook

You can also test the built static page generated with the build command running the following command (in the root of the project):

npx http-server ./static

The command to deploy the storybook is the following (IMPORTANT: Please do not use this command unless it is totally necessary, we have an automated action that deploys the storybook when we merge code into the main branch):

yarn deploy-storybook

Structure, Patterns & Best Practices

We follow the structure you see below when creating new components:

 |
 |__ components
    |
    |__MyComponent
      |__index.tsx
      |__MyComponent.tsx
      |__MyComponent.test.tsx
      |__MyComponent.styles.tsx
      |__MyComponent.stories.tsx
      |__MyComponent.types.ts

🚧 We are working on adding a library/command to generate these folder structures automaticall based on a template (hygen) when creating a component from scratch so stay tunned for that. 📺 👀

Git Contributing Guidelines

Branching Model

Branches keep the code organized. Following the convention branch-per-feature, create a new branch whether you are developing and pushing a WIP, feature, bug fix, or an experiment.

Branch Naming Conventions

The following rules are a common convention for naming Git branches:

1. Start the branch name with a Grouping Token
2. Add the Issue Tracker Number after the Grouping Token, if available
3. End the branch name with Description Tokens
4. Separate branch parts by slashes (/)
5. Don't use numbers to start your branch name
6. Use short nouns for Grouping and Description Tokens

<grouping-token>/<tracker-number>/<description-tokens>

Examples:

group1/XXXX/lead-foo
group1/YYYY/lead-baz
group2/lead-bar
group3/lead-foo

Grouping Tokens

Grouping Tokens are the ones in front of the branch name. Use one of the next defined tokens to group the branches.

• feat for creating or improving a feature.
• bug for fixing a bug in an existing feature.
• test for adding tests or improving test coverage.
• chore for updating tasks that have no production code change.
• doc for improving READMEs or other Markdown documents.
• junk for experimental features not to be merged.

Issue Tracker Number

Issue Tracker Number is the one after the Grouping Token, if exists. It is the issue number assigned to the feature or bug in the project's issue tracking tool.

Examples:

feat/RSSI-12/order-blueprints
bug/RSEM-10/sticky-navbar
test/RCMY-9/post-model-attributes
junk/RUMS-49/login-bug-test

Description Tokens

Description Tokens are the ones at the end of the branch name. These tokens must match your flow and are personalized depending of your code addition or subtraction.

Examples:

feat/order-blueprints
bug/sticky-navbar
test/post-model-attributes
junk/login-bug-test

Commit Messages

Avoid this

Commit messages must be understandable for future reference, bug tracking, or code history. The ideal commit message consists of two parts, reviewed below. First, let's take a look at the following commit model.

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical, unless you omit
the body entirely; tools like rebase can get confused if you run the
two together.

Since the diff of the commit already describes "what" changed, this detailed
explanatory text should describe "why" the change was made.  As a project ages
it is often useful to use `git blame` or review the history of the file to see
why the code is designed the way it is.  At the moment you are creating a
commit, you know more about "why" you are making that decision than you will in
the future, so while adding this context might seem obvious now it is often
useful down the road.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug."  This convention matches up with commit messages generated
by commands like git merge and git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, followed by a
  single space, with blank lines in between, but conventions vary here

- Use a hanging indent

Use the following established conventions for writing commit messages.

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Start the subject line with a capital letter
4. Don't end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

Submitting Pull Requests

Title

Title must be clear and up to 75 characters. It should include the Grouping Token, as the branch specifies, the Issue Tracking Number, if available, and a short description of the PR.

<grouping-token> - <tracker-number> - <Short description>

If a PR is not completed, add the tag [WIP] at the beginning of its title.

[WIP] <grouping-token> - <tracker-number> - <Short description>

Description

When submitting PR with your work, please follow the template you see on screen so that the reviewers have more context and have a better understanding of what to review and where to find it more effectively. Briefly, our teamplate looks like this:

- What does this PR do?
- Where should the reviewer start?
- How should this be manually tested?
- Any background context you want to provide?
- What are the relevant tickets?
- Use the format: Closes #X
- Screenshots
- Questions
- Type of change

Roadmap

🚧 Coming Soon