Multi-Platform Frontend Architecture and Code Reuse Practices at Ctrip Play Team

Author Introduction

Neo, a front‑end engineer at Ctrip, is responsible for the Play team’s front‑end architecture.

1. Introduction

The article shares the Play team’s practical experience of code reuse across multiple platforms, aiming to provide ideas for developers facing similar challenges.

1.1 Background

Before the multi‑platform effort, the Play front‑end suffered from a fragmented and outdated tech stack, inconsistent across business lines (e.g., .NET, iMVC, Next.js, jQuery). The company’s push toward React made the legacy stacks a maintenance burden. Additionally, product requirements demanded simultaneous delivery for PC, H5, Hybrid, and RN, which would have required changes in six separate repositories. Release processes were manual, and monitoring was insufficient.

1.2 Measures

The team upgraded the architecture, adopted component‑driven development, and ensured that a single change is visible on all platforms.

2. Architecture Overview

The new architecture splits the codebase into four repository layers:

Base and component libraries (shared services, React component wrappers, AJAX, localization, dialogs, pricing, etc.).

Business component library and SSR repository (business‑specific components and server‑side rendering support).

Engineering repository (tools such as init for dependency installation, watch for hot‑reload, dev for running CRN/H5/online, ares for static asset packaging, precommit for linting, publish for automated Node.js deployment).

Publish repository (contains only configuration files; the code itself remains in the development repo).

Images illustrate the repository layout and configuration files (e.g., app.config.js , app.js , package.json ).

3. Specific Practices

3.1 Service and API Encapsulation

Third‑party components (multilingual, header/footer, locale) are wrapped in unified APIs; all text is fetched via a translate component to keep business logic consistent.

3.2 Code Responsibility Division

The team follows “convention over configuration” and divides a page into five layers: fetch (network requests), view (platform‑specific UI), format (data transformation), action (non‑UI business logic), and style (styling, automatically injected).

3.3 Dynamic Style Injection

Only a single index.tsx is used; platform‑specific CSS is generated at build time (px → rem conversion for H5, dynamic CSS tree construction for PC/H5).

3.4 Runtime Dependency Injection

For universal code, empty variables are declared and populated at runtime (e.g., a rn‑polyfill.ts file for RN modules). This prevents unwanted code from being bundled during static analysis.

4. Conclusion

After restructuring, developers focus on business components while the shared infrastructure handles multi‑platform concerns. Development time for a single feature across all platforms decreased by nearly 40%, and the framework continues to evolve to further reduce duplicated view and style code.