Master Frontend Component Architecture: From State Lifting to Scalable Containers

Frontend componentization has become a hot topic, but many teams still struggle with incomplete specifications, high coupling, low reuse, and code redundancy as projects grow.

Discovering the Problem

Four illustrative diagrams show how a business module evolves through iterations, leading to increasingly complex multi‑layer component hierarchies and shared state across components.

Common Approaches to Shared State

State lifting: move shared state to a container component and pass it down.

State management libraries such as Redux or Vuex.

Event mechanism: child components emit events, parent components listen and update state.

Issues with These Approaches

Determining which states belong in a global store.

Preventing over‑use of global state that leads to chaos.

Defining clear boundaries between container and presentational components.

Ensuring consistent collaboration standards to avoid high onboarding cost.

Proposed Solution

The author suggests establishing clear specifications to unify code style and component contracts.

Define development standards for container and presentational components.

Specify which component states should be extracted to a state management store and how to handle them.

Container vs. Presentational Components

Container component: responsible for fetching, updating, submitting, and deleting data used by presentational components; it does not perform direct DOM updates.

Presentational component: focuses on rendering, includes virtual DOM changes and styling, does not depend on any store; it can be a stateless function but may contain lifecycle methods.

Guidelines

Presentational components must be used inside container components; shared state is managed by the container.

When a presentational component needs to modify shared state, it should emit a stateless callback to the container, which then performs the state operation.

Parent‑child containers share state unidirectionally: child containers can read but not modify parent state directly.

Modifications to parent or non‑hierarchical shared state must go through the central store.

Because stores hold extensive shared data, register shared states by module and container name to keep the hierarchy clear.

Conclusion

The article records the author’s reflections on frontend component standards and provides a practical framework for managing component state and responsibilities.