Forem: Stef van den Ham

A different kind of blog post

Stef van den Ham — Wed, 29 Apr 2020 08:01:38 +0000

I enjoy blogging, but was suffering of a little bit of a writer's block. Writing short tutorials, walkthroughs, tips and tricks seemed to be getting more and more redundant because a specific answer is usually a Stackoverflow answer away.

Writing about a mini project however was a lot of fun which I had done in the past. So I decided a different approach and rather than writing a end-to-end clearcut tutorial to achieve something I instead wrote about my outset, decissions, considerations and fails while working on a personal project dealing with a dataset.

I really enjoyed writing it and while doing it gave me a lot of new inspiration for future code adventures. Of course I have no idea whether other developers might enjoy reading such posts, but I think the main point is that writing these type of posts helps you grow as a developer as you have to put into words what is the chaos that's in your head.

If you want to read the post, it's here!

Launched a free webservice to check your pagespeeds

Stef van den Ham — Thu, 30 Nov 2017 20:11:18 +0000

Heya, after scratching my own itch I decided to publish the tool Wulfdeck at https://wulfdeck.com/ for everyone to use for free.

It finds the linked pages from your site, and then checks them all for their Pagespeed.

What do you guys think, useful? Pointless? Does it work for you?

Hope to get some feedback :)

https://wulfdeck.com/

Getting started with the PanResponder in React Native

Stef van den Ham — Thu, 16 Nov 2017 07:48:26 +0000

Inside React Native you can use the PanResponder to recognize multi-touch gestures as well as swipes and other touches that make native apps feel snappy and intuitive. But getting it up and running can feel daunting and borderline black magic. In this post I'll try and guide you through the process, hopefully demystifying it a bit and get you on track to awesomeness.

What we will be making

Obviously we'll be wanting to focus on the PanResponder itself so UI wise this will be pretty barebones. We'll have an image on screen we can drag. When we release it it will bounce back to its original position. As a bonus, while we press down on the image it will scale up.

