@exactjs/core

Application-authoring primitives and shared runtime contracts for eXact.

Overview

@exactjs/core provides component types, contexts, lifecycle APIs, refs, error boundaries, Suspense, function-defined tasks, interactions, and finite component registries. Applications normally combine it with @exactjs/jsx, an eXact compiler integration, and a renderer such as @exactjs/dom or @exactjs/ssr.

An eXact component owns one durable instance and local mutable this.state. Its outer function is analyzed into a reactive state machine of defaults, tasks, relationships, and render preparation. The returned function contains one JSX view expression. Async outer functions define owned blocking initializer tasks. Local PascalCase view arrows are lexical micro-components that share their owner.

Component example

import type { Component } from '@exactjs/core';

export function Counter(this: Component<{ count: number }>) {
	this.state.count = 0;

	return () => <button onClick={() => this.state.count++}>{this.state.count}</button>;
}

The compiler connects each state read to the work that consumes it, so an update does not require re-executing the component.

Main capabilities

• partitionChildren(), childrenOf(), and withChildren() from @exactjs/core/children for immediate-child composition
• Document, doctype(), and documentOutput from @exactjs/core/document for customizable document declarations, defaults, and renderer-owned output slots, preserving authored metadata and reactive html/body attributes
• Context, refs, lifecycle cleanup, Suspense, Activity, and error boundaries
• Optional server task snapshots through component-owned TaskContext.client().progress() receivers; see task progress for lifecycle and deployment limits
• Function-defined tasks with status, direct invocation, synchronous optimistic state, and optional TaskContext placement and concurrency policy
• createComponentRegistry() for finite eager or lazy component selection
• createDynamicComponent() for intentionally open client-only providers; prefer a finite registry whenever the candidate set is known, and do not use open dynamic components for server work
• createComponentDomain({ executionRoot }) for integrations that establish explicit ownership roots without exposing framework transport or activation capabilities
• Shared component-operation, task, and inspection types used by framework integrations
• A realm-wide cache-backed intl facade; the compiler includes component localization only when a component uses this.intl, with the nearest localization context supplying the active locale for omitted or matching authored-source locale requests

Helpers outside a component can format through the shared pool directly:

import { intl } from '@exactjs/core';

const price = intl
	.NumberFormat('en-US', {
		style: 'currency',
		currency: 'USD'
	})
	.format(42);

Compatibility integrations that construct framework values outside compiled component source must install localization explicitly with import '@exactjs/core/localization'. Compiled components need no such import.

Use explicit task policy for placement, scheduling, cancellation, keys, or inspectable identity. Task status includes queued and running work, including nonblocking and deferred tasks. Readiness policy independently controls whether Suspense waits. Framework integrations use the runtime/render, runtime/registry, and framework/component-contracts subpaths.

Learn more

See the component language, tasks, actions and forms, and component registries guides. See child composition and document shells for child selection, doctypes, and framework output placement.

Documentation | Source on GitHub