We’ve got wiki’s for Elm and Bucklescript, and so as it seems Vue.js is growing in popularity in Elixir circles, it makes sense to have one for it as well
Please add your thoughts about it - have you used it? Would you? What do you think?
Please also feel free to add any blog posts or other resources that would be helpful to anyone using Phoenix.
Anyone at Trust Level One can edit the wiki - simply add whatever you think needs adding to this post, then also make a new post with the info (or summary) so that the thread is bumped and people are alerted to it
This can be found elsewhere, but because it’s so important it’s worth repeating here.
Vuejs single file components don’t work very well with Brunch (the default asset compiler that comes with Phoenix). You’ll get an error each time you try to import a module from inside the .vue file Webpack, despite its shortcomings, has excellent support for Vuejs components, so if you want to use them, you should switch to Webpack.
To use webpack with Phoenix with support for .vue files (single file components):
I’ve used Vue.js in various ways since v1 and there’s a good community around it. It’s one of those tools that once you get a swing of it you’re wanting to use that hammer to hit every JS nail
I like to keep my state on the client and the server stateless, but there are other possibilities. This is just the one I’m most comfortable with. The basic idea is that the client contains the current state, and the Server sends state deltas using channels (yeah, this is 2017, the server sends data to the client without being asked for). Usually
The initial state JSON encoded inside a hidden DOM node (e.g. <div style="display:none">#{JSON-DATA}</div>). My vue components will just pick this state from the DOM. This saves a HTTP request to get the initial state.
I use Ajax POST, PUT or DELETE requests to change data on the server according to the semantics of the verb (these changes might be sent to other clients using channels, see below)
I use Ajax GET to get the full state of the component if needed. Not deltas, usually.
I use channels to send state deltas from the server to the client. Usually, these deltas require some client side processing before being displayed. Fortunately, using Vuejs means that we only have to integrate the delta into the state, and the UI will update itself automatically.
This is just a warning and speculation based on something I never really tried: Note that in the setup above, theoretically we might lose a delta if it is sent after the page render on the server and before the client starts listening to events in the channel.
If this is not an option for your app, you could get the state from a GET request only after your code is listening to the channel, so that you’re sure you’re not missing any events. This will increase the page load time because of the latency of that GET request.
So, if you want to be as fast as possible, you can do something like this: 1) send the state encoded in the DOM, 3) start listening to the channel and 3) get the state from the server with an Ajax GET request, and re-render the component with the possibly updated state (while the channel is already listening). This way, you should miss no events. However, ask your friendly neighborhood javascript expert before trusting this setup with your business-critical notifications! I’m just trying to warn you of the possible dangers of the approach I described above.
I did not actually have much of an issue with it but I used in-string templates instead of html templates (which currently require that pre-compilation step until HTTP2 is out and standard, same issue Polymer and such have). I’d honestly say ignore the .vue file setup and just use string-templates, it is ‘slightly’ faster too on initial setup if you want another reason. ^.^
Basically just copy/paste the html into the string used by a template (though I make a file of a template string and when I define the component I just call in to those for my bigger ones, that let’s me keep my html syntax highlighting in Atom).
If you use a HTML template instead then when vue loads it just gets the outerHTML of it anyway, thus converting it to a string, so it saves a short step.
That is the only thing the webpack loader for it is useful for, just splitting the ‘vue’ files into javascript parts, and it would not surprise me if it was a babel step that you could put into brunch anyway, but I don’t like those splitters anyway so I’m happy with string literals.
Ok, thanks. I think I’ll keep using .vue files because I like the ergonomics and I’m willing to wait a couple of seconds for the initial asset compilation.
I started with React/Redux/React Router and switched to Vue/Vuex/Vue-Router and couldn’t be happier. It’s simpler in every way, provides the exact same benefits and the router is way better.
You can also get server-side rendering for free without a node server (although not technically the same). Just create the template as a regular HTML/EEX file as usual but mark it as an inline-template. You can then tell your component to use the existing rendered HTML as the initial component template.
I also don’t .vue single file components but that’s because I never bought into the whole “separation of technologies not separation of concerns” argument. I like to have a single CSS file used thoughout the site and I also like to separate the template from the JS logic.
I don’t use Brunch now though because you don’t get real hot code reloading and when using a state manger (Vuex) it’s very useful. I’m using Webpack now but reluctantly.
Having worked my way through many of the popular frontend frameworks, I can say that I really dig Vue. It really hits that Goldilocks zone by being an un-opinionted view model and ONLY a view model. It incorporates Angular 1.x-style templating with React-like components and virtual DOM. The components are totally optional but very easy to build; No learning JSX or needing a webpack step if you don’t use the optional .vue file format.
What most people seem to like about Vue is it handles the harder parts of making a single page app or frontend (data binding and event management) without being overly opinionated. There are no services to write, no controllers to inherit, no data models you have to adhere to; You’re in charge of your logic and your data. This extends to routing; There is a vue-router you can use, but it’s purely optional and totally separate so you could always write your own if you felt like it. Likewise, you can use any data management you want, including Redux.
I really like Vue for being super useful even if not working on a SPA or alike. It can be seamlessly added to any part of a website. So if you have that one stateful client side thing in your website you can totally use vue there and be happy. It also makes getting into the library way more simple than say react, where you first have to setup so much stuff before you can get your hands dirty. With vue the easiest setup is literally just loading the vue.js file.
I’m using laravel-mix and it does have support for vue and .vue files baked in. It’s also way easier to configure than webpack itself.
Here’s a gist on how to install it, which I just updated from the one I found previously to work with the recently released v1.x: Using Laravel-Mix with Phoenix · GitHub
This is a real time saver during development. It allows you to see exactly what your Vue.js components are doing in real time. There is a Chrome extension as well as a new Firefox Addon.
I personally don’t hot module reload at all, it is fast enough to refresh and I hold the page ‘state’ either on the server, in the URL, or in the localsession or so.
But yeah, Vue.js is very webcomponent’ish but in pure javascript with one of the fastest VDom’s out since it ‘does’ use a vdom but it uses connections similar to how Polymer works internally, so it is very fast.
From my humble experience with React, I agree that it can be painful to get started, but it is very well suited for big SPAs and there’s a nice community (many components are open sourced).
Vue does seem to handle many things in a very simple way, but how does it scale for a large SPA? Are some hard problems like rendering big lists fast solved in Vue?
Have updated the wiki with some of what you’ve all posted - please feel free to add anything you feel is missing (just add to wiki then post in a new post as well)
