Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/chantastic/reactpatterns
Patterns for React Developers
https://github.com/chantastic/reactpatterns
component frontend javascript patterns react react-native react-patterns
Last synced: 25 days ago
JSON representation
Patterns for React Developers
- Host: GitHub
- URL: https://github.com/chantastic/reactpatterns
- Owner: chantastic
- Created: 2016-08-18T17:20:27.000Z (about 8 years ago)
- Default Branch: master
- Last Pushed: 2022-01-15T01:23:45.000Z (almost 3 years ago)
- Last Synced: 2024-10-01T22:01:18.797Z (about 1 month ago)
- Topics: component, frontend, javascript, patterns, react, react-native, react-patterns
- Language: HTML
- Homepage: http://reactpatterns.com
- Size: 171 KB
- Stars: 1,737
- Watchers: 61
- Forks: 101
- Open Issues: 7
-
Metadata Files:
- Readme: README.markdown
Awesome Lists containing this project
README
## Contents
* [Stateless function](#stateless-function)
* [JSX spread attributes](#jsx-spread-attributes)
* [Destructuring arguments](#destructuring-arguments)
* [Conditional rendering](#conditional-rendering)
* [Children types](#children-types)
* [Array as children](#array-as-children)
* [Function as children](#function-as-children)
* [Render callback](#render-callback)
* [Children pass-through](#children-pass-through)
* [Proxy component](#proxy-component)
* [Style component](#style-component)
* [Event switch](#event-switch)
* [Layout component](#layout-component)
* [Container component](#container-component)
* [Higher-order component](#higher-order-component)
* [State hoisting](#state-hoisting)
* [Controlled input](#controlled-input)
## Stateless function
[Stateless functions](https://facebook.github.io/react/docs/components-and-props.html) are a brilliant way to define highly reusable components. They don't hold `state`; they're just functions.
```js
const Greeting = () =>
Hi there!
```
They get passed `props` and `context`.
```js
const Greeting = (props, context) =>
Hi {props.name}!
```
They can define local variables, where a function block is used.
```js
const Greeting = (props, context) => {
const style = {
fontWeight: "bold",
color: context.color,
}
return
{props.name}
}
```
But you could get the same result by using other functions.
```js
const getStyle = context => ({
fontWeight: "bold",
color: context.color,
})
const Greeting = (props, context) =>
{props.name}
```
They can have defined `defaultProps`, `propTypes` and `contextTypes`.
```js
Greeting.propTypes = {
name: PropTypes.string.isRequired
}
Greeting.defaultProps = {
name: "Guest"
}
Greeting.contextTypes = {
color: PropTypes.string
}
```
## JSX spread attributes
Spread Attributes is a JSX feature. It's syntactic sugar for passing all of an object's properties as JSX attributes.
These two examples are equivalent.
```js
// props written as attributes
{children}
// props "spread" from object
```
Use this to forward `props` to underlying components.
```js
const FancyDiv = props =>
```
Now, I can expect `FancyDiv` to add the attributes it's concerned with as well as those it's not.
```js
So Fancy
// output:
So Fancy
```
Keep in mind that order matters. If `props.className` is defined, it'll clobber the `className` defined by `FancyDiv`
```js
// output:
```
We can make `FancyDiv`s className always "win" by placing it after the spread props `({...props})`.
```js
// my `className` clobbers your `className`
const FancyDiv = props =>
```
You should handle these types of props gracefully. In this case, I'll merge the author's `props.className` with the `className` needed to style my component.
```js
const FancyDiv = ({ className, ...props }) =>
```
## destructuring arguments
[Destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) is an ES2015 feature. It pairs nicely with `props` in Stateless Functions.
These examples are equivalent.
```js
const Greeting = props =>
Hi {props.name}!
const Greeting = ({ name }) =>
Hi {name}!
```
The [rest parameter syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters) (`...`) allows you to collect all the remaining properties in a new object.
```js
const Greeting = ({ name, ...props }) =>
Hi {name}!
```
In turn, this object can use [JSX Spread Attributes](#jsx-spread-attributes) to forward `props` to the composed component.
```js
const Greeting = ({ name, ...props }) =>
Hi {name}!
```
Avoid forwarding non-DOM `props` to composed components. Destructuring makes this very easy because you can create a new `props` object **without** component-specific `props`.
## conditional rendering
You can't use regular if/else conditions inside a component definition. [The conditional (ternary) operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator) is your friend.
`if`
```js
{condition && Rendered when `truthy` }
```
`unless`
```js
{condition || Rendered when `falsey` }
```
`if-else` (tidy one-liners)
```js
{condition
? Rendered when `truthy`
: Rendered when `falsey`
}
```
`if-else` (big blocks)
```js
{condition ? (
Rendered when `truthy`
) : (
Rendered when `falsey`
)}
```
## Children types
React can render `children` of many types. In most cases it's either an `array` or a `string`.
`string`
```js
Hello World!
```
`array`
```js
{["Hello ", World, "!"]}
```
Functions may be used as children. However, it requires [coordination with the parent component](#render-callback) to be useful.
`function`
```js
{(() => { return "hello world!"})()}
```
## Array as children
Providing an array as `children` is a very common. It's how lists are drawn in React.
We use `map()` to create an array of React Elements for every value in the array.
```js
- {item}
{["first", "second"].map((item) => (
))}
```
That's equivalent to providing a literal `array`.
```js
- first ,
- second ,
{[
]}
```
This pattern can be combined with destructuring, JSX Spread Attributes, and other components, for some serious terseness.
```js
{arrayOfMessageObjects.map(({ id, ...message }) =>
)}
```
## Function as children
Using a function as `children` isn't inherently useful.
```js
```
However, it can be used in component authoring for some serious power. This technique is commonly referred to as `render callbacks`.
This is a powerful technique used by libraries like [ReactMotion](https://github.com/chenglou/react-motion). When applied, rendering logic can be kept in the owner component, instead of being delegated.
See [Render callbacks](#render-callback), for more details.
## Render callback
Here's a component that uses a Render callback. It's not useful, but it's an easy illustration to start with.
```js
const Width = ({ children }) => children(500)
```
The component calls `children` as a function, with some number of arguments. Here, it's the number `500`.
To use this component, we give it a [function as `children`](#function-as-children).
```js
{width =>
```
We get this output.
```js
```
With this setup, we can use this `width` to make rendering decisions.
```js
{width =>
width > 600
?
: null
}
```
If we plan to use this condition a lot, we can define another components to encapsulate the reused logic.
```js
const MinWidth = ({ width: minWidth, children }) =>
{width =>
width > minWidth
? children
: null
}
```
Obviously a static `Width` component isn't useful but one that watches the browser window is. Here's a sample implementation.
```js
class WindowWidth extends React.Component {
constructor() {
super()
this.state = { width: 0 }
}
componentDidMount() {
this.setState(
{width: window.innerWidth},
window.addEventListener(
"resize",
({ target }) =>
this.setState({width: target.innerWidth})
)
)
}
render() {
return this.props.children(this.state.width)
}
}
```
Many developers favor [Higher Order Components](#higher-order-component) for this type of functionality. It's a matter of preference.
## Children pass-through
There are times you'll need to wrap a stateless function with lifecycle events.
While we want to wrap component functionality around other components, we don't want to introduce extraneous DOM nodes.
In some apps, this might brake styling.
We use the function `React.Children.only`.
`only` allows us to return `this.props.children` __if__ there is only one child.
Otherwise, it throws an error.
```js
class SomeLifeCycleWrapper extends React.Component {
componentDidMount() {
console.log("I mounted but have no DOM.")
}
render() {
return React.Children.only(this.props.children)
}
}
```
In cases where you're working with `state` or `context`, prefer [higher-order components](#higher-order-component) or [render callbacks](#render-callback).
## Proxy component
*(I'm not sure if this name makes sense)*
Buttons are everywhere in web apps. And every one of them must have the `type` attribute set to "button".
```js
```
Writing this attribute hundreds of times is error prone. We can write a higher level component to proxy `props` to a lower-level `button` component.
```js
const Button = props =>
```
We can use `Button` in place of `button` and ensure that the `type` attribute is consistently applied everywhere.
```js
//
Send Money
// Send Money
```
## Style component
This is a [Proxy component](#proxy-component) applied to the practices of style.
Say we have a button. It uses classes to be styled as a "primary" button.
```js
```
We can generate this output using a couple single-purpose components.
```js
import classnames from 'classnames'
const PrimaryBtn = props =>
const Btn = ({ className, primary, ...props }) =>
```
It can help to visualize this.
```js
PrimaryBtn()
↳ Btn({primary: true})
↳ Button({className: "btn btn-primary"}, type: "button"})
↳ ''
```
Using these components, all of these result in the same output.
```js
```
This can be a huge boon to style maintenance. It isolates all concerns of style to a single component.
## Event switch
When writing event handlers it's common to adopt the `handle{eventName}` naming convention.
```js
handleClick(e) { /* do something */ }
```
For components that handle several event types, these function names can be repetitive. The names themselves might not provide much value, as they simply proxy to other actions/functions.
```js
handleClick() { require("./actions/doStuff")(/* action stuff */) }
handleMouseEnter() { this.setState({ hovered: true }) }
handleMouseLeave() { this.setState({ hovered: false }) }
```
Consider writing a single event handler for your component and switching on `event.type`.
```js
handleEvent({type}) {
switch(type) {
case "click":
return require("./actions/doStuff")(/* action dates */)
case "mouseenter":
return this.setState({ hovered: true })
case "mouseleave":
return this.setState({ hovered: false })
default:
return console.warn(`No case for event type "${type}"`)
}
}
```
Alternatively, for simple components, you can call imported actions/functions directly from components, using arrow functions.
```js
```
Don't fret about performance optimizations until you have problems. Seriously don't.
## Layout component
Layout components result in some form of static DOM element. It might not need to update frequently, if ever.
Consider a component that renders two `children` side-by-side.
```js
}
rightSide={}
/>
```
We can aggressively optimize this component.
While `HorizontalSplit` will be `parent` to both components, it will never be their `owner`. We can tell it to update never, without interrupting the lifecycle of the components inside.
```js
class HorizontalSplit extends React.Component {
shouldComponentUpdate() {
return false
}
render() {
}
}
```
## Container component
"A container does data fetching and then renders its corresponding sub-component. That’s it."—[Jason Bonta](https://twitter.com/jasonbonta)
Given this reusable `CommentList` component.
```js
const CommentList = ({ comments }) =>
- {comment.body}-{comment.author}
{comments.map(comment =>
)}
```
We can create a new component responsible for fetching data and rendering the stateless `CommentList` component.
```js
class CommentListContainer extends React.Component {
constructor() {
super()
this.state = { comments: [] }
}
componentDidMount() {
$.ajax({
url: "/my-comments.json",
dataType: 'json',
success: comments =>
this.setState({comments: comments});
})
}
render() {
return
}
}
```
We can write different containers for different application contexts.
## Higher-order component
A [higher-order function](https://en.wikipedia.org/wiki/Higher-order_function) is a function that takes and/or returns a function. It's not more complicated than that. So, what's a higher-order component?
If you're already using [container components](#container-component), these are just generic containers, wrapped up in a function.
Let's start with our stateless `Greeting` component.
```js
const Greeting = ({ name }) => {
if (!name) { return
return
}
```
If it gets `props.name`, it's gonna render that data. Otherwise it'll say that it's "Connecting...". Now for the the higher-order bit.
```js
const Connect = ComposedComponent =>
class extends React.Component {
constructor() {
super()
this.state = { name: "" }
}
componentDidMount() {
// this would fetch or connect to a store
this.setState({ name: "Michael" })
}
render() {
return (
)
}
}
```
This is just a function that returns component that renders the component we passed as an argument.
Last step, we need to wrap our our `Greeting` component in `Connect`.
```js
const ConnectedMyComponent = Connect(Greeting)
```
This is a powerful pattern for providing fetching and providing data to any number of [stateless function components](#stateless-function).
## State hoisting
[Stateless functions](#stateless-function) don't hold state (as the name implies).
Events are changes in state.
Their data needs to be passed to stateful [container components](#container-component) parents.
This is called "state hoisting".
It's accomplished by passing a callback from a container component to a child component.
```js
class NameContainer extends React.Component {
render() {
return alert(newName)} />
}
}
const Name = ({ onChange }) =>
onChange(e.target.value)} />
```
`Name` receives an `onChange` callback from `NameContainer` and calls on events.
The `alert` above makes for a terse demo but it's not changing state.
Let's change the internal state of `NameContainer`.
```js
class NameContainer extends React.Component {
constructor() {
super()
this.state = {name: ""}
}
render() {
return this.setState({name: newName})} />
}
}
```
The state is _hoisted_ to the container, by the provided callback, where it's used to update local state.
This sets a nice clear boundary and maximizes the re-usability of stateless function.
This pattern isn't limited to stateless functions.
Because stateless function don't have lifecycle events,
you'll use this pattern with component classes as well.
*[Controlled input](#controlled-input) is an important pattern to know for use with state hoisting*
*(It's best to process the event object on the stateful component)*
## Controlled input
It's hard to talk about controlled inputs in the abstract.
Let's start with an uncontrolled (normal) input and go from there.
```js
```
When you fiddle with this input in the browser, you see your changes.
This is normal.
A controlled input disallows the DOM mutations that make this possible.
You set the `value` of the input in component-land and it doesn't change in DOM-land.
```js
```
Obviously static inputs aren't very useful to your users.
So, we derive a `value` from state.
```js
class ControlledNameInput extends React.Component {
constructor() {
super()
this.state = {name: ""}
}
render() {
return
}
}
```
Then, changing the input is a matter of changing component state.
```js
return (
this.setState({ name: e.target.value })}
/>
)
```
This is a controlled input.
It only updates the DOM when state has changed in our component.
This is invaluable when creating consistent UIs.
*If you're using [stateless functions](#stateless-function) for form elements,
read about using [state hoisting](#state-hoisting) to move new state up the component tree.*