Design and Implementation of a One‑Code‑Multi‑End Interactive Development Engine Using Taro and React

The article introduces the close relationship between interactive games and the "one‑code‑multiple‑end" (一码多端) scenario in platform business, explaining why native mini‑program development is preferred over H5 embedding and why a unified engine is needed.

Problems faced: selecting a suitable cross‑end framework, integrating basic capabilities (login, tracking, navigation), designing a reusable model, and handling UI adaptation, compatibility and monitoring across different environments.

Framework selection: After comparing Taro, uni‑app and Chameleon, Taro was chosen for its strong WeChat mini‑program support, React compatibility, and existing React‑based Dva state‑management modules.

Data management: The team adopted a lightweight wrapper around Dva‑core, removing H5‑only dependencies, and built a global store that fetches shared data from the backend, avoiding duplicated state and ensuring consistency between modules such as tasks and lottery.

Generic model: A three‑dimensional model (page scenes, initialization flow, business modules) was defined, with a lightweight Redux‑based scene manager to handle preload, main gameplay and error scenes without using traditional routing.

UI adaptation: The rem‑based responsive solution was selected, dynamically adjusting the root font size according to device width, providing consistent scaling across various screen sizes.

Layered page layout: Five layers (background, animation, HUD, modal, toast) were introduced, with recommended z‑index ranges to prevent style conflicts; React portals can further isolate modal and toast layers.

Animation strategy: Primarily CSS transition and keyframe animation are used, while WebGL/Canvas is avoided due to limited mini‑program support.

Adaptation layer: A unified adaptation layer abstracts environment‑specific APIs (location, subscription, risk control, media, tracking) and introduces a new runtime environment variable (APP_RUNTIME_PLATFORM_ENV) to strip irrelevant code during Taro compilation.

Engineering support: Features such as a mock server, environment‑specific variables, automatic sprite‑sheet generation, code style and Git conventions were integrated to streamline development and reduce manual effort.

Challenges encountered: style loss in common.wxss, shared singleton data causing cross‑page contamination, and build failures caused by path naming restrictions; solutions included custom Taro plugins and class‑based component instances.

Conclusion: The one‑code‑multiple‑end engine has successfully supported major interactive projects, improving development efficiency by roughly 30%, while ongoing work focuses on expanding reusable modules and refining the framework for future business needs.