Frontend on Time Friend

Recommended Order for Developing Taro Multi-Platform Applications

Wed, 16 Dec 2020 22:17:36 +0000

Developing Taro Multi-Platform Applications with Minimal Cost

All mini-programs, quick apps, React Native apps, etc. in our company are now being developed using Taro.

If you only need to support one platform, developing with Taro is no problem at all.

However, if you want to develop once and have it run normally on all platforms, you need to pay attention to many details.

Each platform has its own challenges.

Development Difficulty Ranking

Huawei Quick App > Quick App > React Native > Swan Mini-Program > WeChat Mini-Program > H5

How to Optimize Bundle Size for Quick Apps Developed with Taro

Tue, 15 Dec 2020 22:17:36 +0000

Quick App Duplicate Bundling Issue

When developing quick apps with Taro, there’s one issue that absolutely cannot be ignored: bundle size.

Due to the bundling characteristics of quick apps (below version 1080), if a third-party library is repeatedly used across multiple pages, that library’s code will be bundled into each page, causing the same code to exist in multiple pages.

Because quick app version 1080 is not yet widely deployed. If you rashly upgrade your quick app’s minimum platform version to 1080, you will lose a large number of users on lower versions.

Making Taro UI Support React Native

Thu, 27 Aug 2020 22:17:36 +0000

The Dilemma of Taro UI Not Supporting RN

Taro UI documentation mentioned early on that it might support RN, but it’s been over a year, and due to manpower issues in the Taro UI team, it hasn’t been compatible with RN yet.

Business is urgent, we can’t wait for that day. Do it yourself and you’ll have everything you need.

Problems with Traditional Taro Component Packaging on RN

Generally, after a component library is packaged, the dist/index.js file will look like this.

Taro Cross-Platform Development - Multi-Business Module Management React Native (Final)

Tue, 25 Aug 2020 22:17:36 +0000

React Native Hot Update Solution

RN business is becoming increasingly large, and more teams are collaborating. RN’s dynamic capabilities must be put on the agenda. For RN hot updates, the first problem is code splitting.

RN’s base library is very large, plus we depend on many third-party libraries. This code must be separated during code splitting. Business packages should be relatively pure, containing only business code. This ensures business packages are smaller, ensuring speed during hot updates.

Taro Cross-Platform Development - Multi-Business Module Management React Native (Part 2)

Sun, 23 Aug 2020 22:17:36 +0000

Implement a Simple Module Management Tool to Solve the Problem of Slow npm Pulling of Business Modules

Using npm to pull git repositories, the speed is actually acceptable. The main slowness is during postinstall when npm pulls git repositories, it needs to rebuild project code. Another point is that business modules also have dependencies, and npm install also needs to pull the same dependencies again.

These two steps can actually be omitted. The solution is to implement a simple module management tool to replace npm’s handling of loading business modules.

Taro Cross-Platform Development - Multi-Business Module Management React Native (Part 1)

Fri, 21 Aug 2020 22:17:36 +0000

How Can Native RN Projects and Taro Coexist?

Our team started practicing native React Native projects early on, for a long time,

All business modules were developed and maintained in one project. Over time, this project became a behemoth.

Plus later we introduced RN projects based on Taro development. To ensure native and Taro RN coexistence,

Whether it’s native RN projects or Taro projects, the main export index file format in package.json files is consistent.

Taro Cross-Platform Development - Dependency Management Issues

Thu, 20 Aug 2020 22:17:36 +0000

Currently, the platforms we reach through Taro include:

WeChat Mini Program
QQ Mini Program
Baidu Mini Program
React Native
H5
Quick App

To quickly allow business to reach all platforms, each of our business modules is independent.

They are compatible with different platforms according to business needs, and then assembled into a complete project during build time.

To meet the above needs and enable flexible development, each business module can be independently developed and run, without depending on the main project.

Taro Cross-Platform Development - Thoughts and Measures on the New Era of Cross-Platform Development

Tue, 16 Jun 2020 22:17:36 +0000

New Era

The emergence of cross-platform frameworks has transitioned front-end browser compatibility to a new era of client platform compatibility.

For startups, this type of framework can quickly test and reduce human and time costs.

Why Choose Taro

It’s not that Taro solution is particularly excellent. At the current time point, all current cross-platform frameworks are still in the improvement stage. The most complete platforms might be mini programs and H5.

Micro-Frontend Advanced 4 - Cross-Framework Shared Components (Widgetization)

