This is part of a series explaining how to use VueJS to create a transplation-free client-side templating architecture. I'm not claiming this is The Best Way to create a UI, but it's a good thought experiment for minimizing ceremony.

• Part 1: VueJS introduction -- Progressive, observables, loops, & ifs
• Part 2: Components, Templates Types, and SPAs (unedited)
• Part 3: Using Render Functions & HTML Files (to come)

NOTE: I haven't reread/edited this one yet, I'm afraid. Bbl.

In Part 1, we had all the tools we absolutely required to make a single page app (SPA) with VueJS, but the HTML was a mess. Worse, if it got any more complicated and the different "views" shared any UI, we could tell it'd quickly stop being DRY.

The solution to this problem is to employ reusable components. Here's a quick visual from the "Intro to VueJS" video from Vue's home page.

Concentrate mostly on the stuff in the middle... we might want to use that Product Image component in a few different places, for instance. With components, we can define it once, and then reuse all over the place.

Now there are a number of different ways to create components, but, honestly, only a few that really make sense in a practical work environment. The first that we're going to review -- and the one most sites, including Vue's own documentaions start with -- really doesn't make great sense: inline text. But let's do it anyway for kicks. The reason will make more sense later...

Let's take that "cats" markup from Part 1 and componentize it.

Old markup:

<!-- ==== FROM HERE ==== -->
<div v-if="activeUi === 'cats'">
    <h3>Cats</h3>
    <ul>
        <li v-for="cat in cats">
            {{ cat }}
        </li>
    </ul>
</div>
<!-- ===== TO HERE ===== -->

<div v-else-if="activeUi === 'dogs'">
    <h3>Dogs</h3>
    <ol>
        <li v-for="dog in dogs">
            {{ dog }}
        </li>
    </ol>
</div>

<div v-else>
    <h3>Neither dogs nor cats</h3>
    <ul>
        <li v-for="x in others">
            {{x.name}}, a {{x.type}}

            <!-- And note that we can embed ad infinitum, natch -->
            <ul v-if="x.type === 'rooster'">
                <li>"That's a joke, I say, that's a joke son!"</li>
            </ul>
        </li>
    </ul>
</div>

Vue's component model is pretty conventional, and awfully familiar if you've used React. Here, there's no real business logic. We just need to get that the cats data into the component and then loop over it. And we do that with props, which is just a fancy way of saying properties that we bind in the component's declaration in our HTML.

Here the above cats-specific markup as a component. I've got it in a new file marked components.js so that it's not mixing with my core business logic, but you can drop it anywhere you want, as long as it's executed before your main Vue app instantiation. Recall that I've got my main Vue call in a document.addEventListener("DOMContentLoaded", function() {...}); wrapper, so it's not going until the rest of the page is read and rendered.

/*global Vue, window */
(function () {
    "use strict";

    Vue.component("cats", {
        props: ['store'],
        template: '<div><h3>Cats</h3><ul><li v-for="cat in store">{{ cat }}</li></ul></div>'
    });
}());

And here's how the HTML changes:

NOTE: Check the : before store, which tells us to bind the object represented by "cats" rather than treating it as a literal string.

<!-- ==== FROM HERE ==== -->
<cats v-if="activeUi === 'cats'" :store="cats"></cats>
<!-- ===== TO HERE ===== -->

<div v-else-if="activeUi === 'dogs'">
    <h3>Dogs</h3>

    <!-- ... and so forth... ->

That's certainly a lot cleaner, right? If we componentize it all, making similar dogs and others components, we exchange all the markup from the first code dump, above, to this:

<cats v-if="activeUi === 'cats'" :store="cats"></cats>
<dogs v-else-if="activeUi === 'dogs'" :store="dogs"></dogs>
<others v-else :store="others"></others>

A few things to note:

1. Our HTML looks great. No clutter. If we want to see what happens with cats, we know to look at that specific component.
2. The template string can include Vue markup. You see {{ cat }} there. So that's cool -- we can get as nesty as we want.
3. The template string is okayish for the small markup we have, but boy, that'd be messy for lots of markup. It's not even easy to read as it stands!

I bet we can do better, right? Let's see if there's a way to keep the HTML in its own file, where we're not worried about newlines or surrounding values in single quotes, and escaping single quotes in the template, and...

Pros and Cons for VueJS Template Types

There's a decent intro to the different ways you can create templates for components in Vue here on medium from Anthony Gore. Let's run through them and list some pros and cons.

1. String
2. Template literal
3. X-Templates
4. Inline
5. Render functions
6. JSX
7. Single page components

1. String

The first is what we just did. template is literally a string. As Gore says, "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." It's really not scalable, and heaven help anyone debugging or editing a large HTML value within quotes.

2. Template Literals

