HenriMorlaye
Hi,
I was reading the VueJS documentation and then I thought about something:
What if a Phoenix template engine rendered .vue.eex files instead of .html.eex files ?
(.vue files are single file components including the html fragment (with the vue attributes), the script fragment with the vue viewmodel and the style css fragment.)
The template engine would render the vue component tree the same way .vue files are compiled in webpack, and phoenix would serve the compiled html to the client.
The magic would be that instead of writing html, we could write very reactive front-end code, using packaged components but without having to jump into the whole SPA thing.
I thought that a potential problem would be that .js and .css fragments are compiled on the fly, instead of preprocessed and bundled as it is currently the case in Phoenix. But if I am not mistaken, if each components’ js and css fragments are served as individual files instead of a concatenated file, then it would not be a problem on http/2 servers ?
Any thoughts ?
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
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
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
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.
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 8- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
kokolegorille
It looks like You want to do server side rendering with vue.
I think it’s possible to put an intermediate node server that would interpret javascript and render html. Also in react, there is a render to string method, that helps doing SSR.
Otherwise, the Drab library can help You generate reactive frontend, from the server.
But I am not sure it would be easy for phoenix to take vue files, interpret js, and output html.
LostKobrakai
There are a few hurdles with your idea:
EEx won’t parse custom templating. It’s “Embedded Elixir”, which comes down to elixir code within tags within arbitrary text.
Phoenix can have other templating engines than eex, but it’s probably a lot of work to map vue templates to elixir code at compile time and your js bundle would still need the templates in js form for runtime updates of the markup. So besides a third party form of SSR (without hydration) it’s not really improving much.
Just compiling the templates for usage with the lighter vue runtime basically means the vue templates are compiled into js functions. That’s imo a clear concern of a js bundler and not elixir. It’s still js, which comes out at the end.
SSR with vue can probably be more smoothly implemented by using it’s new (v 2.5) V8 compatible renderer within the beam or an external node instance on the same server. This can execute the SSR part of rendering vue components natively.
HenriMorlaye
I wasn’t thinking about SSR. More about building a Vue tree inline in the html template and sending it to the client. The client then initializes automatically a Vue instance on the html body.
Imagine for example returning this template:
But the datepicker vue component would be built from a .vue template file.
LostKobrakai
Having custom html markup injected into components is already possible by using inline-templates or slots, so I don’t really get what you expect the
.vue.eexfile to accomplish over a .vue file bundled into your js assets.HenriMorlaye
Indeed, I have a similar setup already. I guess my “problem” is that some eex file renders a template containing an inline vue component, which is somewhat connected to a css and a js file somewhere in my assets. Reading the Vue doc I found the idea of single file components (the .vue file) interesting to solve this, thinking that the file in web/template could contain all the markup / logic / styling colocated.
aadii104
@LostKobrakai thanks for the elaborated answer.
I have got a doubt from your statement (“SSR with vue can probably be more smoothly implemented by using it’s new (v 2.5) V8 compatible renderer within the beam or an external node instance on the same server.”) and actually I am looking solution for this.
Doubt is :- how can i make sure that the vue rendering and processing will done within the beam ? coz at last this could be a bottle neck.
please do share your comments and any follow-up article/ code sample to achieve same.
Thanks.
LostKobrakai
There are v8 implementations for erlang out there, but I’ve not used them so I cannot say anything about their quality. To use them with vue SSR you probably need to put the pieces together on your own. I’m not aware of anyone having done that already.
adesakin
I truly wish we can have vue.eex.