Choosing @State vs @Prop for Synchronous Updates: When Do Re‑renders Occur?

Question

Internal vs External State: A Decision Point
StencilJS offers two primary decorators for managing component data: @State for internal, encapsulated state, and @Prop for data supplied by a parent or via an HTML attribute. The choice between them hinges on ownership of the data and the desired data flow direction.
When a component performs multiple updates—some to @State properties and others to @Prop properties—in a single synchronous block, the timing and ordering of re‑renders are not explicitly documented. This uncertainty can affect UI consistency, especially in complex component hierarchies.
Unresolved Behavior
While Stencil guarantees a re‑render whenever a decorated property changes, it does not specify whether the framework batches these changes or processes them sequentially. The lack of clarity raises questions about potential intermediate renders and the final render order.
Specific Questions

When multiple @State and @Prop updates occur together, which properties trigger a re‑render first?
Does Stencil batch all property changes within a synchronous block to produce a single render, or does each change cause its own render?
What is the observable order of renders when both internal state and external props change simultaneously, and how does this affect component lifecycle hooks?

Tasadduq Burney · Answer

Answer first
For StencilJS, a change to an @State property or an incoming @Prop value marks the component dirty and schedules an update. Stencil does not apply changes synchronously inside the same call stack; updates are queued and flushed asynchronously. That means multiple assignments to @State and @Prop inside one synchronous block do not cause multiple immediate renders for the same component.
What is confirmed: @State is internal ownership, mutated via the component’s own setter, and @Prop is external ownership, updated when a parent renders with a new value or an attribute changes. Both can trigger a re-render of the component that owns them. What is not confirmed from the supplied research brief is the exact batching and ordering guarantees for Stencil, because the brief covers React behavior, not Stencil.
Confirmed facts vs likely explanation
Confirmed: Stencil uses an async render queue. State mutations are not reflected in the DOM until the queue is flushed. Prop changes arrive from the parent’s render cycle.
Likely explanation for Stencil, marked for review: Within a single synchronous task, multiple @State writes to the same component are coalesced into one render. A @Prop change originates in the parent, so the child re-renders as part of the parent’s commit. The relative order of a local @State update and a @Prop update that happen in the same synchronous block is implementation-dependent and should not be relied on for UI logic.
Practical verification steps for this case

Log render entry in the component function or componentWillRender and log state/props values.
In a button handler, set two @State fields and then set a @Prop via parent state. Observe the number of render logs per event.
Use Stencil DevTools to inspect the render queue and confirm one commit per synchronous event for the same component.

Assumption and uncertainty: Batching details can vary by Stencil major version and by whether the update is triggered by DOM events, lifecycle hooks, or imperative API calls. The recommendation above assumes Stencil 4+ default async rendering.
One missing diagnostic detail that changes the recommendation: the exact Stencil version and whether flushSync-like behavior or manual forceUpdate is used in the code. Provide the version to confirm batching semantics.

Choosing @State vs @Prop for Synchronous Updates: When Do Re‑renders Occur?

Internal vs External State: A Decision Point

Unresolved Behavior

Specific Questions

1 answer

Answer first

Confirmed facts vs likely explanation

Practical verification steps for this case

Your perspective belongs here.

0 question comments