Take you from scratch to build an enterprise-level React project

Take you from scratch to build an enterprise-level React project

"This article has been summoned to participate in activities of a good text, click to see: the back-end, front-end dual-track large contributors, 20,000 yuan prize pool waiting for you to challenge! "

This article is not just for React readers. In addition to the content of the React technology stack, other things are completely projects that can be applied to any technology stack.

Generally, a new project is developed in-house, scaffolding a shuttle and then it's done. As a result, some developers will lack some knowledge points, such as why we choose this technology stack for development; how to do the engineering configuration in the project, once you get started, you will be confused; what is a scaffolding? Readers think that scaffolding is a very powerful thing), how to build an enterprise-level scaffolding suitable for business development.

A React project will involve many common things, but there are many options. Single-person development can be integrated at will according to your own preferences, but in the scenario of multi-person development and multi-project, a set of specifications is bound to limit everyone. The article will talk to readers based on the following outline about how we structure an enterprise-level React project, and finally how to integrate this set of things into scaffolding.

Next assume that you are currently in a company that primarily uses React for development. A multi-person team and existing projects are online. With the development of the business and the increase in personnel, you urgently need to establish a complete, unified and standardized development process. The boss needs you to take full responsibility for this content and finally produce a scaffolding.

Technology stack selection

For a React project, the general technology stack must consider the following:

  • TS or JS?
  • Choose Hooks or non-Hooks or hybrid?
  • CSS solution, is it Saas preprocessing or CSS-In-JS, Atom CSS?
  • How to choose status management?
  • How to choose Route? In fact, this choice is very small

1. before considering the pros and cons of a certain technology, we first need to analyze the team situation.

For example, we now need to consider whether to choose TS or JS, then we should first consider whether most of the team members have already understood or developed TS projects. If most of the members are in a state of unskilled and resisted TS, then being strong on TS will inevitably lead to a decrease in development efficiency.

any
Fly everywhere. Of course, if the Leader can withstand a short-term efficiency reduction, then the TS solution can be placed on the option, otherwise the option may need to be a little behind, or only slowly started to be promoted in some projects.

Next, I will take the above-mentioned technology stack as an example to illustrate from which angles we need to consider the problem when selecting a model.

Choose Hooks or non-Hooks or hybrid?

The hands-on costs in the following table are based on the premise that team members have already used class components to write React projects.

HooksNon-Hooksmixing
Cost of getting startedhighnohigh
Function reusabilityhighlowin
Code readabilityhighlowin
Common pitfalls of eachClosure trap, incomplete life cycle of contrast componentsJS Class flawsBoth have
Old project migration costhighnoin

The choice of Hooks has actually started to talk about the article a few years ago, so I won t be arrogant here to talk about their respective advantages and disadvantages. The above table only lists some common comparisons.

This section is mainly to give you an idea, when we encounter model selection, which directions should we consider.

CSS scheme

CSS-In-JSAtom CSSPretreatment
Cost of getting startedhighinalmost none
Style coverage costHigh, the style that needs to be exposed to an external class or a single nodenono
Code readabilityhighalmost nonehigh
Support postcssDon't support, you have to use your ownstand bystand by
SSR supportThe server side requires additional codestand bystand by

Regarding the choice of CSS schemes, the author wrote an article as early as the beginning of the year . If you are interested, you can read it yourself. The following words let me briefly talk about these schemes.

CSS-In-JS

The author has been using this solution for two years, specifically using the styled-components library (hereinafter referred to as sc). In general, I feel that this solution is very fragrant for React, and it solves some of the traditional CSS writing points that I hate, such as writing a bunch of classes, which is really difficult to name.

Through this library, we need to use JS to manage CSS, so we can fully enjoy the tool chain benefits brought by JS. Once unused style components appear in the project, ESLint can help us find those dead codes and remove them. This function can still reduce a part of the code volume for large projects.

