CL-UI Component System

Setup

yarn

copy example.env as .env

Development

run:

yarn start

To run tests:

yarn test

Open http://localhost:6006 in your browser. It is your Storybook with CL-UI components.

Process of creating a component

When creating a new component, decide on where the component should reside. As a general rule, very simple components that do not use other components, put it into the core folder, more complex components probably using multiple single components (from MUI) into the compound folder.

Folder Structure

| Folder | Rule | | ----------------- | ----------------------------------------------------- | | src/components/ | for simple core components |

Component Files

  src/core/MyCoreComponent
    index.js
    MyCoreComponent.jsx
    MyCoreComponent.notes.md
    MyCoreComponent.stories.{js,mdx}
    MyCoreComponent.test.js

Each component folder defines a seperated and isolated component, containing the implementation, a story explainin the use cases and a test, which tests the functionaliy of the component. Naming is important here. Always start components with an Uppercase Letter. If it contains JSX, end it with .jsx. There is always an index.js which exports the component itself as a default, but also maybe different variants or necessary side modules or helpers as named exports.

Each component should have a corresponding .stories.js file for usage in the storybook. The stories should represent and document all the necessary information to know how and why to use this component, and which Parameters affect it in what way. The .notes.md File can be used to add additional MDX documentation as 'notes'.

Component storis should be written using the new Component Story Format (CSF).

Alternatively you can use MDX flavoured CSF directly when using the .stories.mdx extension.

Each component should also be tested in a way that edge cases are represented. (No inputs, long inputs, short inputs, weird inputs)

Testing

unit testing: testing an isolated part of your app, usually done in combination with shallow rendering. example: a component renders with the default props.

integration testing: testing if different parts work or integrate with each other. Usually done with mounting or rendering a component. example: test if a child component can update context state in a parent.

e to e testing: Stands for end to end. Usually a multi step test combining multiple unit and integration tests into one big test. Usually very little is mocked or stubbed. Tests are done in a simulated browser, there may or may not be a UI while the test is running. example: testing an entire authentication flow.

Rules for Hooks

Don't think in lifecycles.

The question is not "when does this effect run" the question is "with which state does this effect synchronize with"

useEffect(fn) // all state
useEffect(fn, []) // no state
useEffect(fn, [these, states])

— Ryan Florence (@ryanflorence) May 5, 2019