North star
A developer building LiveViews in TypeScript or JavaScript should have capabilities equivalent to current Phoenix LiveView and a comparably coherent experience, while the public API remains idiomatic, strongly typed, and natural in the JavaScript ecosystem.
Protocol/client interoperability is tracked separately in #182. This issue is the product capability ledger and acceptance contract.
Required parity ledger
Create a versioned, machine-readable capability manifest for the latest stable Phoenix LiveView release and generate the human-readable parity table from it. Every entry records its upstream reference, LiveView.js API, status, owning issue, and evidence IDs for types, conformance/integration, browser E2E, runtimes, documentation, and examples.
Every upstream capability must be marked:
- Supported — public API, conformance/integration tests, browser E2E, and documentation exist.
- Partial — exact supported subset and missing behavior are linked to issues.
- Missing — an actionable roadmap issue owns it.
- Not applicable / intentionally different — rationale and LiveView.js alternative are documented.
CI must reject unknown statuses, missing evidence required by a Supported entry, duplicate capability IDs, stale issue references, and disagreement between the generated docs and the manifest.
At minimum inventory:
- Lifecycle: mount, params, events, info/messages, async callbacks, termination, connected/disconnected state.
- Lifecycle hooks/on-mount behavior and reusable cross-cutting modules.
- Assigns, temporary assigns, async results, cancellation, and server-pushed events.
- Stateful/stateless components, update/preload behavior, component targeting, and composition.
- Rendering/diffs, comprehensions, statics, tracked assets, and change tracking.
- Streams and stream DOM semantics.
- Forms, changesets/validation, CSRF, debounce/throttle, recovery, and nested inputs.
- Uploads, external uploads, progress, cancellation, and consumption.
- Navigation, patch/redirect, flash, page titles, and reconnect/history behavior.
- Client hooks, JS commands, DOM patch options, and JavaScript interoperability.
- PubSub/server messages, clustering/distribution boundaries, and process/runtime semantics.
- Testing helpers, telemetry/observability, debugging, security, and deployment ergonomics.
TypeScript/JavaScript experience requirements
- Strongly typed context/assigns, events, infos, route params, component props, uploads, async results, and test helpers.
- No public
any escape hatches used to claim feature completeness.
- JavaScript remains usable without TypeScript while retaining runtime validation and good diagnostics.
- Naming/composition should be idiomatic for TypeScript/JavaScript; deviations from Phoenix naming must be documented in the parity ledger.
- Framework plumbing—WebSockets, protocol envelopes, reconnection, diffing, and cleanup—stays transparent for ordinary application development.
- Examples demonstrate composition and reusable components rather than one large tagged-template return value.
Definition of parity for each capability
A manifest entry cannot be marked Supported until all applicable evidence fields resolve to passing tests or maintained documentation:
- public API and type tests;
- upstream conformance fixture or documented semantic test;
- integration/protocol tests;
- real-browser E2E for applicable behavior;
- Node, Bun, and Deno coverage where the capability is runtime-neutral;
- documentation and at least one maintained example;
- explicit error/cleanup/security behavior.
Exit criteria
North star
A developer building LiveViews in TypeScript or JavaScript should have capabilities equivalent to current Phoenix LiveView and a comparably coherent experience, while the public API remains idiomatic, strongly typed, and natural in the JavaScript ecosystem.
Protocol/client interoperability is tracked separately in #182. This issue is the product capability ledger and acceptance contract.
Required parity ledger
Create a versioned, machine-readable capability manifest for the latest stable Phoenix LiveView release and generate the human-readable parity table from it. Every entry records its upstream reference, LiveView.js API, status, owning issue, and evidence IDs for types, conformance/integration, browser E2E, runtimes, documentation, and examples.
Every upstream capability must be marked:
CI must reject unknown statuses, missing evidence required by a Supported entry, duplicate capability IDs, stale issue references, and disagreement between the generated docs and the manifest.
At minimum inventory:
TypeScript/JavaScript experience requirements
anyescape hatches used to claim feature completeness.Definition of parity for each capability
A manifest entry cannot be marked Supported until all applicable evidence fields resolve to passing tests or maintained documentation:
Exit criteria