Building Reusable Components…

That Are Actually Reusable

Twitter: @housecor
Consulting: reactjsconsulting.com
Courses: pluralsight.com/author/cory-house
As society advances, we
take more things for
granted.
 Reusable Component Decisions
Core Decisions Design Testing
Core technology Wrap HTML primitives? Framework
Audience & support team model Folder structure Assertions
Declare propTypes? Helpers
Rigid or flexible
Apply custom props? Unit
Link, wrap, or fork Defaults? Interaction
Accessibility Structural
Dev Environment Server rendering Style

50 Decisions
Boilerplate, doc lib, or custom Config object vs. primitives When to run
Library or standalone Atoms Where to place tests
Monorepo or separate Molecules Continuous Integration
Organisms
Documentation Deployment
Styling Dependency declarations
Off-the-shelf or custom
CSS Technology Hosting
Generating documentation Inline vs external Versioning
Search Namespace Import approach
Syntax highlighting Naming scheme Declaring package files
Interactive playground Offer unstyled components? Output formats
Hosting Theming Pre-publish testing
Automated deployment Build process
This is about to get So, I’m a big fan of TypeScript…
interesting…

Remind me, how did being a “big

fan” of Silverlight work out,
Tanya?
Why reusable components?
1. Consistency
2. Less Code
3. Faster development
4. Fewer bugs
The modern dev shop is
becoming an assembler of
finished components.
</SalesPitch>
Decisions
 Audience
Rigid vs Flexible
Atomic Design
Link, wrap, or fork?
Wrap HTML primitives
10 KEY DECISIONS
When to add
Styling approach
Documentation
Open/inner source
Package hosting
Decision:
Audience
 Decision 1: Audience

Project
Team
Business
Public
 Audience

Public
Business

Team
Start here

Project

Difficulty
 Start small.
Start specific.
 Decision:
Rigid or flexible?
Style
- Colors
- Padding
- Size
- Font

Layout
- Horizontal vs vertical
- Media query cutoff points

Data display
Logic
Rigid Flexible

Simpler to create and implement Reusable in more contexts

Easier to understand

Easier to test

Less work to maintain

More opinion = more consistency, less fatigue

Easy to add flexibility, hard to remove

The Tragedy of the Commons
Individuals behave contrary to the common good
Can’t we just make
that configurable?

Let’s handle this via

a new component
instead.

Props are easy to

add…but hard to
remove.
Consistency Flexibility
Simplicity Features
 Start rigid.
Add flexibility as required.
 Decision:
Atomic Design
Atomic Design
Atoms Basic building blocks
Molecules Groups of two or more atoms
Organisms Groups of molecules functioning together
Atoms Molecules Organisms
 Home Page

Model View Controller

Data HTML Logic

Product Page

Model View Controller

 AuthorPhoto

NavLink AuthorCourses

CourseSummary

StarRating

SidebarNav

AuthorSummary
React: Nested Components
atomicdesign.bradfrost.com
 Difficulty

Reuse

Atom
Molecule
Atom

Atom Atom Molecule Atom

Atom

Atom Molecule Organism

Atomic Design
=
Modular Design
5 Stages of Atomic Design

1. Atoms
2. Molecules
3. Organisms
4. Templates
5. Pages
Atomic design = hierarchy.
 Decision:
Link, wrap or fork third parties?
 Link Wrap Fork
Here’s a suggestion Pretend we built it Own it
 Link

Documentation Rely on third party

Changes Watch repository
New Features Free
Customization None
Styling Provide separate styles
Cohesion Low
Commitment Low
Ease Very easy
 Wrapping a Component

// DatePicker.js
import SuperDate from ‘super-date’;

class DatePicker extends React.Component {

render() {
return <SuperDate /> Decide which props to pass
Change prop names
} Decide which props to expose
Hard code in styles/config
}
 Wrap

Documentation Integrated
Changes Choose when to upgrade
New features Choose when to upgrade
Customization Some. Enhance / abstract
Styling Varies
Cohesion Varies
Commitment Low
Ease Medium
 Fork

Documentation Integrated
Changes Full control
New Features Your responsibility
Customization Full control
Styling Built-in styles
Cohesion High
Commitment High
Ease Hard
 Fork

Wrap
Start here.

Link

Control and Effort

 Decision:
Wrap HTML primitives?
Form Decisions