The second is to use es6's "template literals". This is a new syntax which allows us to define multiline strings using backticks instead of quotes to delimit strings. That's great, and would improve our cats component definition quite a bit...

Vue.component("cats", {
    props: ['store'],
    template: `
<div>
    <h3>Cats</h3>
    <ul>
        <li v-for="cat in store">{{ cat }}</li>
    </ul>
</div>`});

That's a big step up, but it's not IE happy at all. For me, at least, that's still an issue. There's also spotty escape sequence support, so it's not really HTML ready. And strangely, they don't have any compatibility right now (20180411) for Safari on iOS. ??

3. X-Templates (script tags)

X-Templates are when you use the trick that you can drop HTML into a script tag with an id and then link to it from your component definition. This allows you to embed all your components' html into a single file if you wanted, which is an improvement.

<script type="text/x-template" id="dogs-template">
    <div>
        <h3>Dogs</h3>
        <ol>
            <li v-for="dog in store">
                {{ dog }}
            </li>
        </ol>
    </div>
</script>

That, of course, can go anywhere you want in your html, or in a script include. This isn't an end of the world, and is actually how we used to do templates in KnockoutJS. The only thing I hate is that it feels a little kludge and that it's harder to get your editor set up to highlight the HTML code as HTML inside of script tags.

The component is very clean, however.

Vue.component("dogs", {
    props: ['store'],
    template: "#dogs-template"
});

4. Inline templates :^P<######

Inline templates are a horrible idea, and I can't even find a place on Vue's website that claims it's supported. I'm not saying it's not supported. I'm saying it's a horrible idea. Inline templating is when you put the template between the component's tags in your "parent" markup. Here's Gore's example:

<my-checkbox inline-template>
  <div class="checkbox-wrapper" @click="check">
    <div :class="{ checkbox: true, checked: checked }"></div>
    <div class="title"></div>
  </div>
</my-checkbox>

OMGWTFBBQ! The whole purpose of components is that you can then reuse them with minimal overhead. Now I get it -- perhaps there are times when you want different markup for each use of the component. Maybe. But if something's ever duplicated, you're stuck cut and pasting markup, and you've lost your DRYness. Yuck.

5. Render Function: Spoilers

I'm going to come back to render functions. *wink wink wink*

6. JSX & 7. Single file components.

The final two involve transpilation. You can use JSX in Vue if you want, just like you're back in React-land. Insert Kerriganian "WHY?!!?!"

The second is actually what you probably came to Vue for in the first place, single file components. I really do like the idea of single file components. They contain the template, javascript, and, get this, scoped CSS all in the same file. It sounds wonderful.

Here's why it's not, from vuejs.org:

For Users New to Module Build Systems in JavaScript

With .vue components, we’re entering the realm of advanced JavaScript applications. That means learning to use a few additional tools if you haven’t already:

• Node Package Manager (NPM): Read the Getting Started guide through section 10: Uninstalling global packages.

• Modern JavaScript with ES2015/16: Read through Babel’s Learn ES2015 guide. You don’t have to memorize every feature right now, but keep this page as a reference you can come back to.

After you’ve taken a day to dive into these resources, we recommend checking out the webpack template. Follow the instructions and you should have a Vue project with .vuecomponents, ES2015, and hot-reloading in no time!

To learn more about Webpack itself, check out their official docs and Webpack Academy. In Webpack, each file can be transformed by a “loader” before being included in the bundle, and Vue offers the vue-loader plugin to translate single-file (.vue) components.

NOTE: Either of these involve the gateway drug to that horrible cesspool of build scripts and maintenance that I'm trying to avoid for you. It's also a, well, JavaScript builds are not exactly a broken window; they're more like a stained glass window. Once you have a single piece of stained glass, someone on the team is going to add eighteen more build steps^H^H^H^H^H^H pieces of stained glass, and suddenly you have a priceless stained glass window that looks like a snowflake, if you get my [wait for it...] drift.

Again, this is how everyone does JavaScript development these days, but I'd warn you against it. At the very least, let's see how bad things get if we avoid transpiliation, if just as a thought experiment. The series is called "Templating without Transpilation", after all.

Tune in next time in Part 3, when we finally get where we're going, using, you guessed, it, render functions, and have a solid architecture that allows templating without transpilation.

Labels: howto, javascript, transpilation, VueJS

This is part of a series explaining how to use VueJS to create a transplation-free client-side templating architecture. I'm not claiming this is The Best Way to create a UI, but it's a good thought experiment for minimizing ceremony.

• Part 1: VueJS introduction -- Progressive, observables, loops, & ifs
• Part 2: Components, Templates Types, and SPAs (unedited)
• Part 3: Using Render Functions & HTML Files (to come)

I heard about VueJS a while back on from Shawn Wildermuth guesting on Yet Another Podcast, and figured I'd take a look. The most interesting thing about it was its claim to be a "progressive framework"...

