Streamlining Multi‑Platform Frontend Component Development with Fusion and Rax

Introduction

Whether in the early jQuery/YUI era or the modern React/Vue era, component libraries have always been a core concern for front‑end teams. Reusing encapsulated logic dramatically improves UI construction efficiency, making component work a top priority regardless of the underlying stack.

Why Do Business Components Need Multiple Iterations?

A colleague requested a component package covering PC, mini‑app, and visual components. The PC side used iceworks + deep scaffolding, which integrates well with Fusion. Mini‑app development relied on the early Rax‑based Fusion Mobile solution, while visual components were built with the Lego vdev toolchain. Because PC uses React and mini‑app uses Rax, the same component required four separate packages and extensive configuration, inflating development cost and cognitive load.

Fusion Development Concept

The goal is to eliminate the need for multiple toolchains and packages by creating a single “fusion package” that works across React and Rax. This requires:

Combining the build pipelines of both frameworks.

Providing a unified directory structure.

Ensuring demos and prototypes can be compiled for both environments.

Directory Architecture

The fusion package follows the visual component file layout, with src containing view.tsx (PC) and view.mobile.tsx (mobile/mini‑app). TypeScript and SCSS are used throughout to stay consistent with Fusion components.

Toolchain Selection

We chose the Lego vdev suite as the base because it provides a heavy‑weight visual component ecosystem and is maintained by the core infrastructure team. Existing build‑scripts plugins were reused where possible, and a custom build‑plugin‑vdev‑component was added to handle the fusion-specific steps.

NPM Scripts

start

: launch visual debugging (designer + preview). startPC: launch PC debugging. startMobile: launch mobile web debugging. startMiniapp: launch mini‑app debugging. build: generate all build artifacts.

Debugging and Build Challenges

During development, the demo files are written from a PC perspective, importing React components and @ali/deep. When debugging mini‑app, aliases map React to Rax and @ali/deep to @ali/deep-mobile. JSX is transformed to createElement calls, allowing the same source to work in both runtimes. React.createElement("div") vs Rax.createElement("div") is resolved at runtime based on the active alias.

For the build, we needed both React and Rax demos. The existing build‑plugin‑component could only target one framework, so we extended it: the Rax part runs as usual, while a secondary Webpack task (added via build‑plugin‑vdev‑component) builds the React demo. AST analysis determines whether a file is a React or Rax component, applying the appropriate Babel configuration.

Final Outcome

The fusion package consolidates PC, mobile, and visual components into a single npm package. Developers import the same package regardless of target platform, using paths like es/view.mobile for mobile or lib/view.mobile for mini‑app. The package’s package.json registers both entry points, enabling seamless Webpack resolution.

Automation and Future Work

Automatic generation of prototype.tsx based on component props, reducing manual setter configuration.

One‑click sync of component metadata to the Material Center after publishing.

Integration of @ali/mini to launch a WebIDE for mini‑app debugging with a single command.

Future directions include improving build‑time efficiency, expanding business‑domain coverage, deepening low‑code capabilities, and exploring model‑driven UI generation.

Conclusion

The described practices aim to lower learning curves, eliminate repetitive tasks, and simplify complex steps, ultimately boosting front‑end business component development efficiency.