Considerations for writing React Components — Part 01: Introduction
Table of contents
- Part 01: Introduction (this article)
- Part 02: Function vs. Class components
Components are the fundamental building blocks of React (and many other modern frontends frameworks and libraries).
They enable us to write reusable and composable elements for declaratively building the UI of our applications.
From the official React docs:
Components let you split the UI into independent, reusable pieces, and think about each piece in isolation.
Conceptually, components are like JavaScript functions. They accept arbitrary inputs (called “props”) and return React elements describing what should appear on the screen.
The most basic components there are would be those that render static content:
const StaticText = () => "static text"const StaticHeading = () => <h1>A static heading</h1>
While it’s great that components can be written in such a terse way, solely rendering static content isn’t something we need React for — this could easily be achieved with any templating language. It’s when applications become highly dynamic and interactive that React really starts to shine and components react to changes in the application’s state and efficiently update the UI accordingly.
The React library provides us with great flexibility in the way we write and compose these components. This flexibility can be overwhelming indeed, especially if you’re used to frameworks like Angular which are more opinionated and provide more overall structure for your application.
In software development there are almost always multiple ways to implement a certain feature — some are indisputably better than others, some are a matter of preference. But in many cases it depends — requiring us to take into account many different aspects and consider trade-offs in order to find the “best” (often the least bad) solution to a problem.
Given the aforementioned flexibility, this is no different when it comes to writing React components. React provides us with many tools to build our applications. We need to know which tools there are and, more importantly, how they compare to each other if we want to make informed decisions about when to use which for building our applications without falling victim to Maslow’s hammer.
This is what I hope to address in this series of articles. Its primary goal isn’t to provide best practices or my personal recommendations about how to write React components (although I will include those as well when deemed appropriate). Nor will it cover everything in-depth. It’s more about helping you become familiar with the terminology, common patterns and the multitude of ways for writing React components so you (or your team) can fully leverage the flexibility provided by the library to write functional, extensible and maintainable applications.
This series assumes a basic understanding of React, its core concepts and API, in particular JSX, props and state.
Without further ado let’s begin our journey in Part 02: Function vs. Class components.
Note: Rather than writing one very long piece, I’ve decided to make this a series of articles which makes both writing them way more manageable and (hopefully) their contents easier to digest for you.
This blog post is published by Comsysto Reply GmbH.
