Pages and Components

In UniApp’s cross-platform development model, the distinction between a page and a component is more than a naming detail. It affects navigation, lifecycle handling, data flow, testing, and long-term maintainability. Both concepts are built on Vue’s reactive principles, but they operate at different layers of an application.

What Is a Page?

A page is the basic unit of application navigation. It usually represents a full screen, a route, or a logical view. In UniApp, pages are registered through the routing configuration and often correspond to a specific path. This gives pages the ability to receive route parameters, respond to navigation actions, and participate in the navigation stack.

Because of this, a page tends to own higher-level responsibilities. It may handle route params, trigger network requests, manage page-level state, and coordinate the rendering of child components.

What Is a Component?

A component is a reusable UI fragment. It can be an atomic building block or a complex business-specific block. Components receive data through props, communicate through events, and render UI based on that contract.

Components do not own routing. They do not need a URL in the same way pages do. They exist to be composed into pages or into other components.

Lifecycle Differences

The lifecycle gap is one of the most important practical differences.

A page has navigation-aware lifecycle hooks. UniApp commonly references hooks such as onLoad, onShow, onHide, and onUnload. These hooks connect the page to route changes, tab switches, and visibility transitions.

A component follows a more general lifecycle. Common hooks include created, mounted, and destroyed. A component may not directly sense page navigation. It might need to wait for the page to pass context or emit an event to request action.

Data Interaction and Communication

Data flow in UniApp often follows Vue’s one-way pattern. A parent passes data down through props. A child sends messages upward through events.

For simple parent-child cases, props and events are enough. For deeper or shared state, developers may turn to state management or global event patterns. UniApp also provides its own global event APIs, which can be useful, but they should be used with care in complex projects.

Engineering Reuse

A healthy architecture usually separates concerns clearly.

• Atomic components handle basic UI elements such as buttons, inputs, and tags.
• Business components encapsulate domain-specific blocks such as user info panels or order items.
• Pages act as containers that manage state, routing, and composition.

The goal is to keep components focused on presentation and interaction, while pages focus on orchestration and navigation context.

Performance Considerations

Cross-platform differences add complexity. A design that works well on one platform may need tuning on another.

• Use lazy loading for large components.
• Use virtual lists for long content.
• Keep prop references stable to avoid unnecessary re-renders.

Conclusion

In UniApp, pages and components are related but not interchangeable. Pages serve navigation and container roles. Components serve reuse and UI composition roles. Understanding their differences helps developers build cleaner data flow, stronger boundaries, and more maintainable cross-platform applications.