Forem: Ronnie Villarini

What Neovim taught me about myself

Ronnie Villarini — Mon, 08 Apr 2024 00:00:00 +0000

Before we get started, I'm going to say "Vim" a lot in this article. My experience has actually been with Neovim, but most, if not all, of what I have to say here will be applicable to either.

So I've been using Neovim for roughly a month now and it has been quite the experience. I've had several moments of almost giving up, I've learned a lot about what makes this tool so special, and, surprisingly, I've learned a lot about myself in the process. I'll get to that towards the end of the post, as it's perhaps a little more philosophical and maybe not what most people will be interested in.

The Learning Curve

Everyone has heard about how hard Vim is to learn. The "I can't exit Vim" meme has probably been tired out at this point, and it's true, it is pretty difficult. What only those who seem to get through that learning curve talk about though, is how worth it is. I had heard this a handful of times throughout my career from the few Vim users I encountered, but I never really took it seriously. I do believe that keyboard shortcuts are something everyone should learn, but I didn't really think it would go much further than that.

I was wrong. I was so, so wrong.

Vim Motions

This is the first thing that you'll really learn if you embark on this journey, and it's arguably where the biggest benefit is. The ability to do so much without ever leaving home row is incredible. As I said before, I've always been a fan of keyboard shortcuts, but Vim takes that to another level. Navigating code without moving my hand awkwardly to the arrow keys (or holding down a modifier key to access the layer where my arrows live on my ZSA Voyager), using w, b, or e to flow through words, f or t to jump to (or just before) a specific character... the list goes on. It really is not only more efficient, but also just so much more enjoyable.

Note: Efficiency does not always mean speed. You may very well be fast with your mouse or however you navigate your code, but it's undeniable that hitting e to go to the end of a word is just more efficient than holding down option/alt and tapping the right arrow key.

These motions are just the tip of the iceberg, really. There are so many more and I'm still not quite to the point where I never have to think about it, but I am to the point where it's comfortable and navigating in other programs feels clunky and difficult. Honestly, once you get comfortable with the Vim motions, you could probably just stop here. There are Vim modes or plugins in almost any other editing software that will allow you to use them and, like I said before, this is largely the biggest benefit.

Enjoyment

It's weird to title a section "enjoyment" a few paragraphs after talking about just how difficult or frustrating learning Vim can be. It's true though, it's an absolute blast. In fact, I'd go so far as to say that learning Vim has sparked my love for code again, something that I have really lost over the last year or so while battling chronic feelings of disinterest. Learning Vim was so much fun that I found myself somewhat addicted to it. I watched countless videos, read articles, spent time playing vim adventures, and just found myself fully immersed. Not only was I enjoying the process, but I was also enjoying the dopamine hit of learning and seeing evidence of my improvement as I went from stumbling through the most basic of motions to (seemingly) flying through my code at work.

What I learned about myself

This section is going to be very specific to me, my experience, and my own personal growth. If you're not interested in that, feel free to stop here. I really hope you give Vim a shot though, and if you do, please let me know how it goes for you!

So, before I speak about what I learned about myself, I want to share how I even got started on this path.

A former manager, mentor, and now good friend of mine whom you may know as Dreams of Code, absolutely blew me away when I used to pair with him. When I started to grow interested in learning, I had a few conversations with him about it and he suggested Vim Adventures. I played through the first few levels, but it wasn't really clicking for me. I was mildly interested at best. I did change the arrow keys on my keyboard to be on a layer under h,j,k,l as opposed to the i,j,k,l that I had been using, but that was about as far as I got for several months after.

Fast forward to Zed going open source, and I grew interested. A new editor by the folks who originally made Atom sounded cool, but also, so did something new. I had been using VS Code since I started as a dev, and other than changing my color scheme here and there, I hadn't really tried to branch out. When I launched Zed for the first time, I noticed the welcome screen had a checkbox for enabling Vim mode. That's cool, I thought, Vim mode out of the box? Sure, I'll give it a shot. So I took this as an opportunity to not only try out a new editor, but also learn Vim motions.

This actually went surprisingly well. I also watched a course on Zero to Mastery that went into more depth on not only the motions, but also taught me advanced motions and how things like registers and marks worked. Unfortunately, I was frequently running into problems in Zed where certain things (marks, for example) weren't supported in Zed. The course was being taught using the Vim plugin for VS Code, so I decided to move back over to VSC while continuing through the course.

This was where I had my first internal struggle. At some point I thought, this is kind of silly. Why am I using a plugin to emulate Vim when the whole point was to get away from VSC. I had also found ways to get around some of my issues in Zed, but why do that when I was still just using a crippled version of Vim? So I decided to switch over to Neovim.

Note: I'm not in the slightest implying that there is anything wrong with VSC or Zed. I still think VSC is great, and I'm still very closely following Zed as I'm still very interested in it's direction. I was just having so much fun, and as I've said before, following your curiosity is so important for growth.

LazyVim

At the end of the above mentioned course, there was a section on Neovim, and in that section the instructor walks through the process of installing LazyVim. This seemed great! A fully-functioning IDE in Neovim, right out of the box? Fantastic.

In my case, this couldn't have been further from the truth. In fact, this was the first time I almost gave up on vim all together. LazyVim is actually great. It has so many useful plugins, lots of great defaults, and it saves you lots of time on configuring Neovim. For me though, it was so incredibly overwhelming. There was just so much, and if I wanted to change something, I was totally lost on where to go to change it. I think LazyVim actually does a good job of documenting things, but as my first experience with Neovim, a lot of it just simply didn't make sense to me.

Kickstart

So I backed out and moved back to going back and forth between Zed and VSC for a week or so. Then I remembered I had seen a video by TJ on Kickstart, a more minimal launch point for your Neovim config. This resonated more with me and how I learn.

You see, I like taking things a little slower. I do enjoy jumping in, getting my hands dirty, and learning by doing, rather than by watching/reading. However, I do think there is a line to how uncomfortable I can be before it just becomes too much. Kickstart was the perfect balance and was exactly what I was looking for. It provides some sensible defaults for various options and keymaps, some basic plugins, and the best part? It's all in a single, well-documented file. Combine this with the video linked above, and I quickly felt like I could get up to speed. Within a day or two, I had an editor that I felt comfortable enough with to actually use all day for work.

The Second Time I Almost Gave Up

Things seemed to be going pretty well for a day or two, but I didn't quite have my Vue tooling set up properly. I spend most of my day working in Vue, and without getting this set up properly, I knew it was only going to be a matter of time before I was back in VSC with all the tooling that I had come to appreciate.

So I started trying to get it set up. I started with some googling, which lead to reading various forms of documentation. Here is where the problems started. Vue's official docs point to a repo that shows how to install the recommended tooling via something I had never heard of called coc-nvim. After talking with Dreams of Code, it sounded like that was something I should avoid as it was an older way of dealing with LSPs.

Wait, LSPs. I've heard that before.. right?

Yes, I had. In TJ's video I linked above and also in the documentation in the init.lua file for Kickstart. Both were just so information dense, that I forgot a lot of the information that wasn't immediately relevant.

So I kept looking and eventually found the documentation for how to set up Volar in combination with TS Server. I got this set up and it seemed to be working! I was seeing the same functionality (for the most part. The core functionality I felt was necessary at least.) that I had in VSC, and I thought everything was good to go. Well. Not Quite.

