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!
Trending in Proposals: Ideas
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Develop your skills with books, videos, and courses.
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
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 9 of 9 Posts
cmo
I believe Chris has mentioned that is one of the things he still wants to achieve.
superchris
Looks like our posts crossed
It’s great to hear these features requested, for custom elements I’ve implement exactly these in a library called LiveElements. I reached out in a separate post to see if it would make more sense to integrate this kind of thing in LV proper, I’ve had suggestions from other folks that this would be a good thing and happy to help if this is desired.
markevans
great that’s good to hear!
markevans
ah that’s great!
Yeh I agree something in LV proper would be a good idea.
If custom elements were supported more directly then an alternative to the suggestion I had above for React/Svelte/Vue/etc. of having a standard adapter interface would be to wrap the React/Svelte/Vue components in custom elements instead.
I know that Svelte, Vue, Angular can actually all compile into custom elements anyway so that would also be an option, but if a user wants to use an off-the-shelf component it won’t usually be packaged as a custom element so they might need some kind of wrapper.
Out of interest, in LiveElements I see for listening to events it’s using the
phx-custom-event-hook- what does this send asparameterstohandle_event? Is it the CustomEvent event.detail? In the Komodo library I was umming and ahing about what to send back over the wire by default because I didn’t want accidental big payloads being sent back (e.g. the whole event object) so I ended up making the user be explicit about what gets sent as the payload, but not sure if that’s best. I guess also sometimes you might want event.clientX or something though that’s more for clicks so maybe event.detail is fine…superchris
It had been a minute since I touched this code, so I had to go look to refresh my memory
For the payload of the event I send up to the phoenix channel, I take the custom element detail property and also merge in the element data set (any attributes that start with
data-). This seems to give enough flexibility to do what I need to do in the cases I’ve encountered so far.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
.vuefiles 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:
<.vue v-component="Counter">you can use<.Counter>)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.
Liam_or
I would also love to hear the approach you’re taking! Let us know if you can