m-fe/react-ts-webpack

In the introduction to Web Development/Micro front end and Big Front End, the author briefly describes the design concept of micro service and micro front end and the potential feasible scheme of micro front end. Microservice and microfront-end both hope to transform a single single application into multiple services or application aggregation that can be run, developed, deployed and maintained independently, so as to meet the demands of rapid business change and distributed multi-team parallel development. As Conway’s Law says, organizations that design systems produce designs and architectures equivalent to communication structures between organizations; Microservices and microfront-end are not only changes in technical architecture, but also changes in organizational and communication modes. The principles of microservices and microfront-end are similar to those of software engineering and object-oriented design, Both follow basic principles of Single Responsibility, Separation of Concerns, Modularity and Divide & Conquer.

Fe-boilerplates is the author’s collection of front-end project templates, including different types of templates such as single-module single-page, single-module multi-page, (pseudo) multi-module single-page and micro-front-end projects. The difference between m-FE/React-TS-Webpack and the former is that each module in the micro-front-end can be independently developed, released, deployed and loaded. Distributed collaboration brings collaboration and development process challenges, and ease of use is an important consideration when designing a microfront-end project architecture. In the annual summary, I also discussed the significance of using TS for reconstruction-oriented programming. Please refer to the TS -* project in Backend-Boilerplates/node for full-stack development.

When we consider the project framework, templates, or scaffolding, the first thought of point is hope as far as possible to the upper block details, but for the long-term maintenance of large-size project with the people, if the project leader directly by using part of the abstract scaffolding, inevitably bring certain technology for future update, iterative liabilities; At the same time, there are a lot of mature engineering scaffolding, so the author chooses to abstract the part needed in the micro front-end in the form of project template. Follow the principle of simplicity and intuition as far as possible, reduce abstraction /Magic Function, etc.; Large projects may abstract away a dedicated development toolstream, but for most projects, a proper encapsulation of existing frameworks/toolchains is preferable.

# pull and extract subitems
git clonehttps://github.com/wxyyxc1992/fe-boilerplate cp fe-boilerplate/micro-frontend/react-ts-webpack .. /Add global dependency update tools
$ yarn global add npm-check-updates

Install dependencies for each subproject, and link each subproject
$ npm run bootstrap && npm run build

Perform a precompile operation
$ npm run build

Run the Host APP in basic mode, and then start the Host APP as a standalone APP
$ cd packages/rtw-host-app & npm run dev:sa

Run the child application in standard mode
$ cd packages/rtw-mobx-app & npm run dev

Return to the root directory
$ cd. & npm startCopy the code

It is worth noting that the micro front end as a concept carries different considerations for different people, and its implementation method and landing path are also different from each other. If there is anything wrong, please advise.

Features

  • Non-app classes can be published separately, APP classes can be run separately, and published. The release version can contain ES, CJS, UMD, etc. The DIST directory contains ES/CJS module, and the build directory contains the entire APP resources and UMD module.
  • Versioning: Sub-application resources do not use Hash, but use semantic versions./[cdnHost]/[projectName]/[subAppName]/[x.y.z]/index.{js,css}
  • Styles, LESS files support CSS Modules, CSS/SCSS uses standard CSS
  • State management, flexible support for Redux, MobX, Dva and other different state management framework, for Redux to provide a unified global Store declaration

Structure | project Structure

A complete microfront-end application may contain the following components:

  • Module | modules: modules can be compiled separately, distribution units, the basis of the fundamental mode can be directly packed into the application of standard mode when multiple projects share individually packaged as AMD/UMD, introduced by SystemJS
  • Page | Page: the Page cannot be compiled separately, using Webpack SplitChunk asynchronous loading or other mechanism
  • App | application: the application is for the expansion of the module, is the visible part of the actual user
  • Widget | controls: control is a special module, such as general no business components and so on
  • The Extension | Extension: Extension is a special application, provides a common functionality across modules, similar to Chrome Extension of positioning

Based on this, we can abstract a microfront-end application into different groups of modules as follows:

Basic modules:

  • RTW: Root directory, public directory contains some of the code for cross-module integration tests

Core modules:

  • Rtw-core/Rtw-SDK /rtw-shared: Exposes common base classes, model definitions, some independent modules without interfaces, etc. Rtw-core does not recommend interface correlation, use Jest UT mode for function verification.
  • Rtw-bootstrap: complete project-level build and boot entry, including the project runtime configuration, dependency configuration \ message bus, registry, core module loading mechanism, etc.
  • Rtw-host-app: provides interface basic container, such as the application of standard Layout, Menu and other components; Provides the Redux core Store.

Sub-business applications:

  • Rtw-mobx-app: Mobx sample application
  • Rtw-redux-app: Redux sample application

