Vue with Phoenix

Phoenix Forum Questions / Help
,
1

Hi All,
I am building a project in #phoenix, Then i came know about vuejs, is it a good idea to mix these two. (rendered server side). Its in its beginning stage.
Thanks!

2

It can be a good idea, it all depends on what you’re trying to achieve and your needs :slight_smile:

Here’s a recipe for setting it up: https://medium.com/@bonfirealgorithm/how-to-set-up-vue-js-with-phoenix-1-4-2ed8bda7f4e0

3 Likes
3

Thanks for the fast reply.
Could be a stupid question?.
But will there be an overload? or will there be performance issues? Instead of printing the directly, we fetch data, print html, send it to vuejs and finally vuejs prints it for us.
And which is better, using phoenix as an api only app? let vue handle frontend? or render it server side?.

4

I know that no one here or in the community expresses this, but if your rendering server side then I see no real benefit to loading in a complete js framework like react or angular or vue … all these frameworks are designed to completely hand off the UI to the js, you also have a very large dependency to download, plus trying to keep sync between your fully handed off js app and the backend model… is a pain.

Every time I have to work with server side rendered pages (via any backend like elixir and phoenix, java and thymeleaf, .net and razor etc) I use what has always been popular in .Net circles… Knockout.js

Its a tiny dependency, you simply bind the server rendered variables directly to observed ko functions (they work the same as liveviews morphdom). All knockout does is data binding, it creates watched js functions that bind UI interactions to data model changes and visa versa.

You can bind the whole thing into a viewmodel class for OO … but for phoenix I just bind each piece of data to its own separate function … when that data changes it triggers a UI diff operation, I actually create observed ko function outside a class to work the same as single functions that I feels suits phoenix and elixir well and I’m never mutating a some overarching class object which saves alot of headaches. This gives you a powerful UI data binding system that means when data is say true, the bound element appears, or a class is added or an action is triggered, and the value just is linked so if data changes the values are automatically updated everywhere… all without the massive bundle loads of react vue etc.

https://knockoutjs.com/

http://learn.knockoutjs.com/

3 Likes
5

Here was a git repo with a simple knockout binding to demonstrate, just a simple sprinkle of ko in the main view


Its built on that example project to build chat app in 8 minutes so updates with websockets. (https://github.com/dwyl/phoenix-chat-example)

UI elements are bound to the functions via the
data-bind=“text: dataItem” to display text say
or
data-bind=“if: dataItem” to display the element if var dataItem is present and
not null

Ko watched functions are defined in the script tag…
var dataItem = ko.observable('show me ');
ko.applyBindings( );

In this repo above the message display, the class switching for user styling and the message content display is all done via knockout, I pass knockout the phoenix websocket messages directly into a watched array and the UI updates when the messages update

2 Likes
6

Thanks for the repo ( evomedia247/Phoenix-and-knockout-example) that too in a short period. :star_struck:

7

It’s hard to answer this without knowing your specific use case.

I’d say the biggest cost of adding Vue is that the client will have to download more JS. That said I think there are situations where this is warranted, e.g. you have certain pages in your app that are interaction-heavy, but you still want to let Phoenix render most of the pages, do the routing, auth, etc. and you want everything in one repo.

Splitting the frontend off completely is good for separation of concerns but can also lead to more complexity and duplication of code. Like always it’s about tradeoffs.

1 Like
8

I’ve used Vue together with Phoenix in production, you should have no issues using them together. Two important things:

  1. Make sure you actually need an SPA. It’s much easier to work with Phoenix templates if you don’t need an SPA.
  2. Vue CLI is excellent, but it doesn’t really play nice with Phoenix (maybe this has gotten better since the release of Vue CLI v4). I would suggest just setting up Webpack for the Vue side.
1 Like
9

Its not an SPA, @Ruffalo. And yes i read about this as well “but it doesn’t really play nice with Phoenix”. I going with @bulldog_in_the_dream. Keeping it simple.
I like to Keep it simple and stupid. (K.I.S.S).
Thanks folks.