Micro Applications#

Micro applications are a solution for breaking down large projects into multiple independent smaller applications. Each application can be independently deployed, debugged, and quickly integrated into a larger user-facing application. They also support resource sharing between micro applications, making them suitable for multi-team collaborative development. The micro application capability is enabled by default in wis without requiring additional configuration.

Principle#

The micro application technology is currently built on the mature community solution Module Federation. We have made some simplifications and encapsulations based on this, enhancing the convenience of resource sharing and micro application integration. We have also extended core capabilities such as cross-platform and resource sets, making it more aligned with the design philosophy of wis.

Registering Applications#

For micro applications to share resources with each other, including page resources, script resources, component resources, cross-platform resources, etc., they need to be registered first. Each application can be a producer, a consumer, or both simultaneously.

For example, if we want to use the wis component library in our application, we only need to add the following configuration to the wis.config.ts configuration file:

import type { WisConfig } from "@wisdesign/wis-plugin"
 
export default const config: WisConfig = {
  remotes: {
    wis: "https://static.wis.design",
  },
}

Application Types#

Micro applications themselves do not have type distinctions. Each micro application has complete capabilities and can be used for library development such as component libraries and tool libraries, as well as for container application development like shell applications, and for specific vertical business applications. In actual business scenarios, we often define and categorize applications for better understanding.

Shell Applications#

Shell applications are typically responsible for the basic framework of a project, such as the overall layout of a website, navigation menu, breadcrumbs, and user information, serving as an integrated application provided to users.

Business Applications#

Business applications are typically developed for specific business domains, such as order management, product management, user management, etc. Each business application can be developed, deployed, and debugged independently, and finally integrated into the shell application.

Library Applications#

There are often many commonalities between multiple micro applications, such as shared component libraries and tool libraries. Library applications are specifically designed for sharing resources in such scenarios.

Cross-Platform Applications#

Cross-platform applications are a core feature of wis. They allow you to use a unified definition specification to write different implementations for different platforms (PC, Pad, Mobile). When using them, we only need to write a unified set of code without worrying about the platform, as it will automatically direct resources to the corresponding implementation based on the current access platform type. This chapter will not discuss cross-platform applications in detail. If you are interested, please refer to Cross-Platform Applications.

Application Integration#

By default, each micro application automatically exports its page resources for consumption by other micro applications. Usually, we only need to modify the route access address to switch between different applications and pages.

When you want to switch from the current application to another application, such as the wis application, and access the Button demo page (/button) of wis, we only need to access the following route: /wis/button.

For example, if we are accessing the current application through https://localhost:3000#/, we only need to access https://localhost:3000#/wis/button to complete the application switch. The application switch will not affect the layout part of the current application. For more detailed information, see Pages and Layouts.

Application Routes#

Applications are reflected as part of the route, and switching applications is achieved by changing the route address. They are positioned between the layout route segment and the page route segment. For detailed information, please refer to Route Composition.

Application Resources#

In addition to sharing micro application pages, almost all micro application resources can be shared, including scripts, styles, components, etc. We need to configure shared resources through the wis.config.ts configuration file.

Resource Sharing#

When we want to share resources externally, we need to configure it through the exposes field. The exported resource name must start with ./, which complies with the Module Federation specification. The specific configuration is as follows:

import type { WisConfig } from "@wisdesign/wis-plugin";
 
export default const config: WisConfig = {
  exposes: {
    "./button": "./src/components/button/index",
  },
}

Resource Usage#

Resources are exported by micro applications, so we need to register the application before using the resources. For details, please refer to Registering Applications.

import { Button } from "wis/button";
 
export default function () {
  return <Button text="Wis Button" />;
}

Resource Sets#

Resource sets represent multiple classifications of the same resource. For example, with internationalization resources, we typically include resource packages for multiple languages. If we export all language packages uniformly according to the general resource export method, the exported language packages will become increasingly large as the number of language types increases. In actual production use, users will only use one language, which creates resource waste. Therefore, we have introduced the concept of resource sets, which allows us to export resource sets and match and load one resource from the set at runtime.

Currently, we support the following three types of resource sets:

• Internationalization resource sets
• Theme resource sets
• Cross-platform sets
• Cross-platform resource sets

Among them, cross-platform sets and cross-platform resource sets are core features of wis cross-platform applications. We will introduce them separately. If you are interested, please see Cross-Platform Applications.

1. Sharing Resource Sets

import type { WisConfig } from "@wisdesign/wis-plugin";
 
export default const config: WisConfig = {
  exposes: {
    // The name of the resource set is consistent with ordinary resources
    "./sets": {
      // Must include at least one default field
      default: "./src/source/set1/index",
    },
  },
}

2. Identifying Resource Sets

When loading resource sets, the application will read the data-kind attribute on the html tag, which can be a value separated by ,.

We convert it into a set and use this set to match the resource used by the current resource set.

• When the attribute is not set, the default resource in the resource set will be used.
• When the attribute is set and can match a resource, the matched resource will be used.
• When the attribute is set but cannot match a resource, no resource will be loaded.

It's worth noting that there are some minor flaws with this approach. When defining resource sets, try to avoid duplicate field names between different resource sets, as duplication can lead to resource set matching errors.

3. Setting Resource Set Identifiers

We can set the resource set identifier by setting the data-kind attribute on the html tag, which can be a value separated by ,.

Internationalization Resource Sets#

1. Export Format

import type { WisConfig } from "@wisdesign/wis-plugin";
 
export default const config: WisConfig = {
  exposes: {
    "./locales": {
      default: "./src/locales/en",
      zh: "./src/locales/zh",
    },
  },
}

2. Usage Method

import locales from "wis/locales";

Theme Resource Sets#

Our micro applications can be used for component library development, so they may involve loading different theme Design Token resources.

1. Export Format

import type { WisConfig } from "@wisdesign/wis-plugin";
 
export default const config: WisConfig = {
  exposes: {
    "./themes": {
      default: "./src/themes/blue/index",
      red: "./src/themes/red/index",
    },
  },
}

2. Usage Method

import "wis/themes";