In addition, the problems of style pollution, naming problems, and automatic prefixes are also solved very well. In addition to the above, let's talk about two things that are not easy to notice.

The first is to switch themes dynamically. Because we are writing CSS through JS, then we can dynamically control the style. If your project has a large number of dynamic CSS needs such as switching themes, then this solution will be a good choice.

Another point is to load on demand. Because we write CSS through JS, at this stage, we basically package the code split, then we can load CSS files on demand instead of loading them all at once in the traditional way (of course it can also be optimized, but not so Convenience).

Let's talk about the shortcomings after finishing talking first. The cost of learning definitely exists. There is nothing to say about this. In addition, there are runtime costs. The file size of sc itself, and the need to dynamically generate CSS, then there must be a performance loss. The larger the project, the greater the impact. If your project has high performance requirements, you need to carefully consider using it. In addition, because CSS is dynamically generated, CSS files cannot be cached like traditional CSS. In addition, the style coverage cost is slightly higher than other solutions, and postcss is not supported, and there are additional development costs for SSR solutions.

Atom CSS

The code readability is poor and the learning cost is not low. However, under the existence of mature UI specifications, this solution can provide common styles for reuse, thereby reducing the size of CSS files.

In fact, the author is not optimistic about the large-scale application of this program in domestic business teams, because UI changes caused by frequent changes in requirements and most UI teams do not have a mature specification. These problems will significantly increase the cost of using Atom CSS.

Pretreatment plan

It should be regarded as a traditional solution. It has everything that should be available, and the development cost is low. It is nothing more than a common problem with CSS: debugging is really painful.

summary

In general, using CSS-In-JS needs to consider the cost of learning and the acceptance of team members. After all, there are indeed some developers who do not like this way of writing CSS.

Atom CSS must have a set of mature UI specifications, otherwise the UI will be changed frequently as the needs change. Believe me, it will definitely be a crematorium.

There is nothing to say about the preprocessing scheme, almost no cost to get started, and the code is easy to maintain. If team members don t like CSS-In-JS and don t have a mature UI specification, choose this one.

How to choose status management?

There are really too many options for state management. In addition to the familiar Redux and mobx, there are a lot of other competing products, such as:

When we select the status management, in fact, the first step should be to consider whether the project needs status management. In fact, most projects only need cross-component communication, not management. In other words, when you are actually considering whether the project needs state management, it is basically not needed at this time. Because you may not have encountered the pain points solved by state management at all, but just feel that cross-component communication is troublesome.

If your project has not yet risen to the need for state management, you can consider choosing a state shared library (similar to hox ) plus hooks. In fact, this solution can basically cover most projects, and the state-related code written is also It's not easy to shit.

If the project really needs state management, try not to think about technology-related things, but choose a familiar thing to use directly . Because state management is too easy to write about Shit Mountain, we Barabara compared a bunch of technology-related things. In the end, if we choose a relatively advanced product that everyone is not familiar with, Shit Mountain should be unavoidable.

How to choose Route?

In the routing area, I personally think that there is nothing to choose. After all, there is basically no room to choose. Whichever option you choose has no effect on development, so choose what you choose.

other

In addition to the technical selection mentioned above, we may also have more technical requirements depending on the project, such as single test and so on.

Single test

The business team does not write a lot of single tests, especially UI-related. But we can take the second place and place orders for tool functions or some key nodes to improve the overall code quality.

For tool function testing, just go to Jest or Mocha directly. Anyway, it's a matter of assertion. If you want to test UI-related, then enzyme and react-testing-library are also essential. Finally, if you still want to automate the entire test, then go to cypress .

In addition, the author has written a single test article before , and interested readers can read it by themselves.

summary

In fact, when selecting technology, technology-related content is probably the last consideration. Before that, we need to balance the team, project duration, project appeals and other external factors.

Finally, for the selection of each technology stack, you can browse the warehouse created by Yunqian , which should be considered as a comprehensive coverage.

Engineering configuration