From vuejs.org:

Vue (pronounced /vjuː/, like view) is a progressive framework for building user interfaces. Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is easy to pick up and integrate with other libraries or existing projects. On the other hand, Vue is also perfectly capable of powering sophisticated Single-Page Applications when used in combination with modern tooling and supporting libraries.

Incremental adoption, you say? As in, I could use its templating without any other libraries? RLY? I mean, Vue bills itself to be a pretty mature lib. Heck, you can go full-bore, Babel and JSX with VueJS if you want to. That marks a sort of max progression. Can we find a similarly minimally progressive stack?

Once burned...

Last year, I spent most of my time working on a system that used React, JSX, and MobX using Babel for transpilation. It wasn't a horrible client-side stack, but I've never wasted so much time on build systems since I was new to ant. We updated and debugged with each new release of anything of those three, and it drove me crazy with what Shawn Wildermuth calls the "ceremony" of coding -- all the magic incantations and rituals you have to go through and maintain before working code comes out.

Using transpilation and riding the bleeding edge instead of writing deployable code means everything you do costs you -- let's say -- an extra 10%, and, in the wrong hands, more. Do you really get that time back with transpilation?

Just because everyone else is putting together complex JavaScript build processes (and they are. Projects that don't include "the dev who maintains the build" are becoming few and far between, and that dev is always front and center on interview calls pretending their role is absolutely critical to a project's success), do we have to go full Cranberries? (pro tip: see album title, young'uns)

I don't think so. I'm not against transpilation, if it's well managed. But if I can use a library that doesn't require transpilation, but can still give me a good templating system, I'm curious. Just for fun, let's see if VueJS can keep us transpilation-free.

How progressive is VueJS, exactly?

NOTE: If you already know Vue, stay with me. Skim the balance of this so you know where I'm coming from, and then stop at the end, where I start talking about what's missing. Then tune in next time, for Part 2, where I fill in what's missing & seal the deal.

Let's take the minimal VueJS setup as described in their introductory guide, where we assume zero libraries other than Vue are present.

What's below is the minimal Vue setup from their guide, with just enough changed so that we...

1. Have something that'll work in a live example
2. Include a form element to test our binding
3. Have a button to access our data programmatically (standing in for a call back to the server)
4. Wait until the DOM has loaded before initializing to begin templating
   • If we were using true Vue templates, we wouldn't have to do this. More on that in Part 2.
5. Some gymnastics to pass JSLint.

Excuse the last. It's an unshakeable addiction.

^{(That said, you should use JSLint too. ;^D)}

/*global Vue, window */
document.addEventListener("DOMContentLoaded", function() {
    "use strict";
    window.app = new Vue({
        el: '#app',
        data: {
            message: 'Hello Vue!'
        },
        methods: {
            report: function () {
                // Note that it's app.property, not app.data.property
                console.log(JSON.stringify(window.app.message, null, "    "));
            }
        }
    });
});

And the HTML needed to match is super simple.

<html>
    <head>
        <title>Look how simple</title>

        <script src="../vue.js"></script>
        <script src="./app.js"></script>
    </head>
    <body>
        <div id="app">
            {{ message }}<br />

            <input
                type="text"
                v-model="message"
            /><br />

            <button
                type="button"
                v-on:click.prevent="report"
            >Add new</button>
        </div>
    </body>
</html>

And poof! We've got an interactive, VueJS-templated web page.

That's... great. Right?

Vue does observables right

Actually, it is great, kinda. data is just a datastore. Vue wraps it in observable overhead, so in many ways, it reminds me, at this level, of KnockoutJS. It's advantage? That we're not wasting time dealing with any of that overhead ourselves, in code or our mental model. Knockout had this horrible convention where you had to call a function to get a "raw" observable, which often threw people for loops).

Vue beats out KnockoutJS easily here. You can very simply put in properties to serve as hooks in your data object to hang all of your datastores, and when you set them, they iterate through your object models and make everything an observable too. If you set message, above, to some giant json model, all of that model would be observable. And each property would be accessible in plain old javascript object ("POJsO") notation.

/*global Vue, window */
document.addEventListener("DOMContentLoaded", function() {
    "use strict";
    window.app = new Vue({
        el: '#app',
        data: {
            payload: {
                b: { c: 2 }
            }
        },
        methods: {
            report: function () {
                // Note that it's app.property, not app.data.property
                console.log(JSON.stringify(payload.b.c, null, "    "));
            }
        }
    });

    // Pretend some event caused this.
    window.app.payload = {
        a: 1,
        b: {
            a:"a",
            b:"b",
            c:"c"
        },
        c: 2
    };
});

And then a quick change to our html...

<div id="app">
    {{ payload.b.c }}
</div>

