Interface: ActorProviderProps

API / @xmachines/play-vue / ActorProviderProps

Defined in: packages/play-vue/src/types.ts:19

The props of the ActorProvider component. This file holds them, so that TypeScript can re-export them. The vue-shim has a limit that stops a re-export from the .vue file.

The null-view content is a slot named fallback, and not a prop. The provider shows that slot when currentView is null, and also while a contained error of a descendant is active (see onError).

Extends

BaseActorProviderProps<DefineRegistryResult>

Extended by

PlayUIProviderProps

Properties

Property	Type	Description	Inherited from	Defined in
`actor`	`ViewActor`	The actor instance with the currentView atom. It requires the Viewable capability.	`BaseActorProviderProps`.`actor`	packages/play-view/src/view-types.ts:219
`onError?`	(`error`, `reset`) => `void`	The optional callback. The provider calls it when a descendant fails the RENDER — the render function, the setup function, or a lifecycle hook — and the error boundary of ActorProvider contains the error (`onErrorCaptured`). `onErrorCaptured` of Vue fires for an error of an event handler and of a watcher callback as well, and this prop reports NEITHER: the boundary of React, the ErrorBoundary of Solid and `<svelte:boundary>` see such an error never, so a report here would give play-vue a wider contract than the other four renderers. Those errors continue to `app.config.errorHandler` exactly as they do without this provider. `onError` reports a failure of the render, in every renderer. Vue reports such an error a SECOND time where the application wires no `app.config.errorHandler`: it re-throws the error, and a queued job carries it back as a failure of a render. The provider recognises that repeat and holds the view. It writes the error value to `console.error` with the name of this package, because Vue writes that value nowhere on this path, and `onError` stays silent. A development build re-throws every time, and a production build only where the application sets `app.config.throwUnhandledErrorInProduction`. ONE case escapes that rule. An ancestor `errorCaptured` hook that returns `false` stops Vue before the re-throw, so the record of the provider waits for a repeat that never comes. A second failure in the same flush can take that record. It must carry the same error value, and it must unwind out of the update job of a parent. Vue reports such a failure as a component update. The provider then holds the stale subtree on the screen, and `onError` stays silent. While the error is active, the provider renders the `fallback` slot instead of its children. The provider clears the error on the next view emission (when `currentView` changes), so a view transition retries the render. The boundary stops the error. Without this prop the provider therefore writes the error to `console.error`, because `app.config.errorHandler` does not see it. The per-element boundary of `json-render` catches a throw of a catalog component below the root, and it reports it through `onRenderError` alone. A failure of the ROOT — its component, a prop, or its `visible` condition — leaves no view, and json-render gives it to no boundary of the host. The provider contains it as a failure of the view all the same: it shows the fallback, and it calls this handler one time. `onRenderError` also receives it, with `info.kind` `"root"`. This boundary is the outer net for everything else. The second parameter is the RESET, for a retry that the host starts — a “Retry” button of its own. It clears the contained error and renders again, and it resolves the view that the actor holds at the MOMENT OF THE CALL, so a host that keeps the callback cannot rewind the screen to the view that failed. A reset that the host calls from inside this handler starts no second retry, because no input changed between the two attempts, and a reset after the provider is unmounted does nothing. The five renderers hold the same three rules. A handler that THROWS reaches no caller. The provider contains that throw, and it writes the throw to `console.error`. The errored flag schedules a RENDER, so a throw that left this handler would stop that render and skip the `return false` of `onErrorCaptured`: the subtree that threw stays on the screen AND the error reaches `app.config.errorHandler`. Report a failure from this handler. To ESCALATE one, raise it from a task of your own — `rethrowLater(error)` of `@xmachines/core/utils` — which reaches the global handler of the page and leaves the containment whole. The host installs `@xmachines/core` itself. The five renderers hold this one rule.	-	packages/play-vue/src/types.ts:81
`onRenderError?`	`OnRenderError`	The renderer calls it with `(error, name, info)` for each failure that it reports: a catalog component that throws, a prop or a `visible` condition that fails, an action chain or a watch chain that fails, and a failure of the root. `info.kind` names the kind of the failure. A handler with the two parameters `(error, name)` stays valid. This handler replaces every onRenderError of defineRegistry.	`BaseActorProviderProps`.`onRenderError`	packages/play-view/src/view-types.ts:236
`registryResult`	`DefineRegistryResult`	The complete result of defineRegistry(). It holds the component registry and the factory of the action handlers.	`BaseActorProviderProps`.`registryResult`	packages/play-view/src/view-types.ts:221
`store?`	`StateStore`	The optional external StateStore, which is the controlled mode. With this option, the provider ignores spec.state, and this store is the single source of truth. Without it, the provider makes a new @xstate/store atom for each view transition, with the values of spec.state.	`BaseActorProviderProps`.`store`	packages/play-view/src/view-types.ts:228