Deterministic Initialization in A-Frame
There is no documented setting or native lifecycle hook in A-Frame to enforce a deterministic reinitialization order specifically for hot-reload events. Because hot-reload plugins typically operate by removing and re-adding a specific component to an entity, they bypass the global declaration order established during the initial page load.
The Root Cause of Order Inconsistency
In a standard page load, A-Frame initializes components based on their declaration order in the HTML. However, a hot-reload event is a targeted mutation. When a single component is re-instantiated, it triggers its init and update methods immediately. If that component depends on state provided by a sibling component that has not been re-instantiated (or is in the process of being updated), a race condition occurs.
Recommended Implementation Strategy
To ensure a repeatable development environment without relying on full page refreshes, you should move dependent reads out of init. The following patterns are the established ways to handle inter-component dependencies:
- Move Logic to
update: Use the update handler to react to changes. Since update is called after init and whenever a component property changes, it is more resilient to the timing of sibling instantiation.
- Deferred Execution in
tick: If a component requires a state that may not exist yet, check for the existence of that state in the tick function. Once the dependency is detected, execute the logic and disable the check to avoid performance overhead.
- Event-Based Handshaking: Have the "provider" component emit a custom event (e.g.,
state-ready) upon completion of its init. The "consumer" component should listen for this event rather than assuming the provider is ready during its own init.
Verification and Production Parity
A full page refresh remains the only native way to guarantee that the production initialization sequence (based on HTML declaration order) is followed exactly. To verify if your hot-reload logic is diverging from production, you can use the following diagnostic approach:
// Add to the init() of both provider and consumer components
console.log(`[${this.el.id}] ${this.componentName} initialized at ${performance.now()}`);
Compare the timestamps between a hard refresh and a hot-reload to identify the specific shift in execution order.
Diagnostic Requirement
To provide a more specific architectural recommendation, please specify if you are using a custom build of aframe-hot-reload or a specific integration (like Vite or Webpack), as the method of component replacement can vary by plugin.
aframe