Use Any Javascript Library With Vue.js

Use Any Javascript Library With Vue.js

Lodash, Moment, Axios, Async…these are useful Javascript libraries that you’ll want to utilise in many of your Vue.js apps.

But as your project grows you’ll be separating code into single file components and module files. You also may want to run your app in different environments to allow server rendering.

Unless you find an easy and robust way to include those Javascript libraries across your components and module files they’re going to be a nuisance!

How not to include a library in a Vue.js project

Global variable

The naive way to add a library to your project is to make it a global variable by attaching it to the window object:

entry.js

window._ = require('lodash');

MyComponent.vue

export default {
  created() {
    console.log(_.isEmpty() ? 'Lodash everywhere!' : 'Uh oh..');
  }
}

The case against window variables is a long one, but, specifically to this discussion, they don’t work with server rendering. When the app runs on the server the window object will be undefined and so attempting to access a property will end with an error.

Importing in every file

Another second-rate method is to import the library into every file:

MyComponent.vue

import _ from 'lodash';

export default {
  created() {
    console.log(_.isEmpty() ? 'Lodash is available here!' : 'Uh oh..');
  }
}

This works, but it’s not very DRY and it’s basically just a pain: you have to remember to import it into every file, and remove it again if you stop using it in that file. And if you don’t setup your build tool correctly you may end up with multiple copies of the same library in your build.

A better way

read more

Don't Forget Browser Button UX In Your Vue.js App

Don't Forget Browser Button UX In Your Vue.js App

When building single-page applications many Vue developers forget about UX for browser button navigation. They mistakenly assume that this kind of navigtion is the same as hyperlink navigation when in fact it can be quite different.

Unlike hyperlink navigation, if a user goes forward and back between pages they expect the page to still look like it did when they return or they’ll consider the UX “weird” or “annoying”.

For example, if I were browsing a thread on Hacker News and I scroll down to a comment and collapse it, then I clicked though to another page, then I clicked “back”, I’d expect to still be scrolled down to the comment and for it to still be collapsed!

Hacker News comments

In a Vue.js app, though, this is not the default behaviour; scroll position and app data are not persisted by default. We need to consciously set up our app to ensure we have a smooth and predictable UX for the browser navigation buttons.

Configuring Vue Router

Vue Router’s role in optimal back and forward UX is in controlling scroll behavior. A user’s expectations with this would be:

read more

Faking Server-Side Rendering With Vue.js and Laravel

Faking Server-Side Rendering With Vue.js and Laravel

Server-side rendering (SSR) is a design concept for full-stack web apps that provides a rendered page to the browser. The idea is that the page can be shown while the user waits for scripts to be downloaded and run.

If you aren’t using a Node.js server for your app then you’re out of luck; only a Javascript server can render a Javascript app.

However, there are alternative to SSR that may be good enough, or even better, for some use cases. In this article I’m going to explain a method I use to “fake” server-side rendering using Vue.js and Laravel.

Pre-rendering

Pre-rendering (PR) tries to achieve the same outcome as SSR by using a headless browser to render the app and capture the output to an HTML file, which is then served to the browser. The differnce between this and SSR is that it is done ahead of time, not on-the-fly.

Limitation: user-specific content

Some pages, like the front page of your site, will probably contain general content i.e. content that all users will view the same. But other pages, like admin pages, will contain user-specific content, for example a user’s name and birth date.

The limitation of PR is that it can’t be used for pages that contain such content. As I just said, the pre-rendered templates are only made once and can’t be customised. SSR does not have this limitation.

Faking server-side rendering

My fake SSR method for Vue and Laravel is to pre-render a page, but replace any user-specific content with Laravel Blade tokens. When the page is served, Laravel’s view helper will replace the tokens with user-specific content.

So before pre-rendering your page will have this:

<div id="app"></div>

After pre-rendering you’ll have this:

<div id="app">
    <div>
        Hello {{ $name }}, your birthday is {{ $birthday }}
    </div>
</div>

And when the page is served by Laravel your browser receives the following, which is exactly what it would receive from SSR:

<div id="app" server-rendered="true">
    <div>
        Hello Anthony, your birthday is 25th October.
    </div>
</div>

With this method we get all the benefits of SSR but it can be done with a non-Node backend like Laravel.

read more

Pre-Render A Vue.js App (With Node Or Laravel)

Pre-Render A Vue.js App (With Node Or Laravel)

Server-side rendering is all the rage right now. But it’s not without its downsides. Pre-rendering is an alternative approach that may even be better in some circumstances.

In this article we’ll explore how pre-rendering works with Vue.js and look at two examples; one with a Node.js project, one with a Laravel project.

Server-side rendering

One of the downsides to Javascript-based apps is that the browser receives an essentially empty page from the server. The DOM cannot be built until the Javascript has been downloaded and run.

This means that the user has to wait a bit longer to see anything. It can also have an impact on SEO if crawlers can’t see content of the page quickly.

Server-side rendering (SSR) overcomes this issue by rendering the app on the server so that the client receives the complete DOM content when the page is loaded, before Javascript is even run.

So instead of the browser receiving this from the server:

<head> ... </head>
<body>
<div id="app">
  <!--This is empty, Javascript will populate it later-->
</app>
</body>

With SSR it receives a page with complete content:

<head> ... </head>
<body>
<div id="app">
  <div class="container">
    <h1>Your Server-Side Rendered App</h1>
    <div class="component-1">
      <p>Hello World</p>
      <!--etc etc. This was all rendered on the server-->
</app>
</body>

Server-side rendering cons

  • Your app will need to be executable on the server, so you’ll need to design your code to be “universal” i.e. it works in both the browser and a Node server.

    read more

7 Ways To Define A Component Template in Vue.js

7 Ways To Define A Component Template in Vue.js

There’s plenty of choice when it comes to defining component templates in Vue. By my count there are at least seven different ways:

  • String
  • Template literal
  • X-Templates
  • Inline
  • Render functions
  • JSX
  • Single page components

And maybe more!

In this article we’ll go through examples of each and address the pros and cons so you know which one is the best to use in any particular situation.

1. Strings

By default a template will be defined as a string in your JS file. I think we can all agree that templates in a string are quite incomprehensible. This method doesn’t have much going for it other than the wide browser support.

Vue.component('my-checkbox', {
	template: `<div class="checkbox-wrapper" @click="check"><div :class="{ checkbox: true, checked: checked }"></div><div class="title"></div></div>`,
	data() {
		return { checked: false, title: 'Check me' }
	},
	methods: {
		check() { this.checked = !this.checked; }
	}
});

2. Template literals

ES6 template literals (“backticks”) allow you to define your template across multiple lines, something you can’t do in a regular Javascript string. These are much easier to read and are supported now in many new browsers, though you should probably still transpile down to ES5 to be safe.

read more