That, I like. That's how you should do observables. It's the same mental model as a plain ole JavaScript object. There's no "oops, that's an observable! Remember to treat it like a function!" overhead. It's simply magic.

Okay, okay, I haven't looked, but it's almost certainly some getter and setter overhead, which works like magic here. That's why it's important to note that window.app.data is inaccessible. What we don't want to do is blow up our observable chain.

How not to observe...

NOTE: The follow-on from that is that you can't do this:

window.app.payload.d = "spam" and expect spam to be observable. You have to set something that's already an observable, or the extra setter logic won't fire. That just makes sense.

But you can pick up the observable train wherever you want...

NOTE: You really shouldn't be updating your data object's object model for the most part, however. That's a code smell, imo. You'll be getting nice large JSON payloads from your server, and you might have some navigation and convenience objects for managing views, but that's about it. If you make changes to data, that should be going back to the server. And if you're changing the data model on the client, that's probably a business rule that should've been handled on your server-side, not the client-side, where your interest should be almost exclusively presenting views.

Keep your interests separated.

Moving towards an SPA

There are really only two more things you need to know to get pretty close to making minimalistic single page apps (SPAs) with VueJS: conditionals and loops.

Loops with v-for

Loops are easy. If you have an array of objects in your datastore, you can loop through them easily with v-for, repeating the markup within that marked node as many times as you have objects.

So if you had data = { stooges: ["Larry", "Moe", "Curly", "Shemp"] }, your markup would be something similar to:

<div id="app">
    <ul>
        <li v-for="stooge in stooges">
            {{ stooge }}
        </li>
    </ul>
</div>

Easy. And if your stooges were objects instead of strings, that's done just like you'd expect, thanks to the POJsO setup Vue supports.

data = { 
    stooges: [
        { name: "Larry", desc: "the curly-headed one." },
        { name: "Moe",   desc: "the relatively smart one." },
        { name: "Curly", desc: "the bald one. See what they did there, with Larry having the curly hair?" },
        { name: "Shemp", desc: "the one nobody knew in the 70s, but somehow everyone did starting around 1990." }
    ]
};

And change the markup to match:

<div id="app">
    <ul>
        <li v-for="stooge in stooges">
            {{ stooge.name }} is {{ stooge.desc }}
        </li>
    </ul>
</div>

Conditionals with v-if

Now let's look at conditionals. If you only want something to be rendered when some condition is true, you plant that portion of your markup in a conditional.

 <html>
    <head>
        <title>Animal types and examples</title>

        <script src="../vue.js"></script>
        <script src="./app.js"></script>
    </head>
    <body>
        <div id="app">

            Display all animals of type: <input
                type="text"
                v-model="activeUi"
            /><br />

            <div v-if="activeUi === 'cats'">
                <h3>Cats</h3>
                <ul>
                    <li v-for="cat in cats">
                        {{ cat }}
                    </li>
                </ul>
            </div>

            <div v-else-if="activeUi === 'dogs'">
                <h3>Dogs</h3>
                <ol>
                    <li v-for="dog in dogs">
                        {{ dog }}
                    </li>
                </ol>
            </div>

            <div v-else>
                <h3>Neither dogs nor cats</h3>
                <ul>
                    <li v-for="x in others">
                        {{x.name}}, a {{x.type}}

                        <!-- And note that we can embed ad infinitum, natch -->
                        <ul v-if="x.type === 'rooster'">
                            <li>"That's a joke, I say, that's a joke son!"</li>
                        </ul>
                    </li>
                </ul>
            </div>

        </div>
    </body>
</html>

You're half-way there. To an SPA, that is.

If you use conditionals with reckless aplomb, you could force your way to a complete SPA. No, really, you're done. You could have every portion of your app in some div marked with the proper conditional, and have everything appear iff it's supposed to.

There're just two problems. At some point, it's going to be very difficult to keep this DRY. You will eventually want to use the same markup (HTML) and business logic (JavaScript) in two places that are each embedded deep within some other portion of HTML.

And, well, that's HTML is already a mess. It's sprawling and difficult to grok quickly, which means it'll be difficult to maintain.

Wouldn't it be nice if we could cut that previous html down with some custom components, like this?

 <html>
    <head>
        <title>Animal types and examples</title>

        <script src="../vue.js"></script>
        <script src="../components.js"></script>
        <script src="./app.js"></script>
    </head>
    <body>
        <div id="app">

            Display all animals of type: <input
                type="text"
                v-model="activeUi"
            /><br />

            <cats store="cats" v-if="activeUi === 'cats'" />
            <dogs store="dogs" v-else-if="activeUi === 'dogs'" />
            <other store="others" v-else />

        </div>
    </body>
</html>

... and to do it without transpilation?

We can. And we will. In Part 2.

Labels: howto, javascript, transpilation, VueJS