Creating a component
In this guide, we'll walk through creating a custom component in HSDS!
We do encourage you to have a look at other components and follow how thay are put together, you might learn a thing or two, which is always a good thing!
We'll be created a
Strong component, an enhancement to the default HTML strong primitive.All of HSDS's components are located under
src/components/:hsds-react/
└── src/
└── components/
The first thing we'll need to do is create a dedicated
Strong directory under Components/:hsds-react/
└── src/
└── components/
└── Strong/
Under our newly created
Strong/ directory, we'll need to create a few files:index.jsStrong.jsxStrong.css.jsStrong.test.jsStrong.stories.mdx
hsds-react/
└── src/
└── components/
└── Strong/
└── Strong.css.js
├── index.js
├── Strong.jsx
├── Strong.test.js
├── Strong.stories.mdx
└── Strong.utils.js
The
index.js file is the main file allow the consuming App/component to use Strong.The
Strong.jsx file our actual React component.Using the provided component generator npm script creates templates that includes all the files for you (component jsx, css, stories and test files) that follow our general patterns.
npm run remake --name="Strong"
Add the starting React component boilerplate for
Strong.jsx:import React from 'react'
import PropTypes from 'prop-types'
import getValidProps from '@helpscout/react-utils/dist/getValidProps'
import classNames from 'classnames'
import { StrongUI } from './Strong.css.js'
class Strong extends React.PureComponent {
render() {
const { children, className, ...rest } = this.props
const componentClassName = classNames(
'c-Strong',
isSuperBold && 'is-superBold',
className
)
return (
<StrongUI {...getValidProps(rest)} className={componentClassName}>
{children}
</StrongUI>
)
}
}
Strong.defaultProps = {
isSuperBold: false,
'data-cy': 'Strong',
}
Strong.propTypes = {
/** Awesome prop to make this component super bold */
isSuperBold: PropTypes.bool,
/** Data attr for Cypress tests. */
'data-cy': PropTypes.string,
}
export default Strong
Whoa 😳! Lots of stuff going on already!
Creating a component class from extending
React.PureComponent works seems to work best for component libraries.Compared to a
React.Component, it's often more performant and faster since it shallow diff's props when React needs to re-render.If you're expecting your Component to have a bunch of deeply nested, logic heavy child components, extends from
React.Component instead of React.PureComponent.Compared to Stateless-Functional Components, the pros are many, which include:
- Ability to reference DOM nodes
- Standardized component structure
- Prop-diffing, so that it doesn't re-render all the time (this is a big one)
It is used to both define your component's
className, and to extends the className prop.Always give your components a className. Even if it's not directly attached to a CSS style rule. The main reasons are for inclusivity and thoughtful architecture.
The concept of markup and classNames can be understood by everyone who knows HTML. That allows for non JS/React folks to inspect to understand/debug the UI. It also allows for folks to write tests that explicitly target selectors.
The second point is thoughtful architecture. HTML is the foundation to your React component. It's critical to get this right to make your components/app accessible and easy to reason about/comprehend. There has to be a purpose for every single HTML selector added to a React component. Describe that reasoning with a thoughtful className.
Any prop that can modify a components appearance or behaviour is added as a
className under componentClassName. This is to both apply styling and to better communicate a component's state within the DOM (for debugging/testing/targeting).These modifier classNames should typically be prefixed with words like
is-, has-, with.HSDS's components are designed to be used as if they were default HTML elements. The
...rest pattern allows for users to pass in custom (but HTML-supported) props like:ariarolesdata-attributestitle
(Just to name a few)
It also allows for the user to hook into default React props, like:
onMouseEnteronClickhtmlFor
getValidProps() is a special utility function that filters out non-default HTML/React props. This prevents React from throwing errors if non-default props are accidentally passed during the Object spread process.Wonderful 🙏! You've created the base for
Strong, that's performant, easy to extend, and Flow typed.Your component might need different functions, constants or other stuff that don't need to live inside of it, the place to put those is inside your utils file:
Strong.utils.js.We'll need to export
Strong to make it simpler to import and use. This is all done in our index.js file:import Strong from './Strong'
export default Strong
Whoa 😳! More stuff!
All of HSDS's components are made available in
components/index.js:hsds-react/
└── src/
└── components/
└── index.js
Open that file. You should see a bunch of exports listed in alphabetical order. Add
Strong:...
export { default as Strong } from './Strong'
...
And that's it 🙏! You've successfully created, hooked up, and exported our new
Strong component 💪.You'll quickly notice a pattern to everything we add inside a component. The reason for this is that HSDS has many components! And when you are working inside your code editor, it's easier to find what you need if everything is named following a convention.
Below is a summary of things to pay attention to with examples of a slightly more complex component:
We try to follow a one-level folder structure for the most part but sometimes a component is too complex and composed of multiple smaller components, to give structure add folders as needed, for example:
hsds-react/
└── src/
└── components/
└── Table/
└── __tests__/
├── Table.Cell.test.js
└── Table.test.js
└── styles/
├── Table.Cell.css.js
└── Table.css.js
└── stories/
├── Table.stories.mdx
└── TableBody.stories.mdx
├── index.js
├── Table.jsx
├── Table.Cell.jsx
├── Table.utils.js
Last modified 1yr ago