Sat, 22 Jun 2019 22:17:36 +0000

In micro-frontend, we can let sub-modules use different framework technology stacks according to our business needs. Although reaching this step is already very beautiful, is this the end of micro-frontend?

The answer is no, micro-frontend boundaries can be further broadened.

The previous micro-frontend article https://time-friend.com/archive/qh7x5i5szfh/ introduced how to call React components between sub-modules with the same technology stack.

What we’re talking about today is how sub-modules between different technology stacks call components from different technology stacks.

Micro-Frontend Advanced 3 - Cross-Module Shared Components

Sun, 12 May 2019 22:17:36 +0000

After front-end microservices, we face a problem: duplicate code between modules cannot be reused.

If we use npm to manage our duplicate code, we’ll have additional costs maintaining npm packages. Updating npm package versions in sub-modules is also very troublesome. There’s no optimization in js file size either.

Today let’s talk about how to use one component simultaneously in multiple modules.

Approach

Manage public components in base module, encapsulate components as dynamic components, so when packaging we can split this component into a separate file. When other sub-modules need this component, dynamically get it from Base module.

Micro-Frontend Advanced 2 - Local Development Guide

Mon, 22 Apr 2019 22:17:36 +0000

After building our microservices front-end application using single-spa, there’s actually a problem that will always trouble us, That is how to develop effectively? How to be as simple and easy to use as our usual front-end application development. Today using umi sub-module as an example, hoping to give everyone an idea

Today I’ll introduce one method, hoping it helps everyone.

Module Loader

Do you remember my previous module loader, https://time-friend.com/archive/1a60cede/

We just need to encapsulate the original module loader into an npm package.

Micro-Frontend Advanced 1 - Umi-Based Submodule Solution

Sat, 13 Apr 2019 22:17:36 +0000

It’s been more than half a year since the first article about front-end microservices. Many people are interested.

Today let’s talk about how we build a more complete front-end microservices sub-module based on umi.

If you’re using front-end technology stacks other than React, Many of my handling methods can also be applied to other technology stacks.

Hope it helps you too.

Excellent umi Framework

In front-end mid-backend projects, front-end microservices needs are relatively strong.

Single-SPA Micro Frontend Demo Collection

Wed, 31 Oct 2018 00:00:00 +0000

Here are the single-spa micro frontend demos that can be found on GitHub:

single-spa-examples

This is the official single-spa example. Here is the online demo.

simple-single-spa-webpack-example

This is a usage example built with webpack. The webpack version might be a bit old, but the concept is the same.

single-spa-angular-cli-examples

An Angular example based on angular-cli, suitable for Angular 2.0+ versions.

single-spa-es5-angularjs

An AngularJS example, i.e., AngularJS 1.x version.

single-spa-portal-example

This is already a very complete multi-tech-stack use case, integrating multiple tech stacks with inter-module communication ideas. Very worth studying.

Micro Frontend Solution 8 - Secondary Build

Fri, 07 Sep 2018 01:00:00 +0000

Secondary Build

Further optimize our micro frontend performance

In a micro frontend architecture, each module outputs fixed files, such as the previously mentioned:

Project config file
Store.js file
main.js render entry file

These three are the necessary files for each module in a micro frontend architecture.

When the module loader starts the entire project, it must load all modules’ config files and Store.js files. In a previous article, we discussed config automation, which is essentially a simple form of secondary build. Although each module’s config file is not very large, each file is loaded and is necessary for project startup. Each file takes one HTTP request, and each file’s blocking affects the project’s startup time.

Micro Frontend Solution 7 - Static Data Sharing

Thu, 06 Sep 2018 01:00:00 +0000

From the previous introductions, I believe you now have a relatively complete understanding of micro frontends. Below are some tips and handling methods I’ve developed during my work.

Dynamic Entry

When a new submodule is mounted to the project, a new entry point in the UI is needed to access the submodule’s UI. Such an entry point needs to be generated dynamically.

For example: the menu on the left side of the image should not be hardcoded. It should be automatically generated based on the data provided by each module.

Micro Frontend Solution 6 - Build & Deploy

Wed, 05 Sep 2018 01:00:00 +0000

Micro Frontend Build

There are some things to note when bundling micro frontend projects. Take webpack as an example:

AMD Modules

In previous articles, we mentioned that our loader is based on System.js. So the final bundle of our micro frontend modules must conform to module specifications. We use the AMD module specification to build our modules.

Specify Base Path

