Conversation
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>
burbas
left a comment
There was a problem hiding this comment.
I think this is doing what it should and certainly works, but I'm a bit conflicted about bringing in a lot of dependencies for something that the user might not want to use. So my suggestion is that we instead try to modularize the protocol-option in the routes so it works roughly as our handlers. That way we can support a lot of different protocols and be slim at the same time :-). Then we could break this out and make a separate application of it which the interested user can bring in and start to use.
|
Moved Arizona integration to arizona_nova instead (https://github.com/novaframework/arizona_nova/tree/feat/live-route-helper). Nova core doesn't need to know about Arizona — arizona_nova_live:live/1,2 returns standard Nova-compatible funs. |
Summary
nova_arizonabridge module for rendering Arizona LiveView views through Nova's request pipeline#{protocol => liveview}— views go through the full plugin/security middleware chain/liveWebSocket endpoint (configurable viaarizona_live_pathapp env) when liveview routes are presentRoute syntax
How it works
nova_arizona:render_view/3for HTTP renderingregister_view/3finalize/1builds Arizona's Cowboy dispatch table (persistent_term:put(arizona_dispatch, ...)) soarizona_websocketcan resolve views for client-side reactivity/liveWebSocket endpoint is added as a raw Cowboy handler (#cowboy_handler_value{})Test plan
🤖 Generated with Claude Code