React Application Architecture: Components [Part 1]

Have you ever tried to find out some useful and basic information about React application architecture? It’s as tricky as learning rocket science, really! I spent hundreds of hours Googling and the result was like “create src folder, components folder, middlewares, …”

The first thing you have to understand is that architecture is not only about folders and their location by use-cases. Moreover, it depends on the specificity of the project and what the team needs and you will face an issue while switching between different companies.

I want to give you some basic knowledge about React apps architecture: from a brief overview of the React library to code-splitting and architecture patterns.

So, this is the first part and today we’re going to dive deep into React and components.

What the heck is React?

It’s a JavaScript frontend library.
React is all about components. You need to think of everything as a component.
Built for both web and mobile platforms.

function Example() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
       </button>
    </div>
  );
}

Pros

Modular: easy to split code (e.g into chunks)
State-based: predictable behaviour
Independent: easy to testFast: improves application rendering performance
Flexible: can be used on both client and server
Simple: due to JSX code readability increases
Easy-going: not a big deal to integrate with other frameworks

Cons

It doesn’t provide an architecture pattern to follow
All teams have their own best practices
It’s easy to make the app overcomplicated
The future of React depends on... Facebook

Components

The coolest thing about React is the ability to create your own components. This can be done in any framework or without them; in modern web applications, components are the core.

Why we need them?

Having a component, we understand that we have an interface, we have some application-specific objects that we communicate with, some structures (like typescript, doesn’t matter) and we can display them in one place and solve specific use-case.

UI: common
App-specific: depends on DTO and app behaviour, but shared
Solve one case at one place

With components, we have 2 things: we can do everything in monorepo, when we store components close to our application and we can make a distributed application when the components are aside from our website (for example, we can create a local npm where each component will be in its own independent package).

Why distributed apps?

There can be more than one application using the same components. Imagine you are making 10 websites and they all should look similar and you need to share similar elements (components) between them — the UI kit is a good idea and, as a result, you will end up with it. But here you need versioning, you need a team that will support this, and it’s rather difficult to configure.

How about monorepo?

On the one hand, you can develop and distribute everything faster. On the other hand, you have a bunch of problems with shared components through the app, issues with naming and other interesting things.

Libraries

Splitting up large codebases into separate independently versioned packages is extremely useful for code sharing. However, making changes across many repositories is messy and difficult to track, and testing across repositories becomes complicated very quickly.

To solve these (and many other) problems, some projects will organize their codebases into multi-package repositories (sometimes called monorepos). Projects like Babel, React, Angular, Ember, Meteor, Jest, and many others develop all of their packages within a single repository.

Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.

Lerna can also reduce the time and space requirements for numerous copies of packages in development and build environments — normally a downside of dividing a project into many separate NPM packages. See the hoist documentation for details.

Anyway, UI Kits should have sandbox to play i.e. demo app, like opensource components have.

Storybook is a tool for UI development. It makes development faster and easier by isolating components. This allows you to work on one component at a time. You can develop entire UIs without needing to start up a complex dev stack, force certain data into your database, or navigate around your application.

If your company doesn’t have a single style guide and UI kit there are ready-made solutions like Ant.D.

Here we have a set of high-quality React components out of the box. You don’t have to spend hours developing your own solution and your teammates will be able to read perfectly written docs. Think twice before implementing your own library because such libraries as Ant.D or Material-UI have reusable and customizable components with polyfills and other ready-made staff.

How about charts?

Let’s say we have to deal with a bunch of documents and implement graphics or charts. Can you estimate how much time you need to spend and how much more to maintain all this?
Thanks God we have D3.js, it helps you bring data to life using HTML, SVG, and CSS. It’s quite complicated, with specific syntaxes and documentation.

Moreover, we have ECharts - is an open-sourced JavaScript graphing library for creating intuitive, interactive, and highly customizable charts and a npm-package for React.

Conclusion

Summing up, components are an essential part of a React application and architecture. They help us to build reusable and maintainable interfaces and it’s crucial to handle them in the right way.

In the next part, we will discuss code-splitting, frontend metrics, and migration from old to new.

I wish you the best of luck in learning JavaScript!