For those of you who have read the history of React-Router, you will know that React-Router did something important after v4. Refactoring code, instead of developing in config mode, manages the route in component mode.

Many people have launched their own react-router-config solutions after seeing this mode. The most widely used NPM library in the industry is react-router-config. And then Ali came up with more constraints than configuration. But these are the ideas of people with limited minds. Although I can’t speak for anything, I just want to mention that the use of react-route-config mode keeps the front end in the VUE phase, probably because vue comes from Config and everyone manages according to config, or for historical reasons of the project.

But I would say react should have been fully developed in v4. However, in recent years, I found that people still use umi.js framework when they use React, or use create-React-app instead of maintaining the scaffolding themselves.

The following is my personal opinion, as the majority of the copywriting solution is still stuck in react-router-config

What is modular development?

We now have a system, which has user module, mall module,CMS module and so on. As shown.

If we need to talk about this system to dismantle the development of the time, in theory is the following model. Load the module into our main reference module as a module and execute. But when we don’t need the code, we decouple the module directly from the entry file for complete decoupling.

However, because of the router.config.js configuration, it is very difficult to write this stipulation if you need to load it on demand. There will be some problems.

So if the main module needs to load something from the sub-module, you also need to bind your road force module.

But if you are using RouterV4 after component concept, simple, do what you said is surreal package, you can even do to project management for the enterprise management can achieve the security (code of whole developers can only get a small module development, you can say they can know what your business model?)

How to load a micro module

For now, call our module in the rc-modules file, but we can do node_modules directly. Because of the package mode, we don’t need to compile the node_modules files when we deploy the project, even if you type the files, it will be done before the NPM private library. All you need to do is install a new package (at deployment time), which in my opinion is faster than compiling.

I’m just going to give you a simple example.

For example, we now have an rc-modules/test-modeuls/ SRC/app.tsx module.

Define our submodule entry file.

test-modules/src/App.tsx
import React from 'react';
import { Route, Routes } from 'react-router-dom';

function TTT() {
    return (
        <div>
            Google
        </div>)}function App() {
    return (
        <Routes>
            <Route path="/" element={<TTT />} / ></Routes>)}export default App;
Copy the code

How to load into the main module

Returning to our main module SRC/app. TSX, we just need to add our module to the Router and set it to the Routers


  <Routes>
    ....
    <Route path="/test/*" element={<TestApp />} />
  </Routes>

Copy the code

At this point we just need to add /test in the browser

You can see the effect of our page.

So if you look at this, think about this diagram how do you manage your module?

Perhaps this is what React-router-V4 was originally intended to do, but it limited our thinking more than the DACHang model.

If I’m doing architecture, I need to manage the context of my entry module. I only need to worry about module loading and interface definition, how to implement it is the module’s business.

Currently a scaffold is being built to completely replace Umi.js, and the file compiled modules are compiled concurrently using Golang.

The modules completed so far are

As for why context is required, the store and core functions of submodules must require context to ensure uniqueness.