![PanResponder Demo](https://mindthecode.com/images/panresponder_demo.gif)

Setting the stage

I'll be assuming you're somewhat familiar with setting up a fresh React Native project. If not, the guys at Facebook have done an excellent job explaining the steps right here.

Let's start with a new project. I'll call it panresponder-demo for simplicity sake and lack of a name that rhymes with unicorns.

$ react-native init panresponder_demo

First up, let's add an image to the project that will act as your drag and drop target.

Create a directory assets to the panresponder_demo folder and insert the image you want to use in there. If you don't have one, you can use this one.

Let's get our image on the screen so we can continue on to the cool part.

Open up index.ios.js and add the Image component at the top:

import React, {
  AppRegistry,
  Component,
  StyleSheet,
  Text,
  View,
  Image // we want to use an image
} from 'react-native';

Now replace the default app content with our Image so alter the render() method

render() {
  return (
    <View style={styles.container}>
      <Image source={require('./assets/panresponder.png')} />
    </View>
  );
}

When you run the app now you should see the image in the center of the screen, waiting for you to do something more exciting. So let's get to it.

![Panresponder 01](https://mindthecode.com/images/panresponder_01.png)

Adding the PanResponder

Let's get to the more interesting part. Adding the PanResponder system.

At the top, import PanResponder so we can use it. While we're at it, we'll also add Animated which allows us to use Animated values, which will come in handy for our animation and calculations.

import React, {
  AppRegistry,
  Component,
  StyleSheet,
  Text,
  View,
  Image, // we want to use an image
  PanResponder, // we want to bring in the PanResponder system
  Animated // we wil be using animated value
} from 'react-native';

PanResponder basically consists of a couple of event-driven methods that you can implement. Once you've defined what you want it to behave like you attach it to a view, which will then propagate all the events (gestures) to the methods you hooked up.

To illustrate it in a simple way, let's implement the componentWillMount() method and set up a basic PanResponder instance:

componentWillMount() {
  this._panResponder = PanResponder.create({
    onMoveShouldSetResponderCapture: () => true,
    onMoveShouldSetPanResponderCapture: () => true,

    onPanResponderGrant: (e, gestureState) => {
    },

    onPanResponderMove: Animated.event([
    ]),

    onPanResponderRelease: (e, {vx, vy}) => {
    }
  });
}

render() {
  return (
    <View style={styles.container}>
      <Animated.View {...this._panResponder.panHandlers}>
        <Image source={require('./assets/panresponder.png')} />
      </Animated.View>
    </View>
  );
}

Whoa, lots going on here. Let's break it down.

onMoveShouldSetResponderCapture tells the OS we want to allow movement of the view we'll attach this panresponder to. onMoveShouldSetPanResponderCapture does the same, but for dragging, which we want to be able to do.

Next up we got 3 methods that will be called onPanResponderGrant gets invoked when we got access to the movement of the element. This is a perfect spot to set some initial values.

onPanResponderMove gets invoked when we move the element, which we can use to calculate the next value for the object

onPanResponderRelease is invoked when we release the view. In a minute we'll use this to make the image animated back to its original position

Last up, we add the panresponder to an Animated.View which we use to wrap the Image component in so it will obey our panresponding demands.

Make it draggable

Let's implement the first 2 methods to be able to drag the image around the screen.

In order to keep track of where the image is on the screen we'll want to keep a record of its position somewhere. This is the perfect job for a components state, so let's add this:

constructor(props) {
  super(props);

  this.state = {
    pan: new Animated.ValueXY()
  };
}

Next, let's update the panHandler implementation:

componentWillMount() {
  this._panResponder = PanResponder.create({
    onMoveShouldSetResponderCapture: () => true,
    onMoveShouldSetPanResponderCapture: () => true,

    // Initially, set the value of x and y to 0 (the center of the screen)
    onPanResponderGrant: (e, gestureState) => {
      this.state.pan.setValue({x: 0, y: 0});
    },

    // When we drag/pan the object, set the delate to the states pan position
    onPanResponderMove: Animated.event([
      null, {dx: this.state.pan.x, dy: this.state.pan.y},
    ]),

    onPanResponderRelease: (e, {vx, vy}) => {
    }
  });
}

Basically, upon dragging we updat the states pan value, and when we move, we set the dx/dy to the value from the pan.

Now that we have our values, we can use this in our render() method, which gets called constantly as we're dragging, so we can calculate the position of our image in there:

render() {
  // Destructure the value of pan from the state
  let { pan } = this.state;

  // Calculate the x and y transform from the pan value
  let [translateX, translateY] = [pan.x, pan.y];

  // Calculate the transform property and set it as a value for our style which we add below to the Animated.View component
  let imageStyle = {transform: [{translateX}, {translateY}]};

  return (
    <View style={styles.container}>
      <Animated.View style={imageStyle} {...this._panResponder.panHandlers}>
        <Image source={require('./assets/panresponder.png')} />
      </Animated.View>
    </View>
  );
}

Getting there!

We're getting somewhere. When you run the app now you will be able to drag the image around the screen! However, when you do this for a second time you will notice it starts from the middle of the screen again instead of following up where you left it.

Let's fix that.

Fortunately, it's quite simple. We need to alter the initial value in onPanResponderGrant to take in account the correct offset (we dragged it off center):

onPanResponderGrant: (e, gestureState) => {
  // Set the initial value to the current state
  this.state.pan.setOffset({x: this.state.pan.x._value, y: this.state.pan.y._value});
  this.state.pan.setValue({x: 0, y: 0});
},

If you were to run the code again you will notice a second drag and drop works perfectly, but every time after that the image will jump erratically. This has to do with the way the offset is calculated. We actually need to flatten this once you let go of the image. This can be done in our 3rd and last method:

onPanResponderRelease: (e, {vx, vy}) => {
  // Flatten the offset to avoid erratic behavior
  this.state.pan.flattenOffset();
}

Scaling up and down

Last but not least, lets make the image change in size while we're dragging. First we'll add a scale property to our state so we can use this in our style and influence its value in the PanResponder

this.state = {
  pan: new Animated.ValueXY(),
  scale: new Animated.Value(1)
};

We'll use the value of this in our style inside the render method

...
let rotate = '0deg';

// Calculate the transform property and set it as a value for our style which we add below to the Animated.View component
let imageStyle = {transform: [{translateX}, {translateY}, {rotate}, {scale}]};
...

With this in place all that's left to do is influence the value of scale in the PanResponder implementation. When we start dragging the onPanResponderGrant method is invoked, so we can animate the value

onPanResponderGrant: (e, gestureState) => {
  // Set the initial value to the current state
  this.state.pan.setOffset({x: this.state.pan.x._value, y: this.state.pan.y._value});
  this.state.pan.setValue({x: 0, y: 0});
  Animated.spring(
    this.state.scale,
    { toValue: 1.1, friction: 3 }
  ).start();
},

and when we release it we'll animate it back

onPanResponderRelease: (e, {vx, vy}) => {
  // Flatten the offset to avoid erratic behavior
  this.state.pan.flattenOffset();
  Animated.spring(
    this.state.scale,
    { toValue: 1, friction: 3 }
  ).start();
}

Conclusion

And that's it! We got an image we can drag around, and it will give a visual indication we're doing so (besides following our finger).

The resulting code can be found here on Github, in case you didn't follow along or want to review it.

As always, should you have any questions you can find me on Twitter.

Happy coding!

Launching a webservice: Defining your MVP

Stef van den Ham — Tue, 14 Nov 2017 08:34:36 +0000

When you have an idea for a webservice it's easy to get lost into coding a lot of neat little features. But do you need all of them straight away? More often than not these features will cost you a lot of time to develop, while they might not even be the features your customer want.

Wikipedia says:

A Minimum Viable Product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.

But how do you decide which features make it into your Minimal Viable Product? As I'm (re-)launching a webservice at the moment I figured it would be good to use it as an example.

A little backstory.

For illustration purposes, I'll be using one of my own webservices and use it to go through the process of defining the MVP for it. I recently launched Wulfdeck.com, a service that cralws your website and finds all pages. It then takes them through the Google Pagespeed API and finds the pagespeed for each page. Once scanned you can see what needs to be improved to increase the score. As a bonus, it will tell you exactly how much your score will improve per individual improvement, so you don't waste time fixing things that are not be worth the time/tech investment.

At the moment it uses a Freemium model and a monthly Pro subscription. I've decided that marketing this SaaS will take too much of my time, let alone maintaining it for paying customers (which it doesn't have yet). So, I will be dropping the account system altogether and .. make the service free for everyone! In addition, it allows me to use it as a real life use case on this blog to illustrate various topics.

A win-win situation ðŸ¦„

Different types of MVP's

The internet will argue there's different kinds of MVP's. The most barebones variation is one where you have a landingpage and 'pretend' to have a product and then ask people to sign up by email to be informed once it launches. This way you can quickly validate whether it's even worth the actual work of building your SaaS before you write a single line of code for it.

Another version is where you already validated the idea, by talking to people, and want to get your functional product out there. This is the variation we will be discussing here.

Setting a goal

Every product should have a goal. What problem is your SaaS trying to solve? Ideally this is one line clearly stating what your webservice is all about. For our example, Wulfdeck, this could be the following:

Goal: Give user insight in the Pagespeed of all their pages, by entering their domain.

This goal leaves a lot of things unclear. How about things like:

Do users need to have an account?
Is the service free to use?
Do I get the results instantly or do I need to wait?
Do I get just a score, or information what to fix?

The first two are not all that important. They could change and are not directly related to the problem we're solving, so we don't need to mention this in our goal.

The last two are trickier. Instant results sounds directly related, but is it part of the problem we're solving? Maybe not. It could very be the user doesn't mind waiting for the results. Getting more information besides the score is actually quite important, otherwise we're just making the problem visible, not solvable, so let's add it to the goal:

Goal: Give users instructions on how to increase the overall pagespeed of their site by scanning all pages in the domain they enter.

That sounds better! We're stating what we offer, why we do it, and how we do it.

Define the User Journey

As a user goes through the app there are a few steps he/she will follow to get to the result. This is the User Journey and should be clear from the beginning. If you have too many different ways a user can use the app it will be difficult to build all flows correctly, and what's worse, it will most likely confuse the user.

What would a user journey for Wulfdeck look like.

Enter the domain
See list of pages we find
See instructions on how to increase the pagespeed score for that page

This may sound over-simplified. And it should be. If your user has to go through a lot of steps it's only logical there's more points in the flow the user will stop and not get to the result.

In our case we have actively chosen not to have a user registration system. If we did, however, should it be part of the user flow? It could be, but since the user will probably be logged in in order to use the actual product I personally don't think it should be part of the User Journey. If you think about a flow where the user can use the product, and afterwards can fill out their details to create an account, then you could say it is part of the user journey. Still, it sounds more like a feature than a step within our Goal.

So to summarize: we define all the steps the user will take to get to the desired 'result' and write them down. This will be your User Journey, and the base for the next step.

Features per page

If we think of the steps in our User Journey as pages in our webservice, we can then think of features (or pieces of functionality) each page could have. Let's see what we can come up with.

Enter the domain

Should be able to add domain with or without http(s):// and or www
Form should have validation

See list of pages

Page should show the google pagespeed score for mobile
Page should show the google pagespeed score for desktop
Page should show the url and title
Pages that are 404 should be marked as such
Pages should be updated in real time as they are crawled
Scores should be updated in realtime
Page should show a screenshot
Should be able to re-check a page for fresh Pagescore

See instructions on how to increase the pagespeed score per page

Should see a list of things that should be fixed
Should see how many points we gain for fixing an issue
Should be able to re-check a page for fresh Pagescore
Should see a screenshot
Show a visual HAR graph of page loading time
Offer download of optimized assets

At this point we have a bunch of features, and have to start prioritizing. Basically, for every feature, no matter how cool it sounds, we have to ask ourselves these four questions:

1: Is this feature directly related to solving the original Goal?
For the MVP we should really focus on features that solve the original problem. We can always add more features later.

2: How many users will use this feature
If a feature is only useful or interestig to a very specific user or usecase its overall usefulness is very low and we probably should not be building it at this stage.

3: How much work is building this feature
If a feature is a lot of work you have to consider if it's worth building it straight away. Maybe there's an easier way which isn't ideal, but increases your 'product to market' significantly. You can always add the ideal feature later.

4: Does it add enough value to the User Experience
Some features don't really relate to solving a problem but might be worth building after all. For instance, in our case we know the user will have to wait for both the crawling of the site and the pagespeed checks. Implementing 'real time updates' might be a good feature for the MVP in this case. But always consider question 3.

This doesn't mean you should throw all other features out of the window though! You should put them on your Roadmap so you can come back to them later. The focus for now is finding those features that are essential to our goal so we can launch.

If we look at our list above, the most 'feature fluff' is in the last step. Which makes sense, as that's where we display the end result of our page score results. The list of things we can offer the user there is potentially huge, so we have to make sure for our MVP we focus on what's most important for now.

I think the final MVP list for Wulfdeck features could look like this:

Enter the domain

Form should have validation

See list of pages

Page should show the google pagespeed score for mobile and desktop
Page should show the url and title
Scores should be updated in realtime

See instructions on how to increase the pagespeed score per page

Should see a list of things that should be fixed
Should see how many points we gain for fixing an issue

It definately feels weird to cut out all the extra features, and you might feel the app is not complete without them. However, don't forget we're building a Minimal Viable Product. We're focussing on getting something out there so real world users can play with the core and essentials. The sooner we can learn from our application out in the wild the better. Often you will find the features you added to the roadmap are not even the features your users are asking for. Good thing you didn't invest your time in building things people don't want! ðŸ˜‰

Feature creep

Having defined the MVP the most important next step is; AVOID FEATURE CREEP. As you're building your MVP it is not uncommon you think of a new exciting features for your application. This is a good thing, but also very dangerous. If you didn't think of it while defining the above list, it's most likely not that important, and can safely be added to the Roadmap.

Rounding up

( I originally posted this on https://mindthecode.com )
If you have any questions or would like to discuss, you can find me on Twitter at https://twitter.com/hyra :)

The best boilerplate app is the one you code yourself

Stef van den Ham — Wed, 08 Nov 2017 16:39:56 +0000

Boilerplate apps are great. They let you get your next project up and running quickly, and usually provide some form of structure you can follow.

They can also, however, be a massive time-sink. We developers are curious by nature, and tend to have this thing where we want to know exactly how things run under the hood 🙈 In addition, boilerplates can be too minimalistic for your needs, or too much bloat. This means you either spend time adding base-features, or scraping off the excess things you don't need.

This process is not a bad thing in itself, obviously, but it can easily lead to procrastination. Time you could probably better spend building that awesome feature, instead!

Should we use boilerplates?

YES! I'm not saying we shouldn't use boilerplates. Quite the opposite, actually. Building a project from scratch will most always be far more time consuming than using a boilerplate. The trick is using the right boilerplate for your project. I really believe the boilerplate you should be using is the one you code yourself. Creating your own boilerplate not only teaches you a ton about the technology you are using, it also leaves you with a piece of base-code you know inside out and can use to start working on that next project.

Of course you don't have to start from scratch with this. You can pick any existing boilerplate that almost works for you, and then customize it so it works perfectly for you. Or your team.

But not all projects are the same!

Agreed. Even more so, not every environment is the same. Or project team, for that matter. For instance, you might use a completely different stack when you are working on your pet side-projects than what you use at the office. Personally, I work with about 4 boilerplate apps, depending on the project, the people I work with and sometimes the constraints set by the client. For example, I have boilerplates for:

a Single Page VueJS App
an API only Express application
a Static Site Generator (Hexo) for blogs
etc.

The idea is that you standardize as much as possible, but don't constrain yourself too much. Sure, every project and situation is different, but starting every project from a base you are very familiar with makes sure you can get up and running quickly.

Keeping up to date

Ideally, you should keep your boilerplate apps up to date. Make sure to check your dependencies are up to date every now and then, check if it still works, and see if there's any upgrades you should be aware of. Over time you will know exactly what works, and what doesn't, so when that new library comes along you know exactly where to fit it in. But, don't do this religously, else we end up tinkering on Boilerplate apps rather than projects that will let you take over the world

It's all about that fine balance 🦄 ✨

As always, find my on @hyra at Twitter if you want to discuss!

Using Vue Components in your Express app

Stef van den Ham — Sun, 22 Oct 2017 11:53:24 +0000

VueJS is awesome. Creating self contained components and compose them together in your pages makes so much sense, and therefore I've been using it extensively in my latest projects. However, sometimes you want (or need) to create a traditional app, and can't use the SPA workflow development with hot reloading and .vue files.

Or can you? ðŸ¤”

TL;DR: I've prepared a repo with the full example code in case you want to dive right in at Github

Laravel already got Vue tightly integrated out-of-the-box, and you can actually register and use .vue components in your blade templates relatively easy. My weapon of choice is usually Express though, as I'm a Javascript fanboy ðŸ¤“. I set out to see if this is possible and spent 2 evenings trying to get the same working. With success! Below the steps to get this up and running for your next Express app as well.

Defining some goals

Before setting out to come up with a solution I had to define the goals I had in mind. I came up with the following:

Be able to write components using the .vue approach
Surely it's possible to write lengthy javascript and define components in one big file, but I want to use the .vue approach where <template>, <script> and <style> are combined in one file.
Use the components by puttin <custom-tag> in my view files
Registering and compiling is one thing, but being able to use them is another. I don't want to have to use Vue code to render the components explicity
Ability to use a pre-processor
I like writing my styles in the scss format, so this should be supported.
A simple build tool to compile
When developing SPA projects the build tools get rather verbose and complex. For the projects I want to use components in the build tool should be simple.
Bonus Feature: Hot Reloading
Spoiler alert: I didn't set out to have this as a requirement, but it works, and it's awesome.

Setting the stage

So let's get started. Obviously we will need a starting point. The easiest way to start a new Express app is by using its generator. Basically this will create an empty project that you can build off from. If you don't have it yet, here is how you get it installed:

npm install express-generator -g

Next we run the generator to create our project:

express --view=pug myapp

I use pug because I like the clean syntax. Though I know plenty people who hate it, so if you are one of them, just omit the --view parameter ðŸ˜‰

The generator will have created a folder myapp with an app which is pretty much ready to go, just go:

cd myapp
yarn install # or npm
yarn start

This will just install the dependencies and start the Express webserver. If all went well, browsing to http://localhost:3000 should give you the Welcome page of your new app.

Adding Vue

With the base set up, it's about time we add some Vue to the project. Let's pull in the Vue dependency first:

yarn add vue

Next, we need to create our entry Javascript file. We will eventually bundle all the referenced javascript code into one file, so this will be our main file. I created a file in public/javascripts/main.js. In there put the following:

var Vue = require('vue/dist/vue.js')

const app = new Vue({
  el: '#app'
})

Notice we pull in vue/dist/vue.js rather than just vue. This is because by default Vue includes the runtime-only build, which means we can't use templates like we want in .vue files.

We also mount our Vue app to an element with id app, so change the views/layout.pug to include that

doctype html
html
  head
    title= title
    link(rel='stylesheet', href='/stylesheets/style.css')
  body
+   #app
      block content

Create a build script

Now, to use our javascript we will need to bundle it and include it in our template. My usual choice is webpack, but configuring this is quite cumbersome and to be completely honest, I couldn't get it to work. For some reason it would incude the default vue version meaning we can't use .vue files, one of the main goals.

Luckily, there is a nice tool called Vueify which we can use to compile our javascript. As a bonus, it supports pre-processors such as SASS, Styuls and even template languages such as Pug. Win. It's a transform for Browserify, so we will need both.

Installing is simple:

yarn global add browserify # We want this global, to run is easily
yarn add vueify

Now we can do the compiling:

browserify -t vueify -e public/javascripts/main.js -o public/javascripts/bundle.js

This will, unsurprisingly, create a new file bundle.js with the compiled code. Let's not forget to include it in our layout:

doctype html
html
  head
    title= title
    link(rel='stylesheet', href='/stylesheets/style.css')
  body
    #app
      block content
+   script(src="/javascripts/bundle.js")

Writing a component

Next up is the part we've been waiting for .. an actual component! Let's add a file public/javascripts/components/cruelWorld.vue

<template>
    <div class="cruel">
        Cruel
        <span>{{ who }}</span>
    </div>
</template>

<script>
module.exports = { // This is important, I got errors when using `export default`
    data () {
        return {
            who: "World"
        }
    },
    mounted () {
        setTimeout(() => {
            console.log('We can use ES6 too!')
        }, 1000)
    }
}
</script>

<style scoped>
.cruel {
    color: green;
}
</style>

This is your basic Vue component. We have a simple template and some data, and it's mounted we log out a message after 1 second to show Arrow functions work as well.

Let's add it to our main.js so we can use it:

var Vue = require('vue/dist/vue.js')

Vue.component('cruelWorld', require('./components/cruelWorld.vue'));

const app = new Vue({
  el: '#app'
})

And compile it by running the command again:

browserify -t vueify -e public/javascripts/main.js -o public/javascripts/bundle.js

Include the component

Nice. So we got our setup, we got our component. Now let's use it. Open up views/index.pug and add the component:

extends layout

block content
  h1= title
+ cruel-world
  p Welcome to #{title}

Start the webserver:

yarn start

If all went well, you should be seeing our component alive and kicking!

Now, we can use pre-processors as well. For instance, we can add lang="scss" to our <style> tag to use SASS syntax:

<template>
    <div class="cruel">
        Cruel
        <span>{{ who }}</span>
    </div>
</template>

<script>
module.exports = {
    data () {
        return {
            who: "World"
        }
    },
    mounted () {
        setTimeout(() => {
            console.log('We can use ES6 too!')
        }, 1000)
    }
}
</script>

<style scoped lang="scss"> <!-- add this attribute -->
.cruel {
    color: green;
    span { <!-- nested scss syntax! -->
        color: orange;
    }
}
</style>

Before compiling this, we need to quickly add node-sass as dependency:

yarn add node-sass

Now, when you compile and run, you should see the SASS is being compiled correclty and your component has become more colourful.

This is great. We can write .vue components and then use them in our traditional app. We could stop here, but let's add one more feature ..

Bonus: Hot Reloading

This is just the icing on the cake. Being able to update our components and see the results straight away in our browser.

Open up your package.json and add the following dev script to the scripts section:

"scripts": {
  "start": "node ./bin/www",
  "dev": "watchify -vd -p browserify-hmr -t vueify -e public/javascripts/main.js -o public/javascripts/bundle.js & node ./bin/www" 
  },

This script looks daunting but is quite simple. Basically it uses watchify to watch for code changes, and proxies the result of vueify through browserify-hmr (hot module reloading) to our page. Awesome.

Don't forget to install the dependencies this relies on:

yarn add watchify
yarn add browserify-hmr

Now when you start the server ..

yarn dev

It will compile our javascript and watch for changes. Try it out, make a change to cruelWorld.vue and see the change automagically in the browser!

Conclusion

I'm glad I could get this working. Sometimes it doesn't make sense to go all out with a single page app. Having the ability to still use the Vue Components in your traditional project is just gold.

If you want to see the full source code of the above, I've prepared a repository at Github which you can use as a reference or starting point.

Hope the above helps!

If you have any questions, you can find me on https://twitter.com/hyra