markevans
Better interop with Javascript libraries (React, Svelte, etc.)
Hi!
I feel like Phoenix is slightly missing a trick when it comes to front-end Javascript libraries like React, Svelte, etc.
I feel that Javascript framework components could be treated as even more of a first-class citizen than they currently are.
I realise that most, if not all, of what you need to do can be done just with LiveView, but there are times when you want a little bit more interactivity, or it doesn’t make sense to have some browser-related state in the LiveView process memory.
In those cases rendering JS framework components (particularly just as leaf nodes) from LiveView is the perfect fit.
Yes, we can use hooks for that, and also yes, there are libraries that provide these hooks, but I believe it could be even easier if Phoenix did half the work for you, i.e. the non-framework-specific parts.
Currently, a library that helps to plug a JS framework component into LiveView has to:
- provide elixir code, e.g. a function component, to render the component from the liveview
- provide javascript hook code, to mount the JS framework component and update appropriately
If Phoenix did the non-framework-specific parts out of the box (1. and some of 2. above), then for a user to use components from any given JS framework they’d only need the adapter part of 2. above, which would likely live in a third-party npm package (i.e. no need for elixir code at all).
I’ve just released a simple library, Komodo (see Komodo - easily render React, Svelte, Vue, Angular, any JS framework component from Liveview) that does (1) and (2) above, but it would be great if the generic parts weren’t even needed because Phoenix already did it (and had a standard interface for a “js component” that each library would adapt to).
To be specific, the Komodo library currently requires the user to do this in app.js:
import { registerJsComponents } from "komodo";
import componentFromReact from "some-third-party-adapter-lib-for-react";
import SomeComponent from "path/to/some/react/component";
// ...
let liveSocket = new LiveSocket("/live", Socket, {
hooks: {
komodo: registerJsComponents({
MyReactComponent: componentFromReact(SomeComponent)
})
}
// ...
});
If Phoenix already did this, this would become, for example
import componentFromReact from "some-third-party-adapter-lib-for-react";
import SomeComponent from "path/to/some/react/component";
// ...
let liveSocket = new LiveSocket("/live", Socket, {
jsComponents: {
MyReactComponent: componentFromReact(SomeComponent)
}
// ...
});
instead.
Anyway just throwing around a few thoughts - I hope that made at least some sense!
At the very least it would be great if Phoenix (i.e. HEEX) had built-in support for custom elements (i.e. native web components) that went as far as:
- allowing props that were more than just strings, e.g. arrays, objects
- allowing listening to custom events
without requiring the user to write an extra hook for this.
Then at least people could always have the option of wrapping their framework component with a custom element if the above wasn’t feasible.
What do you think? Any thoughts welcome!
Most Liked
Sebb
We are just building an app with LV and solidjs.
There is close to zero friction, working very nicely together.
markevans
nice - what are you using to integrate them - a custom hook? or some library?
I was going to write a solidjs adapter for komodo but didn’t want to have to support too many libraries myself (though would be super easy to do)
Jskalc
Some time ago I’ve created live_vue. Heavily inspired by LiveSvelte, it uses Vite instead of ESbuild for stateful hot reload & SSR bundling in development, also it’s easy to include all .vue files to app bundle by using glob imports. We cannot use esbuild package as it doesn’t support plugins, and we need them to compile vue / svelte files.
All in all, I had very similar thoughts to you, as posted in this twitter thread. You need:
- Server side function to render & sync props to your client side component (possibly with many performance optimizations like diffing props)
- Client side hook to initialize / update props / pass events from your frontend framework to live view
- Bundler configuration to support your framework of choice
- SSR configuration - might be not trivial with code splitting, preloading etc.
- Macro for creating shortcuts (eg. instead
<.vue v-component="Counter">you can use<.Counter>) - Slots support
I’d say steps 2-4 are dependant on the frontend framework, but it’s not a “huge” difference. I’m considering creating a core library that would install individual frontend frameworks as plugins. So something very similar to what you’ve done with Komodo, just with more features provided. I don’t think it should be part of the LiveView itself, since using it is entirely optional and there are multiple opinions about framework of choice.
Btw, Inertia.js does it in the right way. I think doing something similar but for LiveView makes perfect sense.
Popular in Proposals: Ideas
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









