You can add "hooks" that attach to any normal element. Those hooks have access to push/pull data/events down the socket, so you can basically set up listeners on any element to trigger what would be your normal REST calls. In that respect you can hook your <canvas> into integrating with a liveview process, but obviously it wont receive any DOM difffing etc. If your entire UI is in a canvas, you're probably better off using another UI framework - but perhaps you would still benefit from having a "live process" on the server with a socket, especially if you have any kind of chrome around it. It can simplify lots of stuff in general such as long running tasks, not having to think about a REST API, etc.
People also integrate directly with React/Svelt/Vue/etc though I dont have personal experience with doing that.
I have a reasonably complex LiveView app that has a complex UI, but they're still forms in the end, if only dressed up. Mostly its composed of "function components" (static-y bits of mark up) or "live components" (things that have some internal state, that I want to separate [sic] from the main process).
you write components for it
LiveView is a channel to pass data back and forth between backend and frontend in a very performant and size-effective way, that hides all the complexity involved, making it astonishingly simple to get started.
The presentation layer it's up to the developers.
Wanna react to a change?
setup a `phx-*` event
Wanna handle some custom event?
Setup a hook [1] [2]
[1] https://hexdocs.pm/phoenix_live_view/js-interop.html
[2] example of reacting to Monaco editor events: https://github.com/BeaconCMS/live_monaco_editor#fetching-the...
Front-end developers love the LiveView model with functional components, no state, and light node.js dependency.
Backend developers get a process/actor + OTP supervision tree that's second to none. Horizontally scalable, functional, and pretty simple at its core.
Fullstack developers get to transition seamlessly.
I've really enjoyed using it while building.
Pedantic but just for drive-by readers, there isn't really any nodejs dependency. You can use it to manage JS dependencies, or you can forgo it for "vendoring" with esbuild (or bun, etc).
Liveview itself has a small JS component that is mostly transparent (socket.connect() basically). You can of course add more JS too it.
implement this:
https://www.deepmind.com/blog/decoupled-neural-interfaces-us...
in this:
Someone at our local meetup said it was the future.
I would read a whole book about neural networks written in this style.
This lets you train a machine learning model of arbitrary size (bigger than can fit on a GPU, or even a multigpu node) using an actor-based distributed technique. There is a slight training cycles count penalty but it's way less than the cost of coordination.
If you are only re-rendering what is required, it's just a webpage at rest.
Does it not being typed affect productivity?
If anyone with experience can chime in, that'd be very appreciated!
The main reason for that is, the LiveView test framework is super simple to work with. I didn't write any tests when I was doing React / TypeScript just because it seemed so cumbersome to setup. Having a test suite that works out of the box made me write more tests for my front-end.
Not having to build API endpoints for my react components is also a huge accelerator in productivity.
In the end I ended up writing less code, with more polished / well tested front-end.
You can watch the video of what I built with LiveView here https://instellar.app
Also the fact that you have to setup API endpoints for your data, with liveview, you have direct access to the data. You can load any state with a function call instead of having to develop a separate endpoint for your frontend, handle hydration etc... You need real-time updates? It's done out of the box, you don't have to think about it. With react, that stuff is just ALOT to do.
I ended up removing a lot of controllers from my codebase that was there just to service the react front-end. Having those controllers do not service as the "API" of the app. Specs for front-end apis and core APIs are usually quite different based on my experience.
The easiest way I can explain it is LiveView is the least friction between thought and output. React / TypeScript just gets in the way because of all the choice and abstractions you have to build for it.
Don't get me wrong, React still has it's place, there are things I would still use react for, like if I need to render something visually rich, like a flow diagram (reactflow.dev), or video component, or make something like Figma, or a calendar / gantt chart, but for most front-end UIs (95%) you just don't need React.
When I was looking into Phoenix all routes, no matter how nested, had to resolve to single controller. That meant that controller for path `/user/settings/privacy` was also responsible for getting data to display users sidebar.
# lib/your_app_web/controllers/user_sidebar.ex
defmodule YourAppWeb.UserSidebar do
def load_sidebar(conn, _params) do
data = SomeModule.whatever_loads_your_sidebar_data()
assign(conn, :sidebar, data)
end
end
# then in router.ex:
import YourAppWeb.UserSidebar
pipeline :users do
plug :load_sidebar
end
scope "/users", YourAppWeb do
pipe_through [:browsers, :user]
get "settings/privacy", SettingsController, :privacy
# and all other routes that need this sidebar
# …
end
Remember that an HTTP request/response cycle in Phoenix is fundamentally just a list of transformations that are applied to a `%Plug.Conn{}`. If you want the same behaviour to apply to multiple controller actions, you can just define that behaviour in a plug function (i.e. a two-arity function that takes and returns a conn), then pass your conn through that plug before it reaches your controller actions.