Easy to maintain front-end development architectureCopy the code

RDE was born in the context that we found the following problems with front-end engineering:

  • The development and maintenance of the project are managed by the project as a unit, and each project is developing the infrastructure repeatedly

  • Scaffolding is only responsible for initial engineering, can only be maintained at the time of creation, subsequent maintenance depends on the business developers themselves repeated maintenance

If there are a lot of projects in the business, it will cause problems such as waste of manpower and low efficiency in promoting transformation. By reconstructing the front-end engineering structure, RDE provides a set of maintainable scaffolding solutions to achieve the separation of business and engineering infrastructure, sustainable upgrade and maintenance of infrastructure, and further improve the development experience of business developers.

Problem solved

  • When developing a business, you have to navigate from a bunch of irrelevant (configuration) files to a page file, and the overall project feels chaotic

  • Each project repeats infrastructure and configuration, such as Webpack base configuration, dotting, Sentry, mock build, etc

  • Each upgrade dependency, such as Webpack, Vue, optimized packaging, etc., is required to push each project upgrade, which is inefficient

  • It is difficult to synchronize the dependency specifications of multiple projects, such as unified use of EcHART, unified form verification library, etc

  • It is difficult to synchronize development specifications for multiple projects, such as norm terms, Lint, serve, etc., or directory structure specifications; Cross-engineering development costs can be reduced

  • It is difficult to maintain engineering documents. Although a README can be placed in each project, it is not good for newcomers to get started, and README is easy to fail due to timely maintenance

Implementation scheme

The original engineering structure is divided into three parts according to functions:

  • Engineering infrastructure: packaging, development, mock, Lint, preCOMMIT validation, commit-MSG validation, Lint rule making, base dependency packages, etc

  • Component, util, directive, mixin, decorator, filter, style, request, etc.

  • Business application: engineering of business production

RDE acts as a link between the pieces, providing solutions that make the development of all three pieces easier; The whole idea is very simple. The project is divided into an app directory and a template directory. The app directory is for business, the Template directory is for infrastructure, the app directory is for business Git project, and the template directory is published in docker Hub container. Local runtime, aggregate the two in docker and run;



Core functions – CASE model

RDC Container: an engineering infrastructure image that is encapsulated and maintained by users and published on DockerHub. C stands for Container

RDA Application: Business engineering Application, A stands for Application

RDS suite: In business development, components are not the only common components. Therefore, the concept of suite includes common components, methods, directives, mixins, decorators, etc

RDE tool: a connector for the entire solution, providing the ability to create projects, develop runs, publish, and generate IDE configurations

Reviewing the front-end development process, RDE can be used as a more general standard scheme for integrating, summarizing and combining all services, so that the granularity of development and maintenance engineering is no longer engineering, but can be combined and reused according to their actual needs. The diagram below:



Best practices

RDE breaks the original business structure of maintaining a single project, but how to reorganize projects, split several RDCS, and how to position RDCS need to be decided according to their own business discussions. It is not recommended to directly use external RDCS. Each team (or department) should maintain its own RDC. Even an individual, assuming you develop multiple projects, can maintain one RDC for subsequent maintenance; Currently, RDC can be used in but not limited to the following scenarios:

  • As the underlying infrastructure of business projects

  • As the underlying infrastructure of component library and suite library, it can contain basic functions such as publishing and testing, which is convenient for the upper layer to develop and publish component library quickly

  • You can encapsulate common configuration or logical parts as a Node side

RDC maintainers need to cooperate with the RENDER configuration provided by RDE to create a broader coverage of the underlying infrastructure, need to abandon the single-project development thinking, combined with the upper level of various scenarios should be used for development and maintenance; Here are some of the issues that might be considered in the development of a business-level RDC:

  • Whether to encapsulate the background common menu

  • If the menu is multiple, can the APP layer choose it

  • Whether common scenarios such as login, error pages, and no permission pages need to be encapsulated in RDC

  • Whether to specify routing specifications to save the trouble of configuring routes

  • Make team Lint rules

  • Whether basic functions such as mock and proxy are included

  • If commands such as publish and deploy are involved, whether these operations are encapsulated

  • If single test is required, check whether the RDC provides the installation and configuration of the corresponding package

  • Some of the most basic and versatile packages are whether to install, such as Echart/Momentjs/Vue etc

  • If TS is used, is the definition of some of the most basic D.ts files provided

  • If there is a style specification, does it provide the most basic style and corresponding style methods, mixins, etc., such as BEM methods, common methods, etc

  • Whether a Webpack Alias configuration is provided to facilitate application development

  • Which parts of the RDC should support application extensions, and how should the extension rules be formulated

  • Is there good documentation available for developers to use

  • Ecological selection, version upgrade maintenance, such as future Webpack upgrade, VUE/React upgrade, etc

  • Packaging performance optimization

Overhand experience

Installation dependent Environment

  • Node

  • Docker

$ docker pull node
Copy the code

Install the RDE

$ npm i -g rde

$ yarn global add rde // if using yarn
Copy the code

Create a project

$ rde create
Copy the code

  • Enter the name of the project to be created

  • Select the create type as Application

  • Select the framework for the project to be created

  • For the sake of experience, choose the default container and container version

Began to explore

After creating the project, you can start exploring. After switching to the project directory, you will find that:

file type instructions Ides shows GITIGNORE Sync cover RDA attention
app directory Initial directory of business code         ●       –         –          ●
template directory Configuration files and other files copied from the image for local development          –         ●         ●           –
rda.config.js file RDA configuration file         ●        –          –          ●
.git directory The PreCOMMIT hook and commit-msg checksum are generated          –       ● only hooks          –
gitignore file The file that contains the initial rules         ●        –          –         ●
.vscode/.idea directory Editor initial configuration file          –       ●         ●          –
.devcontainer directory Configuration provided to vs Code-Insiders experience         –       ●         ●          –
node_modules directory Node_modules installed according to container requirements        ●       ●          –          –
README.md file Automatically generated readme        ●        –          –          ●

Only app directory and rda.config.js are concerned here. Other files are copied from the image for local development and have been added to gitignore, which cannot be modified.

  • IDE display: whether this directory is displayed when developing in vscode or webstorm

  • GITIGNORE: Default rule already added to GITIGNORE

  • Sync overwrite: Files that will be overwritten when rde sync is executed

  • RDA concerns: Files that need attention to develop business applications

Next, execute:

$ rde clean
Copy the code

Will delete all files except the application needs to focus on the directory; If you want to restore, you can do it again

$ rde sync
Copy the code

After restoring all files, sync can be used every time a container is upgraded or some files are deleted by mistake.

If you open the project with VScode or webstorm, you can only see app, rda.config.js and other files by default, because RDE has already generated the initial configuration for you and hidden the files that do not need to be concerned. Also, if you are using VSCode-INSIDERS or the latest VERSION of VSCode (and have remote installed), you can start development using Rde Clean by opening the Container. Since VS Code-INSIDERS is not a stable version, it is only used as a test experience and is not recommended.


Please refer to the documentation and Github repository for more details