plan-ui-change

Identify each distinct visual region that owns its own state or behavior, then draw a component tree showing parent-child relationships. Classify each component by render mode and estimated size, keeping any single component under roughly 200 lines of markup and code.

Data flows down through [Parameter] attributes and events flow up through EventCallback<T>. The page or parent component owns the data and passes filtered views to children, which never mutate parameters directly.

Skip this planning workflow for simple single-component pages, creating new Blazor projects from scratch, or implementing one individual component. Those cases are better served by project scaffolding or single-component authoring workflows.

Build bottom-up: models and DTOs first, then services, leaf components, container components, the page component, and finally DI configuration. Each component should be independently compilable so parents can reference children that already exist.

When data must cross more than two levels without intermediate components needing it, use a cascading value or a scoped state service instead of passing parameters through every layer. This keeps component signatures clean and intent clear.