I guess while setting this all up, browsing various files and doing basic testing, I had neglected to save any of the files I was doing my testing in. The next day, when I performed my first code change, I hit save and... everything disappeared. My entire file. All the code was replaced with blank lines, and my only option was to q! out of Neovim, and perform a git checkout on the file I had edited to recover the code. This issue was particularly annoying because I tried to just simply undo everything by hitting u, but then every time I saved, it would happen again. Meaning there was no way for me to save the file without losing everything and being forced to reset the file with Git.

The more experienced Vim users will know what's going on here, and will have by no doubt figured out that I could actually save without this issue. We're getting there. Settle down.

Some frustration, mild panic, and a few minutes (hours) of frantic googling later - I found my problem on a GitHub issue. I had assumed that this was related to my config, as commenting out my Volar and TS Server setup in my init.lua prevented this from happening. Unfortunately, I just didn't really understand why. Turns out, it was a bug related to TS Server and the format on save action.

I fixed my issue, and was able to finish my workday without more hiccups, but at this point I was beginning to question everything. Why was I bothering to learn Vim. I had learned the motions, but I was also very competent with VS Code's keybindings and was still very fast ... just not as efficient. Did it matter? Did I ever even stop to ask myself why I was doing this? Did I really want to move to a tool that was going to end up requiring this level of frustration?

Difficulty Is Fun

This is it. This was the thing that Neovim really taught me about myself. Yeah, it taught me that learning you tools is important. It taught me that stopping to question whether or not you really need all those extensions or whether all those different buttons, icons, and notifications in my editor were even important.

More than anything, it made me reflect. When I almost gave up because things were hard, I spent a couple days not only feeling bummed out, but also thinking about what went wrong. I mean, this shouldn't be that surprising right? It's a large portion of why so many of us like to code. We like solving problems. So I came back. Why? Because I like to do difficult things.

I get the most enjoyment out of competitive or difficult video games like League of Legends and Dark souls. I get more enjoyment out of doing things "the hard way" frequently, just because it's more engaging. No, I don't always. I'm not out here mowing my lawn with scissors, but I do find more difficult activities to be more engaging and ✨rewarding✨.

So, at least for now, I'm going to continue using Neovim. I haven't run into any other issues since that day, either. Maybe something like that will happen again, but I really think that the "I lost x amount of time on my Neovim config" comments are largely self-induced. I really think that, just like all software, you may encounter bugs, but you don't have to "lose" a bunch of time fiddling with your config if you don't want to. I've spent another handful of hours, but it's largely been because I've added a few more plugins here and there, messed with my keymaps, or I've just simply spent some time going over everything to make sure I really understand my config.

At the end of the day, that's what it really is. Yours. That's what makes Neovim special.

Until next time. Cya nerds. 👋

Build A Dark Theme Toggle With The Composition API

Ronnie Villarini — Mon, 17 Aug 2020 16:52:14 +0000

