Way back in the early modules of the course we looked at the relationship between components in React. No matter what the size, structure, and complexity of the React project you’re dealing with, when it comes to components there are broadly two roles that a component will have: they will either be a parent or a child.

Parent and child component relationships#

Most components are either a parent or a child and this isn’t a one to one relationship. Just like real life, parents can have parents, and children can themselves have children. The important thing to remember about this relationship is how we move information between them. It’s a core part of the React approach but one many beginners struggle with.

Here’s our earlier module’s diagram that highlights this information flow.

You can see that a parent component passes data or information down to a child via props, whilst a child component sends data and information back up to a parent via some sort of event.

For example, a parent component which deals with calling an API to retrieve a list of users might pass a loading flag, isLoading, a value for the total number of users found, totalUserCount, and a function nextPage() to a child component which deals with displaying some paging elements in a nicely formatted way. The child component has a styled set of page elements and a button for the user to click to move onto the next page.

The child component, in this case, is purely presentational, that is it contains minimal (or zero) logic or state and is more concerned with accepting a range of prop values and displaying them in some formatted way.

In this scenario, the parent component passes the data, our totalUserCount, nextPage() and isLoading down into the child component via the props object. In the child component, we’d access them via a call to props like this, props.totalUserCount or props.isLoading.

That’s fine, but what happens when the child component wants to change to the next page of results?

The logic involved in fetching new results and organizing the returned data is handled by the parent component not the child component because the child component is purely presentational.

At this point you might be thinking, ‘well couldn’t we just move the button that triggers the next page into the parent component?’. This is an option, but the button makes more sense in the context of the whole paging component. The parent component in this example is possibly doing several other things and contains several other related presentational components such as a data table and a search bar.

So what’s the solution? Well, we leave the button where it is, in the presentational child component, but attach the props.nextPage() function that we passed down from the parent to the button’s onClick event.

What happens now is that when the user clicks the next page button, the button’s onClick event is triggered, this calls whatever function is attached to this event, which in our case is the passed in nextPage() function. The nextPage() function will be called and since it lives in the parent component, it’ll be handled there. The parent component will likely fetch more results from the API and then pass these new results down to the child competent, which will re-render and complete React’s component lifecycle once more.

This is a fairly simple, yet common, example of data flow around your app and between components. Things can get complicated and a little ugly if you have many layers of children and you need to get data from a parent component higher in the chain to a much lower child component. This practice is called prop drilling and involves each child component in the chain having to grab a prop from its parent and pass it down to the next child.

In a later module, we’ll be looking at more complex data and state management using the useReducer Hook and the Redux state management pattern. These concepts can avoid scenarios like prop drilling and reduce the dependency of unrelated components on each other for the sake of passing props down the line.

Component types in the wild#

Just about anything that you come across in a React project that returns some JSX can be thought of as a component. However, not all components are created equal. There are several different component types that you may come across when building projects as part of your job, contributing to open source projects or reading about in blog articles.

Let’s take a look through some of the more common ones to see what they are used for, what they look like, and how you can identify them.

Keep in mind that because React is both very unopinionated and is based on JavaScript, which is itself a very loosely typed language, there can be a lot of overlap between styles of components. For example, a class-based component can also be a presentational component. The naming convention of a style or type of component can be a mixture of its role, its output or how it’s constructed. Nothing’s set in stone, but it can help to order your project and the building blocks that components represent.

Class-based components#

A class-based component is really any component based on an ES6 class. They typically look like this, extending React’s Component class:

class MyClassComponent extends React.Component {

	state = {

		name: '',

		age: 0,

	};

	constructor(props) {

		super(props);

		// handle incoming props

		this.state.name = `${props.firstName} ${props.lastName}`;

	}

	render() {

		return(

			<p>Hi, {this.state.name}, you are {this.state.age} years old!</p>

		);

	}

}

You might remember the look of this style of component construction from our earlier modules where we built out some class-based components and refactored them.

This component will accept some props such as firstName and lastName, does some string manipulation to turn it into a single name property in state and renders a paragraph element pulling in the name and age values from state.