UI component library build for React, used by REPAY.
For usage, see the documentation for Cactus Web
Running storybook for local development
Testing the build
Creating a new component
yarn new ComponentName
This will generate skeleton files for the component, tests, story, and documentation (.mdx) using the provided ComponentName.
Usage: node make-component.js [...options] ComponentName - component name must be the last argument, contain no spaces, and should be pascal case. Options: --help, -h display this information --force, -f overwrite component if it exists
Building the repository
Running the build in watch mode which will re-build on changes
Components should have associated stories so that you as a developer can test the component in an active situation. The convention is to create an primary story called "Basic Usage" which allows the user to control the required properties. Then additional stories are created for optional properties.
Components are ideally exported as a
styled component. This allows them to be styled directly by a parent component such as:
If the component is not a static tag like
styled.div, you can create a "base" component and style that:
The requirement here, is that the
className prop must be provided to the element that is being styled.
We use Styled System to help ensure theme value adherence and decrease the difficulty of proper customizations. Most components should provide the
Stories are both for development and documentation.
Documentation can be added directly to the mdx files alongside the components. You can also use the
'website-src' source alias which will point to the source root in the website directory.
The best practices section should include information related to accessibility or other critical information when using the component. However this section can be removed if there are none.
Basic usage section should have at least one example of usage as JSX. If usage in TypeScript is complex or interesting include that as well. Ideally any code written as basic usage can be copied and used directly.
A description can be added to a property via comment above the property definition. To force the inclusion of a property in the Properties section that is not showing up, add the prop to the definition with a comment above and type
!important in the comment.
Components should be tested from the perspective of the end-user as possible; this means using the
user-event library in combination with
react-testing-library. Additionally, when a label is rendered with text, it should be used to select the input element. This will best mimic the user's actions of reading the text to find the element and clicking or typing from there and enforces best practices for accessibility.
test'should trigger onChange event',
Also, be sure to test the negative cases alongside the positive, such as when there is a
test'should not trigger onChange event',