Since the module loader calls the module entry file after bundling, To clearly manage each module and correctly load all our module resources, we specify a publicPath for all module resources.

Micro Frontend Solution 5 - Route Distribution

Tue, 04 Sep 2018 01:00:00 +0000

Route-Distributed Micro Frontend

From Application Distributing Routes to Routes Distributing Applications

There is no better way to explain micro frontend routing than this sentence.

Route-distributed micro frontend distributes different business functions to different, independent front-end applications through routing. This can usually be achieved through reverse proxy on an HTTP server, or through the routing that comes with the application framework. Currently, route-distributed micro frontend architecture is probably the most adopted and easiest “micro frontend” solution. However, this approach looks more like a聚合 of multiple front-end applications, i.e., we just piece together these different front-end applications to make them look like a complete whole. But they are not — every time a user goes from App A to App B, they often need to refresh the page. — Quoted from phodal The Matters of Micro Frontends

Micro Frontend Solution 4 - Message Bus

Mon, 03 Sep 2018 01:00:00 +0000

The main function of the micro frontend message bus is to bridge communication between modules.

Black Box

Problem 1:

After applying microservices architecture, each individual module becomes a black box. What happens inside, what state changes, other modules have no way of knowing. For example, when Module A wants to perform an action based on a certain internal state of Module B, there is no way for black boxes to communicate. This is a major problem.

Micro Frontend Solution 3 - Module Loader

Mon, 03 Sep 2018 00:00:00 +0000

The micro frontend module loader handles three main responsibilities:

Loading project configuration files
Loading module API files (used by the message bus, covered later)
Loading module entry files

These are three essential parts for every module.

Configuration File

In our micro frontend practice, each module has an external configuration file used when registering with Single-SPA.

{
 "name": "name",
 "path": "/project",
 "prefix": "/module-prefix/",
 "main": "/module-prefix/main.js",
 "store": "/module-prefix/store.js",
 "base": true
 }

When a module supports multiple URL prefixes, the path can be an array:

Micro Frontend Solution 2 - Single-SPA

Sun, 02 Sep 2018 22:17:36 +0000

Technology Selection

After extensive research, we chose Single-SPA as the foundation for our frontend microservices solution.

Your browser does not support video.

Single-SPA

A JavaScript frontend solution for frontend microservices

With Single-SPA, you can:

Use multiple frameworks (React, Vue, AngularJS, Angular, Ember, etc.) on the same page without refreshing.
Write new code with modern frameworks without refactoring existing code.
Load each module on demand for better performance.
Run each independent module separately.

Demo: https://single-spa.surge.sh/

Micro Frontend Solution 1 - Thinking

Sat, 01 Sep 2018 22:17:36 +0000

In recent years, microservices architecture has become hugely popular in the backend development community, considered the future direction of IT software architecture. How can we apply the principles of backend microservices to build modern frontend applications? Here I provide a frontend microservices solution that can actually be implemented in production.

Comparison of Backend and Frontend Microservices

Advantages of Backend Microservices:

Controlled Complexity: Small size, low complexity. Each microservice can be fully managed by a small development team, making it easy to maintain high maintainability and development efficiency.
Independent Deployment: Since microservices run in separate processes, each can be deployed independently.
Flexible Technology Choices: In a microservices architecture, technology selection is decentralized. Each team can freely choose the most suitable tech stack based on their service needs and industry trends.
Fault Isolation: When a component fails, in a single-process traditional architecture, the fault is likely to spread within the process, causing global unavailability.
Scalability: Monolithic applications can also scale horizontally, but it requires replicating the entire application to different nodes.

Advantages of Frontend Microservices:

Controlled Complexity: Each UI business module is developed by an independent frontend team, preventing code bloat, maintaining fast compilation during development, and keeping complexity low for easy maintenance.
Independent Deployment: Each module can be deployed independently, down to a single component’s UI, without affecting other modules.
Flexible Technology Choices: The most attractive advantage — you can use any frontend tech stack available today, including future ones, within the same project.
Fault Isolation: A single module failure does not affect the entire application.
Scalability: Each service can be independently scaled horizontally to meet business needs without unnecessary resource consumption.

When Do We Need Frontend Microservices?

The project’s tech stack is outdated, developers with relevant skills are scarce, feature expansion is difficult, and refactoring or maintenance costs are high.
The project is too large, code compilation is slow, the development experience is poor, and a higher-level decoupling solution is needed.
A single tech stack cannot meet your business requirements.

Problems and Challenges

We will face the following issues: