Engineering Practices and Tooling for Frontend Development at Liulishuo (2016‑2017)

My simple view of engineering is to abstract common development problems and address them with appropriate tools, frameworks, and standards, allowing engineers to focus on business logic and more challenging issues. Based on this, we tried several approaches in 2016.

Base Library

Our front‑end foundation is built on webpack and React. While many articles discuss React's pros and cons, we found it beneficial for writing reusable component logic and leveraging a rich ecosystem of third‑party libraries. However, React’s bundle size has become large, and lighter alternatives with better rendering performance are now attractive, making a lightweight base library upgrade a key goal for 2017.

Componentization for Consumer‑Facing Apps

Abstract Common Page Components

In our consumer‑facing WAP projects we abstracted common UI components such as Modal, Toast, loading animations, and lock‑screen effects, as well as solutions for mobile‑specific challenges like jsbridge definitions and page adaptation. These reusable pieces are shared across multiple consumer projects.

Componentization for Internal Tools

Liulishuo maintains many complex backend tools for course entry, operations support, student management, and reporting. As product lines expand, tool volume grows rapidly, leading to two main problems:

1) Early‑stage internal tools were developed by backend engineers using varied tech stacks and design assumptions, causing frequent context switches during maintenance.

2) Insufficient component abstraction; many legacy tools were built directly on raw DOM, limiting functionality and extensibility.

Our solution is to unify code style with ESLint and adopt Ant Design (antd) plus MobX.

1) Antd’s component library covers over 90% of internal‑tool business logic.

2) MobX’s two‑way binding simplifies form handling and promotes code reuse; the team, more comfortable with object‑oriented programming than functional Redux, adopts it faster.

Development Support Tools

Mock Data Auto‑Generation

After adopting front‑end/back‑end separation, we can write mock APIs independently. However, creating mock data manually is repetitive and often skipped under tight schedules. We built a mock data generator that reads Protocol Buffer‑compatible API specifications and produces corresponding mock data, saving time and encouraging developers to use mocks.

Unit Testing

Front‑end projects, especially in fast‑moving startups, often neglect unit testing due to perceived maintenance overhead. Based on our experience, two areas are worth testing: common UI components and core state management of critical pages.

1) Testing reusable components ensures their behavior boundaries, supports continuous integration, and serves as documentation.

2) Testing core page state (e.g., a purchase page) prevents regression when business rules change, reducing the need for manual mock‑data updates and lowering production costs.

Error Monitoring

Front‑end runtime variability makes it impossible to guarantee flawless operation for every user. We adopted Sentry for error monitoring after reading “the‑fine‑art‑of‑javascript‑error‑tracking”. Its advantages include clear error descriptions, breadcrumbs of user actions, comprehensive email/Slack alerts, affordable pricing compared to New Relic, and sourcemap support.

Deployment

We use shipit‑deploy, a JavaScript equivalent of Capistrano. Its orchestrator‑based task flow allows customizations via promises, supporting features like abort on failure and manual rollbacks.

During a library upgrade, a minor change caused Android low‑version devices to throw “Object.assign is not a function”. Sentry alerts helped us quickly identify the issue, add a polyfill, and roll back the deployment with shipit‑deploy, preventing large‑scale impact.

Summary and Outlook

Over the past year we distilled and applied several universal practices that improved code productivity, build/release processes, and error monitoring. In the coming year we aim to:

1) Better measure online page rendering performance with quantifiable metrics for load‑time optimization.

2) Strengthen unit‑test coverage to increase front‑end robustness amid frequent releases.