HenriMorlaye
Idea: rendering .vue.eex templates
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 ?
Most Liked
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:
<body>
<h1>Your Birth Date Picker</h1>
<datepicker current-date="<%= Date.utc_today %>">
<p>Please, <%= @username %>, insert your birth date</p>
</datepicker>
</body>
But the datepicker vue component would be built from a .vue template file.
Popular in Discussions
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
- #javascript
- #code-sync
- #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