The engineering configuration in the project is a very important part. This part of the content should be configured as little as possible for the developer, and it should be used out of the box in common scenarios, and a part of the configuration should be strongly controlled .

The author talked to some front-end developers in small companies and learned that their development is actually quite messy. For example:

  • Engineering configuration is different for each project, which is specifically reflected in the problems of Webpack configuration confusion, ESLint in name, and code format confusion.
  • There is no specification for commit submission, no code review
  • and many more. . .

If the above kind of problems happen to happen to your team who is reading the article, you may be able to try to improve according to the author's ideas below.

For a project, the following should be necessary:

  1. Builder configuration, generally Webpack in the application
  2. Babel configuration
  3. TS configuration
  4. ESLint configuration
  5. Prettier configuration

Regarding the above content, I personally think that in addition to the second and third points, the other items require strong control.

For Webpack, everyone knows that it is troublesome to configure, but a considerable part of the configuration should be common in each application. We can extract this part of the general configuration and make an internal preset, just like @babel/preset-env . This approach simplifies the content that needs to be configured, thereby preventing users from messing around and causing confusion in each project Webpack. At the same time, when upgrading Webpack in the future, users do not need to pay attention to the modification of the general configuration, only need to adapt their new configuration.

So for ESLint and Prettier, strong control is a must, encapsulate the configuration and let the user directly

require
That's it. In this way, the situation where ESLint is closed for another project and the encoding format is completely changed. This kind of problem is actually a devastating blow to the code quality. Everyone will break the jar and write the code.

In general, for engineering configuration, we'd better let users touch the configuration as little as possible, and concentrate on the business code. Places that can be controlled must be strongly controlled, which will improve the code quality of the entire team. Of course, we definitely can't control all configurations. In some places, we still need to open a hole for users to customize/merge configuration items, such as Webpack.

Directory Structure

A good project directory can improve the maintainability of the project, otherwise the code is unorganized and messy, and you may write it well, but it is really a big deal for the colleagues who take over.

The author roughly divides a project directory into the following sections:

  • pages, pages, where each folder is divided according to functional modules
  • components, components, divided into common and business components
  • services, where you interact with the backend
  • store, state management logic related, if needed
  • utils, constants, utility functions, etc.
  • types, TS project needs, storage type
  • assets, static resources, such as pictures and svg
  • tests, test related, if needed

According to the above classification, our general catalog of a project will grow into this:

/src /pages /components /services /store /utils /types /assets /tests index.ts App.ts Copy code

In addition to the above content, the corresponding files will be different according to our different CSS selections and engineering choices.

Integrated into scaffolding

Scaffolding is simply to help us

git clone
After an initial project, a basic scaffolding can be roughly divided into two parts:

The engineering configuration and template code have already been talked about above. You can make such a set of things according to your own business, but these alone are not enough to make a useful scaffolding.

For example, what if some businesses need to do single test? Do you need to do a lot of configuration by the business side?

For example, depending on the business, there may be subtle differences in the templates. At this time, do we create a new set of templates or what should we do?

Therefore, for scaffolding, we need to add some optional content on top of the necessary engineering configuration. For example, if the business side thinks that the project needs single test, then select the single test when initializing the project to automatically add the configuration required for the single test.

Then because of different businesses, there may be differences in the template code. At this time, we can decide whether to split a set of templates or support compilation on the original templates according to the situation, so as to determine the final template output according to the user's input.

After doing the above things, we may barely make a scaffold that is easy to use and suitable for our team's business.

At last

There is no code in the article, but I mainly share from the author s point of view how to design a React project from scratch, what is the technology stack selection, how to make the engineering easy to use, and the project directory structure. What it looks like, and finally talked about how to make a useful scaffolding.

Author: yck

Warehouse: Github

Public number: The front end is really fun

Special statement: originality is not easy, no reprinting or plagiarism is allowed without authorization, if you need to reprint, please contact the author for authorization