Expansion module:

  • Rtw-widgets: contains some business widgets that are used by all sub-applications, extract common business logic, and block some third-party dependencies, similar to the complete OSS file upload control.
  • Rtw-extensions: A generic Extension that contains some business-neutral extensions similar to Chrome Extension.
  • Rtw-worker: contains the common Web worker & WASM calculation module, and the child application can also directly introduce custom workers through Buffer

If you want to load an instance of child application B in child application A, you should get the instance object from A unified registry using A dependency inject-like approach. All base libraries shared by individual modules must be loaded globally in UMD mode; Rtw-host-app which modules need to be shown for declaration and use, and RTW-bootstrap which UMD submodules are registered to be provided.

Development mode

I have always advocated progressive engineering architecture, so this template can be started directly from base mode for projects with low complexity requirements, not much different from other TS projects.

Basic mode

The base mode is similar to (pseudo) multi-module single-page, with a single Host APP as the entry point to compile and run, and other packages (such as RTW-core) packaged directly into the main package, without SystemJS for independent loading.

rtw-core

Rtw-core and similar libraries carry common structure definitions, tool classes, etc. Running NPM run build command in this package directory can generate ES/CJS/UMD and other types of files, as well as types type definition. You can publish directly to public/private NPM repositories via NPM publish.

Other packages are installed and used via NPM. If running in standard mode, the library needs to be loaded into the global scope first and injected into other dependent libraries/applications using tools such as RequireJS/SystemJS in accordance with AMD specifications.

It is worth mentioning that for sub-applications, if there are scenarios where components/types need to be shared. For type information, it is recommended that sub-applications be compiled, packaged and published to the NPM repository as well. Pure components can be imported directly. For business components, it is recommended to obtain them from the global registry.

rtw-host-app

In the rtw-host-app package, run the NPM run dev:sa command to start the application from the SRC /index.sa file. As mentioned above, this mode only carries out asynchronous loading based on Webpack Splitted Chunk, and its development process is not different from standard single-module application.

The standard model

rtw-bootstrap & rtw-host-app

Rtw-bootstrap is the actual starting point of micro-front-end applications. Its core function is to perform registration of dependencies and subapplications. At startup, it will complete the sequential loading and startup of applications according to the variable information such as __HOST_APP__ and __DEV_APP__ passed in. In standard mode, the entry to rTW-host-app is a SRC /index file. In this mode, the index file exposes the render function, which is injected by RTW-bootstrap into the importApp function to perform child app loading:

export function render(_importApp: Function) { importApp = _importApp; ReactDOM.render( ... ) ; }Copy the code

In other words, RTW-bootstrap provides the ability to load applications, while RTW-host-app determines which applications should be loaded. In a practical case, we would place business operations such as user permission control, menu and sub-application information acquisition in RTW-host-app.

rtw-redux-app & rtw-mobx-app

Here, rTW-Mobx-app is taken as an example to introduce how to develop sub-applications. If the project has been published and put online, we can forward online Resource requests to the local server through online Resource request forwarding tools such as Resource Overrides. For local development, since the child application itself does not contain reactdom. render or similar functions to render the Virtual DOM into the interface, after running NPM run dev, Webpack Dev Server, which generates UMD files, is started locally. Refer to the child app’s public/index.html file:

<script src="./bootstrap/static.js" type="text/javascript"></script>
<script src="./bootstrap/runtime.js" type="text/javascript"></script>
<script src="./bootstrap/vendors.js" type="text/javascript"></script>

<script>
  // Check the environment
  // window.__HOST_APP__ = {
  // id: 'host',
  // name: 'HOST APP',
  / / module: 'http://0.0.0.0:8081/index.js',
  / / CSS: 'http://0.0.0.0:8081/index.css'
  / /};

  // The official development environment
  window.__HOST_APP__ = {
    title: 'HOST APP'.module: '/release/rtw-host-app/index.js'.css: '/release/rtw-host-app/index.css'
  };

  window.__DEV_APP__ = { id: 'dev'.name: 'DEV APP'.module: '/index.js' };
</script>
<script src="./bootstrap/index.js" type="text/javascript"></script>
Copy the code

It can be seen that the startup of sub-applications depends on RTW-bootstrap and RTW-host-app. If the project has been published and launched, it is recommended to load resources directly from CDN. Otherwise, you can place the resource in the public/release directory. If you need to debug the Host APP locally, you can run the Host APP in development mode (NPM run dev) and import the resource address generated by Webpack Dev Server directly.

read

  • If you want to practice master Web development, can read JavaScript CheatSheet/ProgrammingLanguage – Series/JavaScript, DOM CheatSheet/CSS CheatSheet, React CheatSheet/Vue CheatSheet, Modern Web Development foundation and Engineering Practice /Web Tuning CheatSheet, etc.