A-Frame Component Update Lifecycle: Execution Order for Simultaneous Property Changes

Execution order of update() on a single entity

When setAttribute is called on an entity that has several components, A‑Frame processes the changes component‑by‑component. For each component that receives a change, the framework does the following, in order:

• init() – only on the first attachment of the component.
• update(data, oldData) – called once per component, even if multiple properties were changed in the same setAttribute call. The arguments contain the new values and the previous values.
• tick() – scheduled for the next render frame, not executed immediately after update().

Ordering across components

The framework resolves the order of update() calls using one of two deterministic rules:

1. Registration order – components are updated in the order they were registered with AFRAME.registerComponent.
2. SetAttribute call order – if multiple setAttribute calls are made in the same JavaScript tick, the order of those calls overrides registration order.

In practice, most scenes use the default registration order because components are registered once at load time. If you need a different priority, register the component you want to run first before the others.

No built‑in transaction or priority API

A‑Frame does not expose a transaction system that guarantees atomic updates across components. The only way to influence order is via the rules above. If your component’s logic depends on another component’s state, you should either:

• Read the dependent component’s data inside update() – the data will already be the latest value if the dependent component was updated earlier in the same cycle.
• Use tick() or play() to defer logic until the next frame, when all update() calls have finished.

Practical verification steps

1. Create a scene with two components, foo and bar, and log their init, update, and tick calls.
2. Register foo before bar.
3. On the same frame, call setAttribute('foo', {a:1}) and setAttribute('bar', {b:2}).
4. Observe that foo.update runs before bar.update.
5. Swap the registration order and repeat – the order of update calls flips accordingly.

These steps confirm the deterministic ordering and show that no duplicate updates occur when multiple properties change simultaneously.