Horizontal or vertical?
Errors at top, by field, or both?
Show errors on blur or submit?
Mark required fields? If so, how?
Tie label to input via htmlFor?
Padding below each input?
 TextInput Opinions
Designed for private use

Vertical layout
Padding below
Required htmlFor for accessibility
Red asterisk if required
Errors in red below the input
Could add…
Textarea support
Automatic placeholder
Validation onBlur
Demo

HTML primitive wrappers

Consistency

Decision
Fatigue
What you make unconfigurable is as
important was what you make
configurable.
 Decision:
When should I add a component to
the library?
“A reusable component should be tried out
in three different applications before it will
be sufficiently general to accept into a
reuse library.”
Jeff Atwood
“Once we proved that the Stack Overflow engine
could scale to these three distinct communities, I
was comfortable pursuing Stack Exchange, which
is now a network of
over 100 community-driven Q&A sites.”
Jeff Atwood
 Rule of Three:
Try a component in three different spots
before placing it in a reuse library.
Create a “reusable” folder
Central place to store app-specific reusable components
Decision:
Styling
 React Styling Approaches

Plain CSS Compiled CSS Inline Styles

CSS Modules CSS in JS

 CSS Sass/Less CSS Modules Inline styles CSS in JS

Deterministic No No Yes Yes Yes

Explicit application No No Yes Yes Yes
Dead code elimination No No Yes Yes Yes
Encapsulated No, but BEM helps No, but BEM helps Yes Yes Yes
Collocated No No No Yes Yes

Themeable Yes Yes, change variables Yes, but no standard Not easily Varies

Full CSS Support Yes Yes Yes No Not typically

Write standardized CSS Yes No Yes, or Sass/Less/PostCSS No Varies

Generate plain CSS during build Yes Yes Yes, but dynamic class names No Varies
Syntax highlighting Yes Yes Yes It’s JS Varies

Autocomplete when writing Yes Yes Yes No No

Autocomplete when using No No No Yes Yes
Library lock-in No Yes CSS, no. In React, yes Yes Varies
Requires wrapper component No No No No Varies
Server side rendering support Yes Yes Must run webpack on server Yes Yes
Post-processing support Yes Yes Yes No Varies
Lintable Yes Yes Yes No Not typically

Build Setup None webpack loader css-loader, or PostCSS None None

Style testing setup Test via screenshots Test via screenshots Config tests to ignore None None
 Decision:
Documentation strategy
 Goal:
Your docs are your dev environment
 ComponentPage

Navigation
Example

CodeExample

Props
 Dev Environment Options

Boilerplate Doc tool Build Your Own

 Dev Environment Options

Option 1: Over 100 to choose from!?

Boilerplate
andrewhfarmer.com/starter-project/
 Dev Environment Options

React Storybook
React Styleguide

Option 2: React Styleguidist

Doc Tool Atellier

Bluekit
Cosmos
getstorybook.io
github.com/styleguidist/react-styleguidist
github.com/pocotan001/react-styleguide-generator
bluekit.blueberry.io
 Dev Environment Options

Option 3: Custom Build your own

Don’t build docs by hand
 Why Generate Docs?

Code and docs in sync More readable code Enforced consistency

Demo

Custom component documentation

 Potential Doc Enhancements

Search Hide “internals” Group components

Live prop toggles Markdown support Live code editing

 Decision:
Closed, inner, or open source?
Consider open-sourcing your
components
Consider “Inner Sourcing”

Components are internally “open source”

No team owns a component
Everyone uses and contributes
 Centralized Inner sourced
Single group “on the hook” No bottleneck
Avoid duplication More involvement
More investment
Decision:
Hosting
😲
 Universal Package Managers

Advantages Disadvantages
Complete control Undiscoverable
Centralized asset hosting Must grant access
Avoid separate fees for each type Must configure registry setting
Easier on-boarding / management
Let’s wrap up.
 Reusable Components - Recap
Audience Start small
Rigid vs Flexible Start rigid
Atomic Design Start with atoms. Then Molecule, Organism
Link, wrap, or fork? Link if you can. Fork if you must.
Wrap HTML primitives Programmatically enforce standards
When to add Rule of three
Styling approach See “Creating Reusable Components”
Documentation Generate it
Open/inner source Consider inner sourcing
Package hosting Consider asset repos
PLURALSIGHT.COM
reactjsconsulting.com