avegancafe/reaction

Artsy’s React Components

      :::::::::  ::::::::::     :::      :::::::: ::::::::::: ::::::::::: ::::::::  ::::    :::
     :+:    :+: :+:          :+: :+:   :+:    :+:    :+:         :+:    :+:    :+: :+:+:   :+:
    +:+    +:+ +:+         +:+   +:+  +:+           +:+         +:+    +:+    +:+ :+:+:+  +:+
   +#++:++#:  +#++:++#   +#++:++#++: +#+           +#+         +#+    +#+    +:+ +#+ +:+ +#+
  +#+    +#+ +#+        +#+     +#+ +#+           +#+         +#+    +#+    +#+ +#+  +#+#+#
 #+#    #+# #+#        #+#     #+# #+#    #+#    #+#         #+#    #+#    #+# #+#   #+#+#
###    ### ########## ###     ###  ########     ###     ########### ########  ###    ####

Meta

• State: development
• Demo: https://artsy.github.io/reaction
• CI:
• NPM:
• Point People: @alloy, @l2succes & @damassi

Installation

$ git clone --recursive https://github.com/artsy/reaction.git
$ cd reaction
$ npm install -g yarn
$ yarn install
$ brew install watchman (If you don't already have Homebrew, go here for installation instructions: https://brew.sh/)
$ cp .env.oss .env

Instructions

• Development of components happen in storybooks:

    $ yarn start
    $ open http://localhost:9001/
  

• When working between Reaction and Force:

    $ yarn link && yarn watch
    $ cd ../force && yarn link @artsy/reaction && yarn start
  

• Run the tests:

    $ yarn test
  

• Run the tests continuously (or use vscode-jest):

    $ yarn test -- --watch
  

• In vscode, run the TypeScript: Run type-checker task and open the PROBLEMS view to see continuous type-checker results.

• After updating components, be sure to deploy a new demo (sharing is caring!):

    $ yarn deploy-storybook
  

• When using new changes in metaphysics’ schema, be sure to update the local schema copy:

    $ yarn sync-schema
  

• There are some suggested VSCode extensions in .vscode/extensions.json and additional docs at docs/vscode.md.

Commits and Deployments

Circle CI is set up to publish releases to NPM automatically via semantic-release following every successful merge to master.

Release versions (major, minor, patch) are triggered by commit messages, when they adhere to Ember conventions:

[TAG context] commit message

Valid tags for release include PATCH, DOC, FIX (patch), FEATURE (minor), and BREAKING (major). A context is also required (note that this should be one word). Commits that do not adhere to this convention will not trigger an NPM release.

Example Patch Release

[FIX onboarding] Modal does not open
[PATCH tooling] Bump version

Example Minor (Feature) Release

[FEATURE auctions] Add relay-based slider component

Example Major (Breaking) Release

[BREAKING publishing] Replace children with props for caption editing

Emitting types

We recently started shipping Reaction builds with declaration files (.d.ts) so consumers have access to the interfaces and types we add to our components. Because of that, you will notice errors resembling the following:

src/Components/Forms/OrderForm/App.tsx:63:14 - error TS4023: Exported variable 'StyledTitle' has or is using name 'TitleProps' from external module "/Users/lucsucces/Projects/reaction/src/Components/Title" but cannot be named.

63 export const StyledTitle = Title.extend`
                ~~~~~~~~~~~

What that error essentially means because you are exporting StyledTitle, the interface TitleProps also needs to be exported. You can learn more about declarations files here

Exporting interfaces

This also affects a bit how we declare our interfaces. Instead using a private Props interface as we've been doing

interface Props {
  ...
}

export class Icon extends Component<Props> {
  ...
}

you should write that instead

export interface IconProps {
  ...
}

export class Icon extends Component<IconProps> {
  ...
}

The more descriptive interface name (IconProps) is to get more useful error messages from the compiler when something goes wrong, and it's clearer which interface is being referred to in type defintion files.