This post first appeared on my personal blog. Make sure you check it out to view this functionality live, and stay for the extra content (:

I recently built a theme toggle for my personal site because, well, everything has a dark theme these days right?
I've spent a lot of time with the composition api recently and after starting to impliment this with the options api,
it became pretty obvious how much code readability would improve by using the composition api and abstracting the functionality
to a separte file.

Important note here: I am using the vue-compositon-api-plugin because I am adding this functionality to my gridsome site which is still using Vue 2.x.

Composables

I'm going to start by creating a composables folder in my src directory. This is totally optional, but I assume this is going
to become the best-practice when it comes to drectory structore and code organization. I'm naming the folder composables because
these function abstractions are called composition functions.

useTheme.js

Now inside the composables directory, I'm going to create a new file, useTheme.js. useX is also a future best practice, and
is the encouraged way to name your composition functions.

It is a recommended convention to start the function's name with use to indicate that it is a composition function.

Inside useTheme I'm going to add some boiler plate:

import { ref } from '@vue/composition-api';

export default function useTheme() {
    const currentTheme = ref('light');

    function toggleTheme() {
        // @TODO
    }

    return {
        toggleTheme,
    };
}

Key things to note here:

I'm importing ref from @vue/composition-api. In a normal Vue 3 application this would just be vue, but I'm using the composition api in a Vue 2 app with a plugin.
I'm initializing a ref called currentTheme, which is being initialized with a default value of light. This will be the default theme when a user visits.
I'm returning currentThem and the function toggleTheme from the use function. This is important to how this all works and I'll explain in more detail later.

Toggling a theme

Now I'll impliment the toggle theme function:

import { ref } from '@vue/composition-api';

export default function useTheme() {
    const currentTheme = ref('light');

    function toggleTheme() {
        if (currentTheme.value === 'dark') {
            setLightTheme();
        } else {
            setDarkTheme();
        }
    }

    return {
        currentTheme,
        toggleTheme,
    };
}

...That's it!

wtf?! 😒 - you, probably

Dad jokes aside, lets impliment those two theme functions!

function setLightTheme() {
    currentTheme.value = 'light';

    document.documentElement.style.setProperty('--primary', 'var(--purple)');
    document.documentElement.style.setProperty('--background', 'var(--bg--light)');
    document.documentElement.style.setProperty('--text', 'var(--text--light');
    document.documentElement.style.setProperty('--link-text', 'var(--link-text--light');
    document.documentElement.style.setProperty(
        '--active-link-text',
        'var(--active-link-text--light'
    );
    document.documentElement.style.setProperty('--shadow', 'var(--shadow--light');
    document.documentElement.style.setProperty('--quote-bg', 'var(--quote-bg--light');

    process.isClient && localStorage.setItem('theme', 'light');
}

function setDarkTheme() {
    currentTheme.value = 'dark';

    document.documentElement.style.setProperty('--primary', 'var(--teal)');
    document.documentElement.style.setProperty('--background', 'var(--bg--dark)');
    document.documentElement.style.setProperty('--text', 'var(--text--dark');
    document.documentElement.style.setProperty('--link-text', 'var(--link-text--dark');
    document.documentElement.style.setProperty(
        '--active-link-text',
        'var(--active-link-text--dark'
    );
    document.documentElement.style.setProperty('--shadow', 'var(--shadow--dark');
    document.documentElement.style.setProperty('--quote-bg', 'var(--quote-bg--dark');

    process.isClient && localStorage.setItem('theme', 'dark');
}

The accompanying styles:

/* variables */
:root {
    --purple: #6200ee;
    --purple-dark: #400088;
    --teal: #04dac6;

    --primary: var(--purple);
    --primary-light: hsl(265, 70%, 95%);
    --primary-dark: #5d3991;
    --secondary: #04dac6;
    --white: #fafafa;
    --off-white: #ffffffcc;
    --black: #1a1a1a;
    --darker-grey: #333;
    --dark-grey: #4e4c4c;
    --grey: #718096;
    --gray-light: #718096;

    /* Dark Theme */
    --bg--dark: #000c1d;
    --text--dark: var(--off-white);
    --link-text--dark: var(--off-white);
    --active-link-text--dark: var(--secondary);
    --shadow--dark: #121212;
    --project-border--light: var(--primary);
    --quote-bg--dark: rgb(2, 55, 81);

    /* Light Theme */
    --bg--light: var(--white);
    --text--light: var(--darker-grey);
    --link-text--light: var(--dark-grey);
    --active-link-text--light: var(--primary);
    --shadow--light: var(--grey);
    --project-border--light: transparent;
    --quote-bg--light: var(--primary-light);

    --background: var(--bg--light);
    --text: var(--text--light);
    --link-text: var(--link-text--light);
    --active-link-text: var(--primary);
    --shadow: var(--shadow--light);
    --project-border: var(--project-border--light);
    --quote-bg: var(--quote-bg--light);
}

So in these functions I'm:

Setting the value of the currentTheme, because I need to keep track of what the active theme is.
Using the native browser document.documentElement.style.setProperty function, I'm finding the CSS variable that I need to change, and then passing in what I want the new valule to be.

If this is your first time seeing document.documentElement.style.setProperty() I highly recommend checking out David Walsh's article

The last line here is very specific to my development environment. Since I'm using Gridsome, when my site is built on Netlify it's going to run through all Vue components and turn them into static HTML. localStorage does not exist in Node, so trying to access it here will cause the build to fail. I'm using process.isClient to check if the current environment is in the browser. If it is, then it executes this line, setting the current theme in local storage. If not, the line is just skipped.

x && y() is just shorthand for if(x) { y() }. If the first value is true, the latter is executed.

Adding the composable to a Vue component

Now to actually use this new functionality, it needs to be imported to a Vue component!

I'm only going to show the relevant pieces here, but my personal site is open source and I definitely encourage you to check out the here and here.

In the template, I'll add a button with a click handler that points to the toggleTheme function.
This is just a regular 'ol button element with a font awesome lightbulb icon inside

<button @click="toggleTheme" class="theme-toggle">
    <i class="far fa-lightbulb"></i>
</button>

In the script tag, I'll import the composable, extract the toggleTheme function, and return it from the setup function so it can be referenced in the template.

<script>
    import useTheme from '~/composables/useTheme';

    export default {
        setup() {
            const { toggleTheme } = useTheme();

            return {
                toggleTheme,
            };
        },
    };
</script>

Notice how I'm destructuring toggleTheme from the return value of useTheme? This is what I mentioned earlier. Some of you that have been working with javascript
for a long time might have already recognized what's going on here. toggleTheme is using a closure to keep the
reference to currentTheme in sync!

Closures are a huge and complicated concept that is out of the scope of this article. They're 100% worth learning though, and this is a great article to start with!

Now when the user clicks on the lightbulb:

The toggleTheme function will be called,
The value of currentTheme will be checked, and the appropriate theme function will be called.

This works!

Saving the user's preference

Some of you might've noticed that in the set[X]Theme functions, the current theme is being saved to local storage. This is so that the user's preference for dark or light
theme can be saved. However, as the code stands, nothing is actually done with this data, and in fact, it causes a bug. So to take care of that,

// ...
export default function useTheme() {
    const currentTheme = ref('light');

    if (process.isClient) {
        // check local storage for saved theme preference and set it
        const themePreference = localStorage.getItem('theme');
        if (themePreference) {
            currentTheme.value = themePreference;
            currentTheme.value === 'light' ? setLightTheme() : setDarkTheme();
        }
    }
//...

Here, process.isClient is being checked again so that this doesn't fail during build, as mentioned earlier.
If the code is being executed in the browser, the themePreference is retrieved from the user's localStorage. If the value
of themePreference is truthy, then the value of currentTheme is set to the retrieved value, and then the appropriate set[X]Theme
function is executed so that the the user's preference is now set on load!

Conclusion

I had a blast implimenting this, and being able to pull all this logic out into a separate file and use the power of JavaScript's modularity is
an awesome feeling. Did you anything? Did you notice an implimentation detail that could be improved? Be sure to let me know on twitter!

As always, until next time 🖖🏻

Let's Build A Game With Vue 3

Ronnie Villarini — Mon, 10 Aug 2020 13:39:31 +0000

This post first appeared on my blog

Today we're going to be building a tic-tac-toe clone like the one seen in the React docs. Except we're going to be using the Vue 3 Composition API.

🗣️You can check out the source code here or the live demo here.

If you're totally new to the Vue 3 composition API, I recommend you check out my post on that first.

This post will assume you have some basic understanding of the API, as well as Vue and JavaScript.

Set up

I'm going to be using Vite for quick setup as well as a lightening fast dev server. I definitely recommend checking it out! It uses Vue 3 by default, so we don't have any additional set up to worry about to get going.

To create the project run:

npm init vite-app tic-tac-toe
cd tic-tac-toe
npm i
npm run dev

Now you should be all set up and if you open your browser to localhost:3000 you should be looking at something like this:

Take a moment to look around the code if you want, otherwise lets get started!

The Board

First lets start creating the board. We will start by renaming the HelloWorld.vue component to Board.vue(Don't forget to change the imports!), then we will alter the template in App.vue along with replacing the boiler plate in the now named Board.vue.

// App.vue
import Board from './components/Board.vue';

export default {
    name: 'App',
    components: {
        Board,
    },
};

The board and related styles:

// Board.vue
<template>
<div class='board'>
    <span class='vertical-line-1'></span>
    <span class='vertical-line-2'></span>
    <Square />
</div>
</template>

<script>
import Square from './Square.vue'

export default {
  name: 'Board',
    components: {
        Square,
    }
}
</script>

<style scoped>
.board {
    position: relative;
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    grid-template-rows: repeat(3, 1fr);
}

.board::before, .board::after {
    background: linear-gradient(to right,  #41b883, #35495e)
}

.vertical-line-1, .vertical-line-2 {
    background: linear-gradient(to right,  #41b883, #35495e)
}

.board::before, .board::after {
    content: '';
    width: 100%;
    height: 5px;
    position: absolute;
    border-radius: 1rem;
}

.board::before {
    top: 33%;
}

.board::after {
    top: 66%;
}

.vertical-line-1, .vertical-line-2 {
    position: absolute;
    width: 100%;
    height: 5px;
    top: 50%;
    border-radius: 1rem;
    transform: translate(-50%, -50%) rotate(90deg);
}

.vertical-line-1 {
    left: 33%;
}

.vertical-line-2 {
    left: 66%;
}
</style>

Here we are just taking care of the basic markup and styling. Using a couple spans, and the board's before and after elements to take care of the lines that make up the game board. We're also registering a Square component, which will be responsible for rendering the actual buttons that the user clicks to place their X or O , respectively. Let's build that now.

The Squares

So before jumping into the code, let's think about what we expect from our Square component:

It should receive a value - When the user clicks on the button, it should receive the value of the current player, and we'll display that value in our template.
It should probably disable the button after it's been passed a value and/or if there is a winner.

That's ... really it! So let's build it out:

First let's take care of the template and the styles. We'll add a button with a disabled attribute which we will bind to winner || value, so that we can dynamically mark this button as disabled based on whether it has been clicked, or if the game is over. For accessibility reasons, we'll add a name attribute that we'll bind to a prop called label.

// Square.vue

<template>
    <button
        class='square'
        :name="label"
        :disabled='winner || value'
    >
        {{ value }}
    </button>
</template>

<style scoped>
.square {
    border: none;
    width: 10rem;
    height: 10rem;
    background: none;
    color: inherit;
    font-size: 3rem;
    font-weight: 700;
}

.square:hover {
    cursor: pointer;
}

.square:focus {
    outline: none;
    background: #41b88330;
}

.square:first-child,
.square:nth-child(2),
.square:nth-child(3) {
    border-top: none;
}

.square:nth-child(3),
.square:nth-child(6),
.square:last-child {
    border-right: none;
}

.square:nth-child(7),
.square:nth-child(8),
.square:last-child {
    border-bottom: none;
}

.square:first-child,
.square:nth-child(4),
.square:nth-child(7) {
    border-left: none;
}
</style>

Now let's add the JS! Since our component isn't in charge of maintaining any state, it'll be pretty lean. All we need is to declare our props, label, value, and winner.

<script>
export default {
    props: {
        label: String,
        value: {
            type: String,
            default: ' ',
        },
        winner: null,
    },
});
</script>

Cool! However, if you've been following along, you'll likely notice our app doesn't actually do anything yet. Let's add the game logic now!

Game Logic

Since we're using the composition API, we can o organize our code in related blocks, and then initiate all of that in the setup function. That might sound complicated, so lets take a look at the code and see what that means.

Let's plan everything out before we start writing code. (I'm just doing this to look good. I almost always code before thinking, which you're not supposed to do 🤫)

We're going to keep track of the board, which we'll represent with an array. Each entry in the array will be one of the boxes on the board.
The board will also need to keep track of who's turn it is, and what value (x or o) that player represents.
When a square on the board is clicked, we should alter it's value in our array and notify the square of the change.

Cool! Now that we know how everything should work, lets get to coding.

import { ref } from 'vue'

setup() {
  const board = ref(Array(9).fill(null));
  const playerValue = ref('X');

  const markSquare = (i) => {
    const boardCopy = board.value.slice();
    boardCopy[i] = playerValue.value;
    board.value = boardCopy;
    playerValue.value === 'X' ? (playerValue.value = 'O') : (playerValue.value = 'X');
   };

   return {
     board,
     playerValue,
     markSquare,
   }
};

Inside our setup function we're initializing two variables, board and playerValue. We're using ref here, a new addition from the composition api, to wrap the variable in a reactive reference. Reactive Reference is an important distinction here, because you have to remember this is an object, and you have to add .value to actually access the value held within. This allows us to use Vue's reactivity system, so that anywhere these variables are referenced will be updated when it changes.

Next we declare a function called markSquare, that takes one parameter, i. This is common shorthand for index, and you'll see why we're expecting this value shortly. The function then creates a copy of the board, assigning it to the variable boardCopy.

💡 I'm using const here out of personal preference. I prefer to always use const unless I need to change the value, in which case I will change it to let. Since ref actually returns a reactive object we can access and change .value without throwing errors. For more info on how that works, I recommend checking this article over at ui.dev.

We'll now access the value located in our boardCopy array, located at the index that was passed to our function, and change the value from null (the initial value) to the value of whoever's turn it is. After that has been taken care of, we will just replace our current board with the copy. Before we return from our function, we're going to check to see who's turn it is and set the appropriate value so that the next player can begin their turn.

Last step here is the explicit return object from our setup function.

return {
    board,
    playerValue,
    markSquare,
};

Anything returned from the setup function becomes available in the template.

It's Important to note that passing a ref to the return object gets automagically unpacked by Vue. So you'll be able to reference it in the template at board instead of board.value!

Updating our board template

Now that we have our game logic in place, let's add the updates to the board so that we can start applying this logic and interacting with the game!

+ <h1 v-else>Next Up: {{ playerValue }}</h1>
 <div class='board'>
 <span class='vertical-line-1'></span>
 <span class='vertical-line-2'></span>
  <Square
+    v-for='(square, i) in board'
+    :key='`square-${i}`'
+    :label="`square-${i}`"
+    :value='square'
+    @click='markSquare(i)'
  />
 </div>

Alright! So we've added:

An h1 to show us who's turn it is.
A loop via v-for to create a Square component for each value in our Board array.
A :key attribute so that Vue can keep track of each instance of Square. This helps Vue keep track of what should and should not be updated.
We're now passing in the current index to the label prop. So our button label should read something like square-1 .
The :value of this square. We're getting this from our loop. Every square should have a value of null on initial render, and as the user clicks it will be updated with the current player's value.
An on click handler that calls our markSquare function, passing in the index of this square so that we update the correct value in our board array.

Now if you load up the game, you should be able to click through each tile, marking each with an x or an o! We're still missing a couple features though:

We have no way of determining who won
Nothing happens when the game ends, the user would probably like to have some sort of text in the UI that tells them who won, and that the game is over.

Calculating a winner and notifying the user.

First, we'll jump back down to our setup function to add the logic for calculating a winner. I borrowed the majority of the below function straight from the React Docs, with some modifications to Vue-ify it.

const calculateWinner = computed(() => {
    const lines = [
        [0, 1, 2],
        [3, 4, 5],
        [6, 7, 8],
        [0, 3, 6],
        [1, 4, 7],
        [2, 5, 8],
        [0, 4, 8],
        [2, 4, 6],
    ];

    for (let i = 0; i < lines.length; i++) {
        const [a, b, c] = lines[i];
        if (
            board.value[a] &&
            board.value[a] === board.value[b] &&
            board.value[a] === board.value[c]
        ) {
            return `${board.value[a]} Wins`;
        }
    }

    if (board.value.every(val => val)) return 'Tie!';

    return null;
});

So a few things are happening here:

We're creating an array of arrays, lines, that houses all the possible winning combinations.
We loop through each of the combos, checking to see if the current state of our board matches any of the possible conditions and declaring a winner if it does.
If there is no winner, and the board is full, declare the game a tie.
If the board isn't full and it isn't full yet, just return null.

Let's remember to declare this in our return object so we can use this computed function in the output.

return {
    board,
    playerValue,
    markSquare,
+ calculateWinner
}

Now we can reference this in our template to both disable all remaining squares on the board, and show a message to the user if a winner has been declared or if there is a tie.

+ <header v-if='calculateWinner' class='header'>
+    <h1>
+        {{ calculateWinner }}
+    </h1>
+ </header>
 <h1 v-else>Next Up: {{ playerValue }}</h1>
 <span ref='boardRef' class='confetti-origin'></span>
 <div class='board'>
 <span class='vertical-line-1'></span>
 <span class='vertical-line-2'></span>
  <Square
    v-for='(square, i) in board'
    :key='`square-${i}`'
    :label="`square-${i}`"
    :value='square'
    @click='markSquare(i)'
+    :winner='calculateWinner'
  />
 </div>

That's it! The game is complete! We can add a little polish though. How about a reset button so the user can play again, and we can add some confetti to celebrate the winner!

Reset and Celebrate

First let's add the reset button, as well as a the accompanying logic.

 <header v-if='calculateWinner' class='header'>
     <h1>
         {{ calculateWinner }}
     </h1>
+    <button class='reset' @click='reset'>Play Again</button>
 </header>
 <h1 v-else>Next Up: {{ playerValue }}</h1>
 <span ref='boardRef' class='confetti-origin'></span>
 <div class='board'>
 <span class='vertical-line-1'></span>
 <span class='vertical-line-2'></span>
   <Square
     v-for='(square, i) in board'
     :key='`square-${i}`'
     :label="`square-${i}`"
     :value='square'
     @click='markSquare(i)'
     :winner='calculateWinner'
   />
 </div>

+ const reset = () => {
        board.value = Array(9).fill(null)
        playerValue.value = 'X'
    }

    return {
        board,
        markSquare,
        playerValue,
+       reset
  };

Yayyy 🎉 Now our users can play again if they want to.

As for the confetti, we'll use a small library from npm, dom-confetti.

Install it via npm i dom-confetti, and then in Board.vue we can import it like so

import { confetti } from '../../node_modules/dom-confetti/src/main.js';

Note: If you're not using Vite, you could just use 'dom-confetti' as the path. I'm using Vite, which requires you to point directly to the file in this case.

The confetti function takes a DOM element as it's parameter, so we'll add an element to our template just for this

 <header v-if='calculateWinner' class='header'>
     <h1>
         {{ calculateWinner }}
     </h1>
    <button class='reset' @click='reset'>Play Again</button>
 </header>
 <h1 v-else>Next Up: {{ playerValue }}</h1>
+ <span ref='boardRef' class='confetti-origin'></span>
 <div class='board'>
 <span class='vertical-line-1'></span>
 <span class='vertical-line-2'></span>
   <Square
     v-for='(square, i) in board'
     :key='`square-${i}`'
     :label="`square-${i}`"
     :value='square'
     @click='markSquare(i)'
     :winner='calculateWinner'
   />
 </div>

Now in the setup function, we'll declare a ref that points at this DOM node, and then in the calculateWinner computed property, we'll call confett if there is a winner.

setup() {
+   const boardRef = ref(null)

    // ...

    const calculateWinner = computed(() => {
        const lines = [
            [0, 1, 2],
            [3, 4, 5],
            [6, 7, 8],
            [0, 3, 6],
            [1, 4, 7],
            [2, 5, 8],
            [0, 4, 8],
            [2, 4, 6],
        ]

        for (let i = 0; i < lines.length; i++) {
            const [a, b, c] = lines[i]
            if (
                board.value[a] &&
                board.value[a] === board.value[b] &&
                board.value[a] === board.value[c]
            ) {
+               confetti(boardRef)
                return `${board.value[a]} Wins`
            }
        }

        if(board.value.every(val => val)) return 'Tie!'

        return null
    })

    return {
        board,
+       boardRef,
        markSquare,
        playerValue,
        reset
    }
}

That's it! Open up your browser and try it out. (or if you haven't been following along, you can check out the live demo here.

If you want you can check out the repo, where you'll find a couple extras like TS, and refactoring into composition functions! I would've liked to include that here, but that was just out of the scope for this post. If there is enough interest, I'd be happy to make a follow up post!

Hope you had fun, and hopefully you learned a thing or two about using the composition api in project setting instead of just theory and small examples!

Be sure to follow me on all the socials for more content like this! Until next time 🖖🏻

Vue Inside AJS?!

Ronnie Villarini — Tue, 04 Aug 2020 13:01:50 +0000

This post originally appeared on my blog

At Winning Streak, we recently began our transition of migrating our biggest project from AngularJS to Vue. This is the why and the how!

Why Vue?

First and foremost - AJS is reaching EOL. It was announced that on July 1st, 2018, AJS would enter into a three year LTS period. The Angular team has moved onto Angular 2+ (simply named Angular), and has since stopped development on AJS.

So... Why Vue? Firstly, it's loved by nearly everyone who has used it. Secondly, it's arguably one of the easiest frontend frameworks to get up and running with. Lastly, I have lots of experience with it, and so does the other developer on my team! Vue recognizes that AJS got a lot of things right, and builds on those features while eliminating some of the pain points and poor decisions made.

Methodology

Since Vue promotes incremental adoption, we chose to take that idea and run with it, but how? I found this amazing pen - we saw an approach that we knew would work for us.

The app in question is fairly large, and an integral part of day-to-day operations within the company. This means that a rewrite wouldn't be a great use of time since there are only two of us, and there are still plenty of new features and various fixes/enhancements to work on. We also had to ensure that whatever path we took, it had to live alongside the current implementations without breaking anything.

Okay, cool - but where does the pen come in, and when are you going to get to the point? - you, probably

So here is the plan:

Refactor everything and get the codebase prepped for a modern approach to old solutions.
Replace our build tool, gulp, with Parcel (I'll explain this decision in the next section)
Use AJS components as an entry point for Vue components, acting as a wrapper until Vue becomes the larger portion of the app, in which case we could sprint to finally make the swap.

Phase 1 - The Refactor

Step 1: Refactoring components & their templates to model Vue SFC

I have to admit, this part was a little intimidating. There is a lot of code, and due to the nature of how quickly everything had to be built - there are not a lot of tests - In fact, there aren't any... So we had to take baby steps, carefully performing reviews along the way.

First up, refactor the components to more closely model Vue's SFC approach. Not only did we love how easy SFCs are to work with and reason about, but refactoring AJS into a close clone of this would make it really easy to transition them into Vue components later on. So we moved all the separate template files into es6 string templates, and packaged them up inside the respective AJS template option.

From this:

// example.html
<div>
    <h1>This is my component template!</h1>
</div>

// example.js
angular.module('app').component('example', {
    controller: function($scope) {
        // ... component logic ...
    },
});

To this:

// example.js
angular
  .module('app')
  .component('example', {
    controller: function($scope) {
      // ... component logic ...
    }

    template: `
       <div>
         <h1>This is my component template!</h1>
       </div>
    `
  })

This is obviously a trivial example, but it illustrate the point. This refactored component looks very similar to a Vue SFC, and will take just a few minutes to refactor to Vue syntax down the road.

Step 2 : Replace Gulp with Parcel

Let me start by saying,

There is absolutely nothing wrong with Gulp.

Pitchforks down? Okay, lets move on.

We chose Parcel for a couple reasons:

No on really enjoys working with Webpack.
It echos Vue's "easy to get up and running" approach.

On top of those points, since it uses Babel under the hood, we also got access to extra javascript features without any extra configuration. A huge benefit, is Parcel's support of Vue SFCs right out of the box.

Since there is no complicated setup or configuration required for Parcel, there isn't much to go over here. All we had to do was eliminate the gulp file that took care of concatenation, bundling, building, etc. Then we created an Index.html file, and an Index.js file that contained the bootstrap logic for the app. Parcel takes care of the rest!

🔗Check out the official Parcel docs for more info

Step 3: Refactor components to default exports

This was the simplest part of the refactor, at was the last step. In ES6, we have support for import/export syntax like so:

import MyComponent from '../components/MyComponent';

// MyComponent.js
export default {
    // ... component logic ...
};

Now if we refactor all our angular components to this syntax, we can simplify how register them with Angular, and this will again make the transition to Vue much simpler.

now in our index.js file, we can register our components like so:

// first mass import all the components
import * as components from './components/*.js';

// loop through all the components and register them
for (component in components) {
    angular.component(component, components[component].default);
}

Let's break this down just to clarify what is happening:

First we're mass importing everything that ends in .js in our components directory, and giving this object that contains them all the name of components.
Then we loop through each property in components, which each of which is a component object.
Then we register this component with Angular. Component is the first argument which is the component's name. components[component].default is the actual component object. It's important to note the .default here, because the object contains a property, default, which is the default export declared in each component file.

Now instead of registering each component with Angular in each module, they're all being declared and registered in one location in our app. Even more importantly, this won't break when some of them get refactored to Vue components, because the import loop only imports .js files, not .vue!

Phase 2 - Adding Vue

Now the fun part, and the part I've been dreaming of since I joined the company and started maintaining the AJS code. As previously discussed, this addition of Vue had to be just that - an addition. It needs to work alongside the existing code, in a symbiotic relationship.

Thankfully, I discovered the codepen mentioned earlier in the article that showcases using AJS to mount our Vue components. This works because Vue, like most SPAs, attaches itself to a part of the DOM, and controls everything within it. This is why most SPA boilerplate just has a single div with an id of "app".

Great. Code please?

Calm down, I'm getting there.

// login.js
import Login from './Login.vue'

export default {
  controller: function($element) {
        this.vue = new Vue({
      el: $element.find('Login')[0]
    })
    }

    template: `<Login ng-non-bindable></Login>`
}

WTF?!

Yeah, those were my thoughts exactly.

So we're importing our Vue component and using Angular to find the custom tag in the DOM, and mount our Vue instance. This works... surprisingly well. Using this method, you can even pass data into the component from Angular! Now our Angular component is actually just a transparent wrapper. It is still registered with Angular, so we can use any data we need from the Angular layer and still route to this component using our Angular router.

Notice the use of ng-non-bindable here. Its required so that Angular doesn't try to apply Angular specific bindings to the Vue component.

This approach becomes really cool when you start passing data between the layers.

import Login from './Login.vue'

export default {
  controller: function($element, $stateParams) {
    this.vue = new Vue({
      el: $element.find('Login')[0]
      data() {
        return {
          userId: $stateParams,
        }
      }
    })
  },
  template: `<Login :userId='userId'></Login>`

In the example above, we're using the Angular router to gather the userIDfrom the \$stateParams (url params), and passing it to the Vue instance. This works the other way too, allowing you to emit an event from the Vue instance that actually calls a method in the Angular instance. You might need to do this for a component that uses an Angular specific third party library, like Angular Bootstrap and modals.

The best part of this whole set up, is we can author Vue SFCs thanks to the built-in support from Parcel. Then we can import those components and reference them in the Angular instance. Done right, this whole system allows you to slowly replace Angular from the inside out, using Vue to control everything about the app. We will eventually get to a point where Angular is just providing the router and wrapping Vue components, in which case we will just replace it with the Vue router, and remove the Angular components!

Conclusion

So this is how we converted our AJS app to Vue without a total rewrite, and without breaking anything in the process. We planned it for months, but it took only a couple days to sprint on the Parcel conversion, and now all we have to do is author new features in Vue and continue to replace bits and pieces with Vue. Hopefully you learned something, or at least discovered something interesting out of all this! If nothing else, at least it'll be a cool way to document this process 😃. Be sure to follow me on Twitter, and let me know what you think!

Until next time! 🖖🏻

Composition API - what is it, and why?

Ronnie Villarini — Mon, 13 Jul 2020 14:17:32 +0000

Before we even start...

Let's talk about a couple of things that should be noted that the composition API is purely additive. It is not required, nor is the old API in any way being deprecated. This was a huge misunderstanding and a pain point for many Vue developers.

So.. Why a new API?

It boils down to a few major pain points that can be encountered when building larger scale Vue apps:

TypeScript support is.. not great. Vue does some magic behind the scenes, and therefore type inference just doesn't work the way that one might hope. Now that TypeScript has seemingly taken the JavaScript community under its wing, it has become apparent that better type support is necessary.
The organization of component logic. If you've ever worked with a large component file, you might know how hard it can be to figure out... just... wtf is going on. Everything is organized by the options API which works great most of the time, but once a component becomes complex you might find yourself jumping back and forth between the different options just to try and follow along with the logic.
Mixins can be confusing. They are the best way to abstract and share certain logic between components as of right now, but they come with a host of their own problems including namespace collisions, and a lack of context about where certain properties are coming from.

Okay so... What is it?

From the RFC summary:

A set of additive, function-based APIs that allow flexible composition of component logic.

Let's break that down and see how it relates to our earlier points.

TypeScript support

This one is huge for a lot of people. There is no denying that TypeScript is here to stay, and it has plenty of people willing to die on a hill to show how important it is. Regardless of how you feel about it, the IDE support and safety it provides is outstanding for the developer experience.

Along with the API change the Vue codebase has been rewritten with TypeScript in mind which is something you couldn't say about previous versions. What really makes this easier though, is the removal of the magical this.

If you're unfamiliar with this in JavaScript or you still struggle with it, I highly recommend this article at ui.dev

In Vue, there is a lot of magic happening behind the, and one of those spells that they are casting is the way that this is automagically bound to the component instance for you. Those of you who used React in the early days may remember how painful keeping track of the scope of this could be. Vue made this easy by taking care of the scope for you. Ensuring that referencing this in your methods, computed properties, or even lifecycle hooks, was always bound to the component instance. This was great, as it greatly reduced cognitive overhead when working inside a component and it really lowered the barrier to entry for more inexperienced devs.

export default {
    name: 'MyComponent',
    data() {
        return {
            count: 0,
        };
    },
    methods: {
        increment() {
            this.count++; // WHAT?! In normal JS "this" would not be what you think it is
                         // but Vue takes care of that for you
        },
    },
};

The drawback of course to all of this was the extra work that had to be done to add proper type inference. Plugin authors had to jump through extra hoops, and TypeScript devs using Vue often resorted to using a community package that added decorators to classes and properties. Now, if you opt to use the composition API, there is no need for this extra legwork since you're working with more natural and type-friendly Javascript.

import { ref } from 'vue'

export default {
    const count = ref(0)

    function increment() {
         count.value++  // note, you have to use ".value" to access it now
                        // but you no longer have to worry about what "this" actually is!
    }
}

Organization of code logic

This is a huge one for me, as I've seen just how out of control a component can get at scale.

Well, that shouldn't have ever happened. If you were using components correctly, you would've abstracted more of the logic into separate components to keep the original component simple.

Shut up, Karen. No one asked you.

Really though, sometimes things happen and components get huge. Like this one, referenced in the Composition API overview.
When components do inevitably get out of control like this, it gets really hard to understand what is going on. Logic can become fragmented because you have your data being declared at the top, but the method that uses that data is all the way at the bottom, and maybe that method references a computed property somewhere in the middle.. you see where I'm going with this.
The more you have to navigate up and down a file, the more cognitive load you're enduring. If users shouldn't have to think, why should we willingly endure such strain when we're just trying to understand wtf is going on?!

Since the composition API doesn't rely on organization by component options, you're free to organize your code by logic. For example:

// options API
export default {
    name: 'MyComponent',
    data() {
        return {
            count: 0,
        };
    },
    computed: {
        prevCount() {
            return this.count > 0 ? this.count - 1 : this.count;
        },
    },
    methods: {
        increment() {
            this.count++;
        },
    },
};

// Composition API
import { ref, computed } from 'vue'

export default {
    const count = ref(0)

    const prevCount = computed(() => count.value > 0 ? count.value - 1 : count.value)
    function increment () {
        count.value++
    }
}

Obviously, this is a small example, but you can see how this would really help clear things up. You can group your code into blocks based on what they're doing and you can focus all your attention on the block you're currently working in. It's like would you rather:

Declare a variable right before the function that is going to use it
Declare all variables at the top of a file and then all functions at the bottom.

If you chose the latter, then.. well. Sorry 'bout ya. 😜

Code reuse

Lastly, there is code reuse. For a while now, the best way to share code among various components were mixins. Essentially, a mixin is a Vue object that exposes all the component lifecycle hooks and properties you might need, but it can be merged with another component.

This is really cool because if you have the same type of initialization logic, or perhaps several functions that you'd like to share between components, all you have to do is apply a mixin and you've got it! Of course, though, there were downsides.

If the mixin happens to have the same data property or method name as the component using it, the mixin's options would be overwritten during the merge.
If you're a new developer, or just a different member of the team looking at a component that someone else wrote, it might not really be clear where some of the properties and methods are coming from.

The composition API solves spectacularly solves this. Since you're essentially writing basic JavaScript, you can simply export your data as a function and import it elsewhere! Now if you're calling a method, unicornPoop(), somewhere in your component - you won't be confused as to where it came from, because you'll have an import statement at the top of the file. :chefs-kiss:

Conclusion

The composition API looks to be an exciting new way for experienced Vue developers to write their components, and I really look forward to using it.

What about you? Are you planning to use it? Will they pry the options API from your cold, dead, hands? Are you going to use them both? (yes, that's possible.)

I'd love to hear about it! Be sure to follow me on twitter @_ronini and @ me all you want!

Until next time 🖖🏻

Getting set up with Gridsome

Ronnie Villarini — Thu, 09 Jul 2020 18:32:30 +0000

⚠️This article is a little heavier than some of the others. I found it best to try and explain the basic structure in a fair amount of detail, but feel free to skim to sections that catch your attention!⚠️

Getting started

So first things first, we need to actually install Gridsome. Like most modern JS frameworks, they have a nice CLI tool we can use to get the project quickly set up.

First install the Gridsome CLI,
npm i -g @gridsome/cli
yarn global add @gridsome/cli (gridsome recommends yarn)

Then all we have to do is create a new project straight from the CLI!

gridsome create ronini

cd ronini

Now we can start the server gridsome develop and navigate to localhost:8080 in your browser to view your site live. Pretty simple! 🥳

Directory Structure

Now lets take a look around and get ourselves familiar with what Gridsome has set us up with.

Now, I won't go over everything because there is a lot going on here and Gridsome, like most tools in the Vue ecosystem, has pretty stellar docs, which you can find here. I will go over some of the bigger talking points though.

Main.js

As you'll see with most of the files and folders in your newly bootstrapped project, the Gridsome team has done a great job of trying to outline the basics for everything. If you open up main.js , you should see something similar to:

A few things to note here:

We're importing and registering a component called DefaultLayout globally. This is something called.. well.. a layout and we will talk about them very shortly.
As the comments suggest, if we wanted to register components/filters/directives with the Vue instance, this is where we would do it. This is also where we would import a global css file, which we will also do in another article.
You can see scripts mentioned as a potential import here. This is where you would inject things into the head of your document such as font awesome, google analytics, etc. (You might also be able to find a plugin for that - another topic we will discuss in a later article.)

/layouts

Let's go ahead and move into the layouts directory since we've already mentioned a layout component. Layouts are basically just large wrapper components that you can use to define the layout of certain pages, routes, or even your whole site.

If you open up /layouts/Default.vue, and take a look at the code inside the <template> tags, you should see

So we have a few cool things happening here:

You can see a component here, g-link, that is Gridsome's wrapper around Vue-Router's router-link. It really acts the same way, but with the added benefit of prefetching data from those links using intersection observers. What this means, is if the link is in view, Gridsome will make the request in the background and grab all that data for the user. This way, when the user clicks the link, the transition is almost instantaneous. This is how sites like Gridsome and Gatsby make the user experience feel so fast when they're navigating around the site.
You'll probably also notice the $static.metadata.siteName, which is a topic for another time but the basics of it is this; Gridsome uses GraphQL under the hood to organize data. This allows you to write GraphQL queries in your components to fetch relevant data and present it like so. Here, we have fetched the name of our site from the metadata object. Pretty cool stuff! If you want to learn more about it, you can check the docs here.
Lastly, we have a slot component. If you're unfamiliar with Vue slots, they are a way to create components that can be passed children. For example:
```
// CoolTitleComponent.js
<template>
    <header class='awesomeHeader'>
        <h1 class='awesomeHeader--text'>  
            <slot></slot>
        </h1>
    </header>
</template>

// Somewhere else in our app
<CoolTitleComponent>
  Wassssuppppp
</CoolTitleComponent>
```
In this example, we have a component called CoolTitleComponent , which contains a component provided to us by Vue, called slot. In this component we can do whatever we want, but for example sake let's just say our component applies some cool color to the text (purple, because it's the best) placed in our h1 tag. Then somewhere else in our app we use our component and place the text "Wassssupppppp" in between the opening and closing tags, because why not.

When Vue renders this component, the slot component will be replaced with the text that we passed in, and our component will be rendered as :
```
    <header class='awesomeHeader'>
        <h1 class='awesomeHeader--text'>  
      Wassssuppppp
        </h1>
    </header>
```
Slots are super powerful, and I would definitely recommend reading more about them here.

So for our Default component, this means that we can structure anything that is passed in the way we see fit! With the code provided to you by the CLI, you can wrap any component you make inside of the Default component, and it will always render with a nav bar as seen in the code, as well as some global styles! We will be editing this file in our next article, so stay tuned 📺.

Index.html and App.vue (optional)

I'm going to group these two files together because they are both optional. Normally when creating a new Vue application you'd have App.vue as the root of all components, and the main entry point. Gridsome, by default, takes care of this under the hood. However, you can override the default file by creating one of your own if you just create an App.vue file in the root of your src directory. We will be doing this to apply global transition effects to our app later on.

Index.html is handled the same way by Gridsome, and can be overridden by creating an index.html file in the root of your src directory as well. This probably won't be used as often, as you can actually inject scripts and cdn links via the main.js file as we discussed earlier. However, if that can't be done, or you'd just rather not do it that way, you can override the index.html and insert the content that way instead!

/static

This one is fairly straight forward. Any files and directories you place here will be copied straight to the /dist folder during build time. This is where you'd put something like a font file that you're serving yourself.

/pages

This directory is where you put all your, you guessed it, pages! Here you'll create .vue files that are various pages in your application. Any file you put here, Gridsome will automagically create a route for! So in the generated code we have:

    ├── pages/
    │   ├── Index.vue
    │   └── About.vue

This means Gridsome has generated two routes for us, / (index.vue, this is the root of the site), and /about. Now can navigate to these routes in your browser like localhost:8080/about.

So we can see how it works, lets go ahead and create a new file in our /pages directory called Blog.vue. We'll put this into the file,

<template>
    <Layout>
    <div>
        This is my blog!!
    </div>
    </Layout>
</template>

<script>
    export default {
        name: 'Blog'
    }
</script>

Save your changes, and navigate to [localhost:8080/blog](http://localhost:8000/blog) in your browser. You should see your page load!

/templates

Straight from the Gridsome docs:

Templates are used to create single pages for nodes in a collection. Nodes need a corresponding page in order to be presented on its own URL.

Now... some of you might have understood that. I wasn't one of those people - so let me try and explain in a way that I now understand.

If you are connecting your site to an external data source, say something like Contentful, Netlify CMS, or Wordpress, You would use templates to generate pages based on the data received from those data sources.

Still doesn't make sense? That's okay! Think of it like this:

Let's pretend you have a blog. The content of that blog is written using Netlify CMS and displayed on your Gridsome site. If the data of each of your posts (the headings, text, pictures, etc.) were all different flavors of Ben & Jerry's Ice Cream (Try Netflix and Chill'd, tweet @ me when you do 😋), then the container would be the template! The content might all change from from post to post, but they'll all have the same structure.

Okay.. but didn't you say this is what Layouts are for..? - you, probably.

Yes.. and no. Layout do theoretically do the same thing, but for different types of data. A layout is something you apply manually to your components, to structure any content inside. A template is also a way to structure content, but it is applied automatically to certain types of content. In this case, a blog post.

This does require some manual configuration which you can learn about here

This was part 2 in my series about rebuilding my personal site with Gridsome! I know this one wasn't quite as exciting, but next time we will go over plugins in Gridsome, and we will add my favorite CSS framework, Tailwind CSS! See you all next time, and be sure to follow me on twitter!

Rebuilding my personal site with Gridsome

Ronnie Villarini — Thu, 18 Jun 2020 13:07:45 +0000

I've decided to Rebuild my personal site with Gridsome for a few reasons:

I've learned quite a lot since making it just a year ago.
It's lacking in content, and I don't feel as though it showcases everything I think is important.
My contact section isn't obvious enough.
I don't imagine it's SEO optimized.

I'll be documenting this process along with my train of thought and decisions along the way. I hope that at least some of you can get something out of it! If nothing else, I'll have a cool little reminder of this process that I can look back on in the future. 😃

So Why Gridsome?

A lot of you may not have heard of Gridsome as it's still in it's early days (0.7.17 at the time of writing), so what is it?

To put it simply, it's Gatsby for Vue

SSG (static site generator) Benefits

Straight from the home page:

Gridsome makes it easy for developers to build static generated websites & apps that are fast by default 🚀

Fast by default. This is one of the main reasons for picking an SSG like Gridsome or Gatsby. They come with so many out-of-the-box optimizations that you get 90+ lighthouse scores from the start. This can be a huge timesaver, and who doesn't like fast sites?
SSG's allow you to work with lots of convenient tools such as templating engines, and transforming markdown files into HTML pages.
They're easy to deploy, and with the help of providers like Netlify, you can even deploy them for free within minutes! Netlify even lets you connect to your github repo and it'll automatically re-build and deploy everytime you push a change!
Of course, they're more secure as well. Without a server, there are fewer points in which to exploit.

Gridsome VS Gatsby

image from morioh.com

Put your pitchforks down, I'm not here to tell you one is better than the other. Only outline the differences and explain why I chose Gridsome.

The most important and obvious reason - I'm a Vue developer. I fell in love with Vue a little over a year ago, starting using it for side projects, and now I use it at work! With Gatsby being a React-based SSG, I opted to stick with what I know and enjoy purely because of my personal bias. I've used React in the past, and it'll always hold a special place in my heart - but I'm just much faster and more productive in Vue.
Gridsome actually takes most of it's inspiration from Gatsby such as
- Plugins
- Themes (starters in Gridsome)
- GraphQL data layer for cool things like site metadata, images, and page queries (something we will talk more in depth about in a later post)

All of these things make it a joy to work with and really which one you choose comes down to either personal bias, or your desire to use something more mature (Gatsby being around for much longer at this point)

Our journey starts here! In the next post we'll talk more about getting started with Gridsome, along with some basic project configuration.

See you then 🖖

Greatest Strength and Greatest Weakness

Ronnie Villarini — Mon, 22 Jul 2019 11:43:09 +0000

What is your greatest strength? What about your greatest weakness?

If you've been to an interview, chances are that you have heard this question at least once.
I'm going to tell you a secret:

I hate it

It's Not A Bad Interview Question

I feel as though it is important for me to preface this by saying, I don't hate it because it's just a bad question. I hate it because my greatest weakness is also my greatest strength. For me, I believe this is my "all or nothing" personality.

WUT?

What does that even mean, Ronnie? Well, for the longest time I didn't realize it - but I'm incapable of just "dipping my toes in". Regardless of if the subject is video games, cooking, or coding - I go, for lack of a better word, H.A.M.

The Good

Going so overboard on just about any topic that really catches my interest gives me a lot of obvious benefits.

I am able to really focus on the topic at hand
I end up learning a lot, from a large variety of resources
I learn at a very accelerated pace

In fact, if I hadn't been this way, I likely wouldn't have been able to make the career change from my seven years at Walmart to a professional developer in under 6 months. Since I was so hyper-focused and well, obsessed, I was able to give up a lot.

I have been a huge gamer since I was around 7, and I gave up gaming for that 6 months
I spent all of my free time studying and practicing.

Work -> Family Time -> Code

The Bad

So, what's so bad about that? Sounds like it worked out pretty well for me, right? I succeeded in making the career change, and now I'm working for an awesome company doing something I love.

At some point, you start to forget who you are
It gets easy to become so focused, it starts to interfere with other responsibilities
It can become unhealthy

Whoa, Whoa, Whoa. Let's start from the top, "forget who you are"?? Yes.

Forgetting Who You Are

In fear of sounding dramatic, at some point you can get lost in what you're doing at lose track of who you are. As I said before, I was, and still am, a huge gamer. Video games for me, like many others, have been an awesome way to escape. When things in life weren't great and when I just needed a little distraction or an experience, games were always there.

When I made the dive into coding and making this career switch, I gave that up.

I forgot to take breaks sometimes. (Those are really important.)
It became more difficult for me to cope with my manic depression

Interfering With Other Responsibilities

I am a father of two beautiful girls, and I am lucky enough to have met a woman that I intend on spending the rest of my life with (shhh 🤫, I haven't proposed yet). So, what does that have to do with anything?

Well, when I became blinded by my ambition and desires, I neglected some of my other responsibilities.

I was not spending enough time with my daughter (my youngest hadn't been born yet)
Sammie and I sacrificed our time together as a couple, and sometimes she sacrificed her spare time to take care of our oldest so that I could get more studying in.

This is a big deal, and it's something I will forever be thankful for. I wouldn't have made it this far without the help and support I received from Sammie. Now, I do my best to make up for that lost time and try and not get so blinded in the future. This could have easily cost me my relationship.

It Can Become Unhealthy

Yeah, Yeah, Yeah - I know. This is probably stretching it for a lot of you. As I said though, this is my experience and has a lot to do with my own addictive personality.

I stopped eating regularly, and definitely wasn't eating as healthily - only food that allowed me to get back to studying as quickly as possible
I stopped exercising, or really anything that would take away from the limited time I had to study
I sacrificed as much sleep as I could while still maintaining the ability to minimally function

I made cuts the same way a corporation does. I sacrificed anything that took away from my ability to study and saw it as something that just wasn't important right now.

It's Okay To Be Passionate

Follow your heart, but take your brain with you.

~ Haley Michael (an old friend of mine)

I'm not trying to say it's not okay to keep your nose down and really give something your all.
That's a wonderful thing to do, and it is a great way to accomplish your goals! Just be conscious of what you're doing. Not everyone gets this obsessed with things, and most are more than capable of drawing that line for themselves.

This is just simply my greatest strength and weakness.

What is your greatest strength and greatest weakness? I'd love to hear what you have to say.

You can find me on Twitter, Dev.to, Instagram,
and LinkedIn

Thanks for reading! 👋🏻✌️