Low‑Code Exploration and Remote Component Integration for Large‑Scale Front‑End Activities

1. Introduction The Cat Ear front‑end team historically built activity pages with pure pro‑code. After adopting an internal low‑code activity platform in 2020, most routine activities could be configured by operations, freeing development resources. However, large‑scale live events (lasting up to two weeks) still required extensive manual coding, consuming significant manpower despite representing less than 1% of total events. The team sought to reuse existing low‑code components to accelerate development and address long‑tail maintenance needs.

2. Scenario Analysis and Problem Identification

2.1 Development approaches for different scenarios

Activities are divided into two categories:

Configuration‑type pages (Low Code + No Code) : When no development is needed, operations configure and publish the page themselves. If minor adjustments are required, developers may add JS or CSS patches.

Development‑type pages (Pro Code) : Complex activities with many states are built entirely by developers based on design, product, and API specifications.

Problems discovered in the pro‑code workflow include:

Low efficiency in updating activity rules during intensive development periods.

Repeated effort for common demands such as redesigning ranking lists or post‑event data integration.

Duplicate implementation of components (e.g., live‑ranking widgets) that could not be reused via low‑code.

Iframe‑based low‑code integration suffered from modal positioning, cross‑origin issues, and redundant resource loading.

3. Solution and Implementation

Adhering to the DRY principle, the team introduced Remote Components (internally called “segment loader”). Starting in October 2022, live events began loading low‑code ranking components, pop‑ups, and rules remotely within a pro‑code page framework, eliminating the need for bespoke CSS and JS for each event.

3.1 Remote Component Architecture

Each remote component consists of three data assets: a JS bundle, a CSS bundle, and a JSON configuration generated by operations. The client‑side loader fetches the assets using a predefined segment ID and renders them via the existing low‑code renderer.

3.1.3 Code Comparison (old vs. new)

Old implementation required >100 lines of CSS and manual integration for each ranking component. The new approach reduces this to a single loader call.

fetchSegment(pageId)
  .then(async (res: any) => {
    if (!res || !containerRef.current) {
      console.error('segment load failure');
      return;
    }
    const { info, render } = res;
    if (!loadedPageIds.includes(pageId)) {
      loadedPageIds.push(pageId);
      const newComponentsMap = makeComponentsMap(info.configure?.pageData);
      window.MissEvanEvents.next((prev: any) => {
        const mergedComponentsMap = Object.entries(newComponentsMap).reduce((acc, [key, value]) => {
          acc[key] = (acc[key] ?? []).concat(value);
          return acc;
        }, prev.componentsMap ?? {});
        return { ...prev, componentsMap: mergedComponentsMap };
      });
    }
    render({ container: containerRef.current, needRenderEnvComponent: false });
  })
  .catch((e: any) => {
    console.error('segment load failure', e);
  });

3.2 Integration Practices

To align pro‑code pages with low‑code capabilities, the team packaged common page utilities, leveraged RxJS BehaviorSubject for global data sharing, and built a unified initialization component that runs in both environments. Code blocks (JS + CSS) were standardized with lifecycle hooks (mount/unmount) to avoid duplicate insertion and memory leaks.

// Example of a code‑block lifecycle definition
function mount(dependency) { /* ... */ }
function unmount(dependency) { /* ... */ }
ContextManager.initLifecycle({ mount, unmount });

4. Outcomes and Benefits

By migrating repetitive features to low‑code, the front‑end team reduced manual coding effort, enabled earlier delivery before design finalization, and allowed operations to adjust certain modules without a full release cycle. Version granularity improved, facilitating rapid hot‑fixes during live events. Quantitative data (shown in the original tables) demonstrate significant reductions in code‑block count and increased reuse of low‑code components.

5. Conclusion

The case study illustrates how integrating remote low‑code components into a traditionally pro‑code workflow can streamline large‑scale activity development, improve resource utilization, and accelerate delivery. The approach is applicable to other front‑end teams facing similar scalability challenges.