Skip to content

feat: Arizona LiveView routing integration#369

Open
Taure wants to merge 6 commits intomasterfrom
feat/arizona-liveview-routing
Open

feat: Arizona LiveView routing integration#369
Taure wants to merge 6 commits intomasterfrom
feat/arizona-liveview-routing

Conversation

@Taure
Copy link
Collaborator

@Taure Taure commented Mar 12, 2026

Summary

  • Add nova_arizona bridge module for rendering Arizona LiveView views through Nova's request pipeline
  • New route protocol #{protocol => liveview} — views go through the full plugin/security middleware chain
  • Auto-registers /live WebSocket endpoint (configurable via arizona_live_path app env) when liveview routes are present
  • Arizona remains an optional dependency — no runtime calls unless liveview routes are defined

Route syntax

routes(_Env) ->
    [#{prefix => "", routes => [
        {"/", my_home_view, #{protocol => liveview}},
        {"/counter", my_counter_view, #{protocol => liveview, mount_arg => #{initial => 0}}}
    ]}].

How it works

  1. During route compilation, liveview routes register a Nova callback closure that calls nova_arizona:render_view/3 for HTTP rendering
  2. Each liveview route is also accumulated via register_view/3
  3. After compilation, finalize/1 builds Arizona's Cowboy dispatch table (persistent_term:put(arizona_dispatch, ...)) so arizona_websocket can resolve views for client-side reactivity
  4. The /live WebSocket endpoint is added as a raw Cowboy handler (#cowboy_handler_value{})

Test plan

  • Verify compilation passes with xref and dialyzer (no Arizona dependency needed at compile time)
  • Test with a project that includes Arizona — confirm HTTP render and WebSocket upgrade work
  • Verify projects without Arizona are unaffected (no-op when no liveview routes)

🤖 Generated with Claude Code

Taure and others added 6 commits March 12, 2026 22:53
Add nova_arizona bridge module enabling Arizona LiveView routes in Nova.
Routes defined with `#{protocol => liveview}` render Arizona views through
Nova's full middleware chain (plugins, security) and auto-register the
/live WebSocket endpoint for Arizona's client-side reactivity.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add broadcast/subscribe/unsubscribe functions that delegate to
arizona_pubsub, letting Nova controllers push real-time updates
to Arizona views without importing Arizona modules directly.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Move PubSub to nova_pubsub with broadcast/2, subscribe/1,2, unsubscribe/1,2
using Arizona's {pubsub_message, Topic, Data} format on nova_scope.

Simplify nova_arizona: remove PubSub wrappers, add resolve_view/1 for
WebSocket view resolution, set Arizona's pubsub scope to nova_scope.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Nova's liveview routing now uses arizona_nova_websocket (from the
arizona_nova integration package) instead of directly referencing
arizona_websocket. Removes arizona_pubsub:set_scope/1 from nova_arizona
since arizona_nova_sup handles scope setup during startup.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Extend handle_ws/2 to support multi-frame replies ({reply, [Frame], CD})
so Arizona LiveView can send initial renders, diffs, and action responses
in a single callback. LiveView WebSocket connections now go through
nova_ws_handler with plugin pipeline support instead of bypassing Nova
as a raw cowboy_websocket handler.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
`fun Module:Variable/1` syntax doesn't work with variable atoms in
Erlang — it produces undefined. Use `erlang:make_fun/3` to construct
the callback dynamically.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant