Every React.js application is composed of components. Let’s get started!
Stateless and stateful components
Stateless functions are a brilliant way to define highly reusable components. They don’t hold state, they are functions that take the input
props and return what to display.
We can define a
Button stateless React.js component as follows:
And now we can build a stateful React.js component. But why should we make our lives easier? Let’s use our stateless component to define this one!
Our first component renders a text and handles a click action via
props, however the second one’s constructor holds it’s
state. This separation of concerns may look simple, but makes
Button component highly reusable.
One thing is worth a mention again, you should define stateless React.js components as
functions and stateful ones as
Spread and deconstructing
Using React.js gives us an extraordinary ability to use all the riches brought by ES6. I would like to show you two, that are quite useful in terms of React.js components.
Above code which can be used as follows:
Will be rendered as:
The other handy syntactic sugar is a deconstruction operation. We can write:
but I recommend doing it better way:
Under the hood we create new object
props.name as its value.
We can now mix those two hacks to create new component:
That will render all
div attributes/props and
name as part of content.
Containers and “presentational” components
Working with external data, e.g. from APIs, you may find it easier to divide you components into two new categories – containers and presentational components. The first ones are responsible to reach data that is kept outside React.js (yes,
redux is outside). The second ones are concerned on how things look, depending only on their own states or, more often, props.
Let us consider a comment list with comments saved in
json file as our goal. The first component should be presentational, rendering only comments passed into it by
The second one, a container, will fetch data and render our presentational component.
Despite it’s a good pattern to use those two types of components, don’t take that separation as a dogma. Sometimes it doesn’t matter or it’s hard to draw the line. You can always refactor your code, so if you are unsure – don’t sweat it!
HOCs and render callbacks
Firstly, let’s modify our
Greeting component a little bit.
name is passed in props it should render it, otherwise it would render “Loading…” text.
Finally, we can build our higher-order part.
Higher-order components can be replaced with Render Callback Components also called Function as Child Components. Whether you use HOCs or RCCs to make your component’s logic reusable actually does not matter, and is only based on your favour.
Here I would present rather simple and useless example of RCC, but it will give you the idea.
Let’s create two stateless function components to begin with.
As a result we want to display a
div with either the
Worker components, based on whether the data is yet fetched. To get it working, we need to treat
this.props.children of our RCC as a function. Here comes the example:
“Give a man a fish vs. teach a man to fish…”
There are plenty of React.js Component patterns that I didn’t mention. There are also patterns that nobody heard about (yet?). I have chosen the ones that I find useful or interesting – here’s a fish for you, but it’s up to you, which you will learn and use in your projects – and there’s a first lesson of fishing.
I put all examples on GitHub and working, live version on StackBlitz.