Stateless functions are a brilliant way to define highly reusable components.
They don’t hold state or refs; they’re just functions.
They get passed props and context.
They can define local variables, where a function block is used.
But you could get the same result by using other functions.
They can have defined defaultProps, propTypes and contextTypes.
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.
Use this to forward props to underlying components.
Now, I can expect FancyDiv to add the attributes it’s concerned with as well as those it’s not.
Keep in mind that order matters. If props.className is defined, it’ll clobber the className defined by FancyDiv
We can make FancyDivs className always “win” by placing it after the spread props ({...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.
Destructuring Arguments
Destructuring assignment is an ES2015 feature. It pairs nicely with props in Stateless Functions.
These examples are equivalent.
The rest parameter syntax (...) allows you to collect all the remaining properties in a new object.
In turn, this object can use JSX Spread Attributes to forward props to the composed component.
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.
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.
That’s equivalent to providing a literal array.
This pattern can be combined with destructuring, JSX Spread Attributes, and other components, for some serious terseness.
Function as children
Using a function as children isn’t inherently useful.
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. When applied, rendering logic can be kept in the owner component, instead of being delegated.
With this setup, we can use this width to make rendering decisions.
If we plan to use this condition a lot, we can define another components to encapsulate the reused logic.
Obviously a static Width component isn’t useful but one that watches the browser window is. Here’s a sample implementation.
Many developers favor Higher Order Components for this type of functionality. It’s a matter of preference.
Children pass-through
You might create a component designed to apply context and render its children.
You’re faced with a decision. Wrap children in an extraneous <div /> or return children directly. The first options gives you extra markup (which can break some stylesheets). The second will result in unhelpful errors.
It’s best to treat children as an opaque data type. React provides React.Children for dealing with children appropriately and opting back into helpful errors.
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”.
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.
We can use Button in place of button and ensure that the type attribute is consistently applied everywhere.
Style component
This is a Proxy component applied to the practices of style.
Say we have a button. It uses classes to be styled as a “primary” button.
We can generate this output using a couple single-purpose components.
It can help to visualize this.
Using these components, all of these result in the same output.
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.
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.
Consider writing a single event handler for your component and switching on event.type.
Alternatively, for simple components, you can call imported actions/functions directly from components, using arrow functions.
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.
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.
Container component
“A container does data fetching and then renders its corresponding sub-component. That’s it.”—Jason Bonta
Given this reusable CommentList component.
We can create a new component responsible for fetching data and rendering the stateless CommentList component.
We can write different containers for different application contexts.
Higher-order component
A 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, these are just generic containers, wrapped up in a function.
Let’s start with our stateless Greeting component.
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.
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.
This is a powerful pattern for providing fetching and providing data to any number of stateless function components.