API reference

Every public class, method, and event in @codexo/exojs. Generated from source.

C

classDestroyScope

@codexo/exojs / core / stable

Ownership container for Destroyable resources. Items registered with track are destroyed in reverse registration order when the scope itself is destroyed - the spine of ExoJS's ownership-driven cleanup. A Scene owns one for its whole lifetime, exposed as `Scene.track`. An `Application` does not: it creates one for the duration of its constructor, to release the subsystems already built if a later construction step throws (the caller never receives an instance, so `destroy()` is unreachable). Its own `Application.destroy()` runs an explicit ordered teardown instead, because the WebGPU→WebGL2 backend fallback replaces subsystems after construction, which a long-lived scope would not follow. `track` is idempotent and returns its argument for fluent capture: ```ts const world = scope.track(new PhysicsWorld()); ``` destroy is idempotent and tolerant: every tracked item's `destroy()` is attempted even if an earlier one throws, so a single failure cannot leak the rest. In development the collected errors are rethrown as an `AggregateError` once teardown completes; in production they are swallowed. A `DestroyScope` is itself Destroyable, so scopes can nest.

2
props
4
methods
0
events
Import
import { DestroyScope } from '@codexo/exojs'

Ownership container for Destroyable resources. Items registered with track are destroyed in reverse registration order when the scope itself is destroyed - the spine of ExoJS's ownership-driven cleanup.

A Scene owns one for its whole lifetime, exposed as `Scene.track`. An `Application` does not: it creates one for the duration of its constructor, to release the subsystems already built if a later construction step throws (the caller never receives an instance, so `destroy()` is unreachable). Its own `Application.destroy()` runs an explicit ordered teardown instead, because the WebGPU→WebGL2 backend fallback replaces subsystems after construction, which a long-lived scope would not follow.

`track` is idempotent and returns its argument for fluent capture:

```ts const world = scope.track(new PhysicsWorld()); ```

destroy is idempotent and tolerant: every tracked item's `destroy()` is attempted even if an earlier one throws, so a single failure cannot leak the rest. In development the collected errors are rethrown as an `AggregateError` once teardown completes; in production they are swallowed.

A `DestroyScope` is itself Destroyable, so scopes can nest.

Constructors1
new(): DestroyScope
Methods4
destroy(): void
Destroy every tracked item in reverse registration order, then clear the scope. Idempotent. Continues past a throwing item; in development the collected errors are rethrown as an AggregateError after teardown.
has(item: DestroyableStructural interface for anything that holds resources requiring explicit release. ExoJS value types tend to implement this even when no external resources are…): boolean
Whether item is currently tracked.
track(item: T): T
Register item for destruction with this scope. No-op when item is already tracked or the scope is already destroyed. Returns item so it can be captured inline: const x = scope.track(new Thing()).
untrack(item: DestroyableStructural interface for anything that holds resources requiring explicit release. ExoJS value types tend to implement this even when no external resources are…): boolean
Stop tracking item without destroying it (ownership returns to the caller). Returns true if it was tracked. No-op after the scope is destroyed.
Properties2
destroyed: boolean
Whether destroy has already run. A destroyed scope tracks nothing further.
size: number
Number of items currently tracked.
Source
src/core/DestroyScope.ts