DEV Community: Drew Clements

The Ease of Eager-loading in Laravel

Drew Clements — Wed, 13 Mar 2024 17:12:59 +0000

Ever waited for a webpage or app to load? That frustrating feeling when time seems to crawl by? That's the nightmare of today's digital world and a major buzzkill for users. Slow load times can derail the entire user experience, leading them to leave your website before even seeing its value.

That's a problem.

47% of users won't wait more than two seconds for a website to load
- Top Website Statistics of 2023 | Forbes

Thankfully, Laravel has a not-so-secret weapon for optimizing performance: Eager-loading.

What is Eager-loading?

Eager-loading is like saying, "I'll need that later, so I'll grab it now." It's akin to packing a flashlight for a trip instead of going back for it when needed.

In database terms, eager-loading reduces the number of trips to fetch data, saving milliseconds that add up with complex applications.

Eager-loading documentation

Eager-loading Prerequisites

In Laravel, eager-loading is built-in; no additional libraries are needed. However, proper setup of model relationships in the database and Laravel app is crucial.

Setting Up Your Tables

Define primary and foreign keys in your database tables. For example:

// posts table
$table->primary('id');

// comments table
$table->primary('id');
$table->foreignId('post_id')->constrained('posts');

Defining Your Relationships

Define relationships in models generated by php artisan make:model ModelName. For instance:

// App\Models\Post.php
public function comments(): HasMany
{
  return $this->hasMany(PostComments::class);
}

// App\Models\PostComment.php
public function post(): BelongsTo
{
  return $this->belongsTo(Post::class);
}

Eager-loading in Action

Now, how do we eager-load these relationships? Use $posts->load(['comments']) to fetch posts and associated comments in one query.

Without eager-loading, separately fetching posts and comments would lead to multiple queries, impacting performance significantly.
Now, let's look at how you could load posts and their comments without eager-loading.

In these examples, we'll act as though we're in a IndexPostsController where we'll query for all posts and their comments.

Without Eager-loading

// without eager loading

public function __invoke()
{
  $posts = Post::all();

  foreach ($posts as $post) {
    $posts->comments = PostComment::where('post_id', $post->id);
  }

  return Inertia::render('IndexPosts',
    [
      'posts' => $posts
    ]
  );
}

With Eager-loading

// with eager loading

public function __invoke()
{
  return Inertia::render('IndexPosts',
    [
      'posts' => $posts->load(['comments'])
    ]
  );
}

Eager-loading saves queries, improves performance, and enhances the user experience. Your database, you, and your users will thank you for building a fast-loading app!

Learn more about eager-loading here in the official Laravel documentation.

Vue 3: Common Options API things done the Composition way

Drew Clements — Fri, 03 Jun 2022 19:40:27 +0000

As with all things new

For those living under a rock (or buried under legacy spaghetti), Vue 3 dropped in 2021 and in February of 2022 it was declared the default version moving forward. With it came the new composition API. The composition API brings a lot of changes in how we write, structure, and build Vue components.

This article is going to be looking at some of the more commonly used Vue features and what they look like in Vue 3, compared to their Vue 2 counterparts.

What we'll be looking at:

props
methods
data
computed properties
watchers

Props

Props are probably one of the most used features in Vue- or any framework really. Props are what allow passing data, whether it be static or dynamic, from component to component.

A common pattern is to define what props a component will be receiving, for a variety of reasons. Define types, whether or not it's required, and more importantly just so the component is aware of it and can be accessed in the template.

Here's what registering props in Vue 2 looks like:

<script>
  export default {
    props: {
      myProp: {
        type: String,
        default: "Hello",
      }
    }
  }
</script>

There's nothing overly complicated about it. In fact, prop registration has never been a "difficult" thing in Vue.

Here's what registering props looks like in Vue 3:

<script setup>
const props = defineProps({
      myProp: {
        type: String,
        default: "Hello",
      }
})
</script>

And both of these would be available in the template like so:

<template>
  <p>{{ myProp }}</p>
</template>

Methods

In Vue 2, methods are where you would store functions for a component you would call elsewhere- either from the template or other lifecycle hooks: computed properties, watchers, mounted, etc.

The concept of methods doesn't exist in the context of script setup. You simply write the function you need and it's available!

Let's look at the Vue 2 way of doing this:

<script>
  export default {
    methods: {
      doTheThing() {
        console.log("The Thing")
      }
    }
  }
</script>

And in Vue 3:

<script setup>
function doTheThing() {
  console.log("The Thing")
}
</script>

And both of these would be available in the template like so:

<template>
  <button type="button" @click="doThething">Click me</button>
</template>

Data

In Vue 2, there's a concept of the data object which is where you can define data points to use in your component as needed. These could be strings, arrays, objects- you name a data type and it can live here (within reason). Forgive my definition of it- this is how I explain it to myself. Think of it "state" for the component.

Here's the Vue 2 way:

<script>
  export default {
    data() {
      return {
        myText: 'Hello, I R Text'
      }
    }
  }
</script>

There's actually two ways to accomplish this in Vue 3, with a ref or a reactive.

Reactive

Reactive objects are JavaScript Proxies and behave just like normal objects. The difference is that Vue is able to track the property access and mutations of a reactive object.
-Vue Docs

This is what a Reactive looks like in Vue 3:

<script setup>
import { reactive } from 'vue'

const state = reactive({count: 0})

console.log(state.count)
</script>

This would be available in the template like so:

<template>
  <p>{{ state.count }}</p>
</template>

There are some limitations to reactives. Check out the docs to learn more about what those are.

Ref

To address the limitations of reactive(), Vue also provides a ref() function which allows us to create reactive "refs" that can hold any value type
-Vue docs

Here's what a ref looks like in Vue 3:

<script setup>
import { ref } from 'vue';

const count = ref(0)

console.log(count.value)
</script>

And this would be available in the template like so:

<template>
  <p>{{ count }}</p>
</template>

Computed Properties

The concept of computed properties in Vue is to give you a way to "handle complex logic that includes reactive data" (official Vue documentation).

Let's say you want to display either the word 'open' or 'closed' depending on the time of day. That would be a lot of logic to cram into the template.

Let's look at what that would look like in a Vue 2 computed property:

// for brevity's sake we're going to pretend a data property isBeforeFive and isWeekend exists and returns true or false

<script>
  export default {
    computed: {
      isOpen() {
        return isBeforeFive && !isWeekend ? 'Open' : 'Closed';
      }
    }
  }
</script>

Obviously this example is a little contrived, but you get the idea here.

Here's that same thing in Vue 3:

<script setup>
import { computed } from 'vue';

const isOpen = computed(() => {
  return isBeforeFive && !isWeekend ? 'Open' : 'Closed';
}
</script>

Both of these would be available in the template like so:

<template>
  <p>{{ isOpen }}</p>
</template>

Watchers

Last but not least of what we're covering today are watchers. Watchers can be an extremely useful tool in the arsenal because they allow you 'to perform "side effects" in reaction to state changes'(official Vue Documentation).

For example: let's say we want to trigger an alert anytime a counter is updated.

Here's that in Vue 2:

<script>
  export default {
    data() { 
     return {
      count: 0
    },
    watch: {
      count(newVal, oldVal) {
        if(newVal > oldVal) alert('Count ticked up!')
      }
    }
  }
</script>

Here it is in Vue 3:

<script setup>
import { ref, watch } from 'vue'

const count = ref(0)

watch(count, (newVal, oldVal) => {
  if(newVal > oldVal) alert('Count ticked up!')
})
</script>

Each of these will trigger an alert anytime the new value of count goes up.

Summary

Vue 3 seems like it's going to be a lot of fun. I can see where the simplicity of script setup will come in handy- but I'm also a huge creature of habit and I like how my Options API has kept things organized for me.

I used to ask "what's an edge case in which I should use composition over options?" After diving into it in more depth, to me, the answer is that there isn't an edge case that will ever force your hand into one or the other and that each has their merits.

Decide for yourself which one you prefer and use that one.

The Vue team has done an amazing job building a useful framework from the beginning and the composition API is just the next iteration of their efforts.

Building an Accessible Recursive Menu System

Drew Clements — Mon, 03 Jan 2022 21:22:30 +0000

Hey hey! It's me again. The guy that rambles like he knows what he's talking about but is really flying by the seat of his pants!

Today we're going to be building an accessible menu system in Nuxt using recursion! You'll be able to use this pattern in a variety of ways: navigation drop-downs, nested sidebar navigations, and plenty of others.

We'll be building it in the context of a sidebar navigation. Think "multiple sub-level navigation menus" akin to what you would expect to see in the sidebar of a documentation site.

Those can get nested and messy very quickly, but we're going to build two components to handle the whole thing!

Note: The accessible menu portion of this article is based on this article by none other than Heydon Pickering

View the repo here

Let's jump right in!

Setting up your project

We're going to be working in Nuxt, so let's get started with spinning up a new project.

I'm actually working from an existing Nuxt project, but here's the command you'll run.

npx create-nuxt-app ally-tuts

It's going to ask you some questions for initial project setup. My answers are below, but choose as you wish.

Programming Language: Javascript
Package Manager: Npm
UI Framework: None (I know, crazy. Right?)
Nuxt.js Modules: Axios
Linting Tools: ESLint
Testing Framework: None
Rendering Mode: Universal (SSR / SSG)
Deployment Target: Static (Static/Jamstack hosting)
Development Tools: jsconfig.json

Now that we have that complete, let's set up a simple scaffold for our app.

A Quick HTML Scaffold

First thing is to delete the Tutorial.vue and NuxtLogo.vue files in the components/ folder. Next, we'll add a SidebarNav.vue in our components folder.

From there, we'll create a layouts folder in the root of our project and add a default.vue component. In that file, we're going to import our SidebarNav component and put it in the template.

Generally, this is where you would set up your header and footer-- and any other global layout level stuff-- but that's out of scope for us so we'll keep it nice and simple.

<!-- ~/layouts/default.vue -->

<template>
  <main>
    <SidebarNav />
    <nuxt />
  </main>
</template>

One cool thing to note here, is that we don't have to import our SidebarNav component! Nuxt just makes it available.

And with that, we can move forward!

Building the Top Level

Again, we're building this in the context of a sidebar navigation. With that in mind, our next step is to create SidebarNav.vue in our components/ folder.

Within that, we'll make our root element an nav and we'll go ahead and give it an id of Sidebar Navigation- which we'll be using later. And then we want to create a ul element inside of our nav, and that will ultimately be where our different menu options render!

<!-- ~/components/SidebarNav.vue -->

<template>
  <nav id="Sidebar Navigation">
    <ul>

    </ul>
  </nav>
</template>

Your markup should look like this.

From there, we're going to move into our script tag in our SidebarNav.vue-- and what we're doing here is just dropping in some static data that we'll use to pass to our components that will then build out our navigation menu.

Copy & paste the code below in your SidebarNav.vue

// ~/components/SidebarNav.vue

<script>
export default {
  data() {
    return {
      navigation: [
        {
          title: "Menu 1",
          link: "/",
        },
        {
          title: "Menu 2",
          submenus: [
            {
              title: "Submenu 1",
              link: "/",
            },
            {
              title: "Submenu 2",
              link: "/",
            },
            {
              title: "Submenu 3",
              submenus: [
                {
                  title: "Subsubmenu 1",
                  link: "/",
                },
                {
                  title: "Subsubmenu 2",
                  link: "/",
                },
              ],
            },
          ],
        },
      ],
    };
  }
};
</script>

Next, we're going to place a component (that doesn't exist yet, we'll build that next) inside of the ul, let's call it BaseMenu.

What we'll do here is v-for over the items in the navigation data we just created and we're going to pass each item it loops over into BaseMenu as a prop.

We're also going to pass in a prop of depth and we'll set it at zero for this base level. Now, we're not actually going to do anything with the depth prop- but I've found it makes it tremendously easier to track which component is at which level once you get into the recursion side of things.

It's been super helpful in debugging too. You know there's an issue somewhere you see something with a depth of 1 or higher at your root level.

So, let's add our BaseMenu in.

// ~/components/SidebarNav.vue

<template>
  <nav id="Sidebar Navigation">
    <ul>
      <BaseMenu
        v-for="(menu, index) in navigation"
        :menu="menu"
        :depth="0"
        :key="index"
      />
    </ul>
  </nav>
</template>

Building the First Recursive Level

The piece we're building next is going to be two things.

First, it's going to be the li within our ul that we just built in our SidebarNav.vue. And secondly, it's going to be the layer that determines whether to render another recursive menu system or just spit out a link.

So, lets' create a BaseMenu.vue component in our components folder, and lets scaffold out our vue file with the root element being an li.

Let's also declare the props we know this component will be expecting, based on the work we just did in the SidebarNav.

We know there are two props coming in, menu and depth. menu is a type of object and we want it to be required. depth is a number, and we want it to be required as well.

// ~/components/BaseMenu.vue

<template>
  <li>
  </li>
</template>

<script>
export default {
  props: {
    menu: {
      type: Object,
      required: true,
    },
    depth: {
      type: Number,
      required: true,
    },
  },
};
</script>

Let's take a step back for a second and look at what we need this to do next.

We know part two of this is that it needs to decide whether to render another menu system or a link. Knowing that, we know we can use a v-if.

If we take a look at the data we added in our SidebarNav component, you can see that there is only ever a submenus array or a link- which is a just a string- but there is never both a single menu object.

We can use that to determine which element to render. If there is a submenus array = give us another menu level, if not = give us a link.

That could look something like this.

<!-- ~/components/BaseMenu.vue -->

<template>
  <li>
    <template v-if="menu.submenus">
    </template>

    <nuxt-link v-else>
    </nuxt-link>
  </li>
</template>

Looking back at our data again, we can see that if a menu object is a link, then it has two keys: title, and link.

Let's use that to finish building out the link part of our BaseMenu

<!-- ~/components/BaseMenu.vue -->

<template>
  <li>
    <template v-if="menu.submenus">
    </template>

    <nuxt-link
      v-else
      :to="menu.link"
      :id="menu.title.toLowerCase().replace(' ', '-')"
    >
      {{ menu.title }
    </nuxt-link>
  </li>
</template>

You'll notice I did a little javascript-ing on the ID, it's just lowercasing and replacing spaces with hyphens- this step is completely optional. It's just the pattern I prefer for id's.

Now all that's left is to add a bit that will soon become our actual submenu that get's rendered when necessary.

Let's add a component BaseMenuItem in our v-if statement, and we'll pass it the same props that our BaseMenu component uses- which will be menu (and that's an object) and depth (which is a number).

Your BaseMenu component should be looking something like this.

// ~/components/BaseMenu.vue

<template>
  <li>
    <template v-if="menu.submenus">
      <BaseMenuItem
        :menu="menu"
        :depth="depth + 1"
      />
    </template>
    <nuxt-link
      v-else
      :id="menu.title.toLowerCase().replace(' ', '-')"
      :to="menu.link"
    >
      {{ menu.title }}
    </nuxt-link>
  </li>
</template>

<script>
export default {
  props: {
    menu: {
      type: Object,
      required: true,
    },
    depth: {
      type: Number,
      required: true,
    },
  },
};
</script>

Now we're ready to build out the BaseMenuItem component we just added to project.

Building the accessible menu

This is the part of the project that was built based on this tutorial by Heydon Pickering for Smashing Magazine. The write-up originally appeared in his book "Inclusive Components".

Let's outline some things this component needs before we jump into the code.

The Basics

We need a button to show/hide a menu's submenu (we know this because we're building a nested menu system)
We need a ul that shows/hides when it's parent button is clicked.
We need a method (or function) to handle the click of parent button

Accessibility needs
Again, if you want a detailed breakdown of everything a11y about this system, I highly suggest reading through Heydon's write-up

We need the aria-haspopup attribute on our parent button. This allows assistive technologies to inform the user that clicking this button will reveal more content.
We need the aria-expanded attribute on our parent button. This allows assistive technologies to inform the user whether or not the menu is currently open.
We need the aria-controls attribute on our parent button. The intention of aria-controls is to help screen reader users navigate from a controlling element to a controlled element. It's only available in JAWS screen readers, but some users may expect it.
Pressing the esc key should close the currently focused menu
Opening a menu should focus the first element within it.

This may read as if it's a lot, but it really isn't that much work.

The structure

We can start by laying out the basic structure of our component, and we'll incrementally add functionality and accessibility as we go.

So, we'll start with a basic Vue component that has a button and a ul in it. We can also declare the props we know are going to be passed in here- remember that's going to be menu and number, same as our previous component.

We'll also want to set the key of isOpen in our data, so we'll have a something to toggle with out button click and we can also use that value to determine when to show our submenu.

At this point, we can deduce that the text in our button will be the title of the menu that's passed into it. Knowing that, we can go ahead and set that up as well.

// ~/components/BaseMenuItem.vue

<template>
  <div>
    <button>
      {{ menu.title }}
    </button>

    <ul>
    </ul>
  </div>
</template>

<script>
export default {
  data() {
    return {
      isOpen: false,
    };
  },
  props: {
    depth: {
      type: Number,
      required: true,
    },
    menu: {
      type: Object,
      required: true,
    },
  },
};
</script>

Next we can get started making this menu do stuff. Let's add a click event to our button that calls a toggleMenu function.

// ~/components/BaseMenuItem.vue

...
<button @click.prevent="toggleMenu">
  {{ menu.title }}
</buttton>
...

And in our methods, we'll create out toggleMenu function. All it's going to do for now is toggle or isOpen key to it's opposite value

// ~/components/BaseMenuItem.vue

...
<script>
export default {
  ...
  methods: {
    toggleMenu() {
      this.isOpen = !this.isOpen;
    }
  }
}
</script>
...

Now that that is in place, we can add a v-show to our ul and dynamically render it based on the button click.

Another thing we'll do is create a computed property that is just going to sanitize an ID we can use for the parent button and submenus.

Drop the text hello into your ul and fire the app up with yarn dev or npm run dev and you should find two parent items, one of which is a button that reveals hello when you click it!

So far it's working!

// ~/components/BaseMenuItem.vue

<template>
  <div>
    <button
      :id="menuId"
      @click.prevent="toggleMenu(menu)"
    >
      {{ menu.title }}
    </button>

    <ul
      v-show="isOpen"
      :id="submenuId"
    >
     Hello
    </ul>
  </div>
</template>

<script>
export default {
  data() {
    return {
      isOpen: false,
    }
  },
  computed: {
    menuId() {
      return this.menu.title.toLowerCase().replace(' ', '-')
    },
    submenuId() {
      return `${this.menu.title.toLowerCase().replace(' ', '-')}-submenu`
    }
  },
  methods: {
    toggleMenu() {
      this.isOpen = !this.isOpen
    }
  }
}
</script>

Your BaseMenuItem component should be looking like this right now.

Adding Aria Attributes

Revisiting our list from above, there's a few aria attributes we want to add to progressively enhance the experience for our assisted users.

We need the aria-haspopup attribute on our parent button. This allows assistive technologies to inform the user that clicking this button will reveal more content.
We need the aria-expanded attribute on our parent button. This allows assistive technologies to inform the user whether or not the menu is currently open.
We need the aria-controls attribute on our parent button. The intention of aria-controls is to help screen reader users navigate from a controlling element to a controlled element. It's only available in JAWS screen readers, but some users may expect it.

On our button, let's add the aria-haspopup="true" attribute, and we'll also add :aria-expanded="isOpen.toString()" as well.

We're adding aria-expanded as a dynamic attribute and we're setting it to the value of our isOpen data point and converting it to a string. We're doing this because the attribute would be removed altogether when isOpen was false, and that's not what we want.

The last aria attribute we'll add to our button is :aria-controls="submenuId". This is so any screen readers will know which menu this button controls.

// ~/components/BaseMenuItem.vue

...
<button
 :id="menuId"
 @click.prevent="toggleMenu(menu)"
 aria-haspopup="true"
 :aria-expanded="isOpen.toString()"
 :aria-controls="submenuId"
>
 {{ menu.title }}
</button>
...

Extending Accessibility

There's two more things we need to add to our menu item for it to be complete.

Pressing the esc key should close the currently focused menu
Opening a menu should focus the first element within it.

There's three steps to being able to close the currently focused menu. We need to (1) write a closeMenu method, (2) add a key listener to our ul that holds the menu, and (3) and a ref to our button.

So, let's add ref="menuButtonRef" to our button, and then let's create a closeMenu method that's going to set this.isOpen = false and we'll also focus our new button ref with this.$refs.menuButtonRef.focus().

Lastly, let's add a key listener to our ul with @keydown.esc.stop="closeMenu".

And that should have your currently focused menu closing! If you want to see something fun, remove the .stop and close a menu 😁.

// ~/components/BaseMenuItem.vue

<template>
  <div>
    <button
      :id="menuId"
      ref="menuButtonRef"
      @click.prevent="toggleMenu(menu)"
      aria-haspopup="true"
      :aria-expanded="isOpen.toString()"
      :aria-controls="submenuId"
    >
      {{ menu.title }}
    </button>

    <ul
      v-show="isOpen"
      :id="submenuId"
      @keydown.esc.stop="closeMenu"
    >
     Hello
    </ul>
  </div>
</template>

<script>
export default {
  data() {
    return {
      isOpen: false,
    }
  },
  computed: {
    menuId() {
      return this.menu.title.toLowerCase().replace(' ', '-')
    },
    submenuId() {
      return `${this.menu.title.toLowerCase().replace(' ', '-')}-submenu`
    }
  },
  methods: {
    toggleMenu() {
      this.isOpen = !this.isOpen
    },
    closeMenu() {
      this.isOpen = false
      this.$refs.menuButtonRef?.focus()
  }
}
</script>

If it's not working, it may be because we haven't focused any menus when we're opening them. Let's do that now!

Focusing first elements

By default, an accessible menu should focus the first element within it once it's opened.

To do this, we'll need to query for all clickable items within a menu from its ID and then focus the first one.

So, in our toggleMenu method we want to write an if statement to check if isOpen is true or not. If it is, then that's where we want to focus our first item.

One additional step we need to do, is utilize Vue's nextTick- which will allow us to ensure that we're checking the value of isOpen after it's been updated.

Inside of our nextTick we'll get our submenu by its ID with const subMenu = document.getElementById(this.submenuId); and then narrow that down to the first one with const firstItem = subMenu.querySelector("a, button");.

After that, we just call firstItem?.focus() and now our menu will auto focus its first item when opened!

// ~/components/BaseMenuItem.vue

...
methods: {
  toggleMenu() {
    this.isOpen = !this.isOpen

    if(this.isOpen) {
      this.$nextTick(() => {
        const submenu = document.getElementById(this.submenuId)
        const firstItem = submenu.querySelector("a, button")
        firstItem?.focus()
    })
  }
}
...

We also want to focus the initial trigger for the menu when it's closed. So we'll write a second if statement checking for !this.isOpen and add the same this.$refs.menuButtonRef that our closeMenu method has

// ~/components/BaseMenuItem.vue

...
methods: {
  toggleMenu() {
    this.isOpen = !this.isOpen

    if(this.isOpen) {
      this.$nextTick(() => {
        const submenu = document.getElementById(this.submenuId)
        const firstItem = submenu.querySelector("a, button")
        firstItem?.focus()
      })
    }

    if(!this.isOpen) {
      this.$nextTick(() => {
        this.$refs.menuButtonRef?.focus()
      })
    }
  },
}
...

Our menu is fully functioning now!! We're not done just yet, but all our base functionality is now in place!

We're officially done with our BaseMenuItem.vue component.

Arrow Key Navigation

The last step here is to allow users, assisted and non-assisted, to navigate up and down the menu tree with the arrow keys.

A lot of what we need is already in place, so all we're doing is writing a key event listener on the top level of our menu.

So, jumping back to our SidebarNav.vue component, let's add a @keydown="handleKeyPress" to our nav element.

// ~/components/SidebarNav.vue

...
<nav id="Sidebar Navigation" @keydown="handleKeyPress">
  <ul>
    <BaseMenu
      v-for="(menu, index) in navigation"
      :menu="menu"
      :key="index"
      :depth="0"
    />
  </ul>
</nav>
...

Next, we'll write our handleKeyPress method.

Inside this method, we'll need to do a few things.

Get our nav element by ID const navEl = document.getElementById("Sidebar Navigation");
Get all focusable elements in our nav const focusableElements = navEl.querySelectorAll(["a", "button"]);
Convert the returned nodelist to an array const focusableElementsArr = Array.from(focusableElements);
Get the active element on the page const activeEl = document.activeElement;
Find the index of our active element const activeElIndex = focusableElementsArr.findIndex( (f) => f.id === activeEl.id );
Find the last index of our focusable elements const lastIdx = focusableElementsArr.length - 1;

// ~/components/SidebarNav.vue

methods: {
  handleKeyPress(e) {
    const navEl = document.getElementById("Sidebar Navigation");

    const focusableElements = navEl.querySelectorAll(["a", "button"]);

    const focusableElementsArr = Array.from(focusableElements);

    const activeEl = document.activeElement;

    const activeElIndex = focusableElementsArr.findIndex(
      (f) => f.id === activeEl.id
    );
    const lastIdx = focusableElementsArr.length - 1;
  },
},

Next, we'll write two if statements. One for ArrowUp and one for ArrowDown. If our user is on the first element and presses the up key, our first element will retain focus- but if they hit the down key, it will move them down one element.

And the inverse will happen for the last element.

// ~/components/SidebarNav.vue

methods: {
  handleKeyPress(e) {
    const navEl = document.getElementById("Sidebar Navigation");

    const focusableElements = navEl.querySelectorAll(["a", "button"]);

    const focusableElementsArr = Array.from(focusableElements);

    const activeEl = document.activeElement;

    const activeElIndex = focusableElementsArr.findIndex(
      (f) => f.id === activeEl.id
    );
    const lastIdx = focusableElementsArr.length - 1;

    if (e.key === "ArrowUp") {
      activeElIndex <= 0
        ? focusableElementsArr[0].focus()
        : focusableElementsArr[activeElIndex - 1].focus();
    }
    if (e.key === "ArrowDown") {
      activeElIndex >= lastIdx
        ? focusableElementsArr[lastIdx].focus()
        : focusableElementsArr[activeElIndex + 1].focus();
    }
  },
},

Now jump over to your browser, open up some menus, and arrow key up and down!

Summary

This walkthrough was bit long-winded, but- as you saw- there are a lot of moving parts to consider when building a system like this.

The good news? The system will work for an indefinite level of menus, provided the design and screen real-estate allow for it. The only limits aren't tied to the recursive system itself.

Another thing to note, the accessibility of it all wasn't difficult or complex. It took very little to take this from a "menu system" to an "accessible menu system", and a lot of base accessibility features are equally as simple to get in place.

Accessibility isn't an enhancement that should be place in the backlog. It's a core fundamental that should be accounted for in scoping, planning, and implementation.

Thank you for making it this far! These a11y write-ups have been huge learning experiences for me and I hope to bring more in 2022.

Disclaimer: This was built with happy path data structures. You may have to write some additional code to get your data structured how you want it. In learning this system, I had to write yet another recursive function that would scaffold a flat chunk of data into the nested levels needed.

Basic accessibility features you should ALWAYS implement

Drew Clements — Mon, 15 Nov 2021 20:46:07 +0000

Accessibility on the web has always been important, but it's only been in the last <10 years that a true emphasis on it has come about. Legally, it's against the law to build a site or application that doesn't adhere to the Web Content Accessibility Guidelines.

Purple Cow Agency has this great article where they answer some of the questions around accessibility. They do a great job of answering those questions and giving an easier-to-digest version of WCAG 2.1

According to Title III of the Americans with Disabilities Act (ADA), all public areas must accommodate people with disabilities—this includes your website. Though the ADA doesn’t mention websites anywhere, the US courts interpret “places of public accommodation” to include the public domain of the internet.

Today, we're going to look at 3 commonly overlooked accessibility patterns you can add to your projects to get them a few steps closer to be fully accessible compliant!

Accessible Modals

Modals are a very common design pattern across the web today. You see them for newsletter signups, requests for cookie tracking, and- believe it or not- mobile menus!

Slide-out, pop-out, revealing- whatever you want to call them- mobile menus hidden behind an icon toggle are technically modals, and they should be treated as such!

They're definitely good patterns to pull user's attention to specific content (especially when they quite literally block other content)- but there are some features they need to be considered a11y compliant.

On open, autofocus the first focusable element in the modal dialog.
While open, limit mouse and keyboard focusability to only the content within the modal dialog.
On close, autofocus the element that initially triggered the modal to open.
When opened, the modal dialog and content should be appended to the end of the DOM.

Now, there are a lot of ways to accomplish this. I just wrote an article about how to do this in Vue, if you're interested in implementing this into your Vue project.

Accessible Menus (navigation submenus)

Collapsible/hover-able navigation menus are another pattern that eat the web up. They make sense. Designers/marketers want to save space above the fold, and they do that by hiding submenu items underneath or behind their parent menu item.

However, this exposes a lot of room for accessibility errors to come into play. It's easy enough to reveal a menu with a mouse hover, but what about for people who use assistive technologies and navigate with their keyboard?

Does .menu-item:hover apply to when a submenu item is keyboard focused? No, it doesn't. That leaves your assisted users possibly reading top-level non-clickable menu items that go nowhere and being given no context as to why they don't go anywhere.

Heydon Pickering has a fantastic Smashing Mag article where he walks through, in detail, how to build an accessible compliant menu and submenu navigation system.

Semantically correct HTML

The last, and surprising thing, on this is semantically correct HTML. It's surprising that this one needs to be mentioned, because structurally sound HTML should be the default for anyone coming out of a bootcamp or grad school- but, somehow, it isn't.

Getting your HTML right can have a huge effect on your assisted users experience. It's very common to wrap everything in a div, and before you know it, you have div soup.

HTML has specific elements with some accessibility baked into them. So, why not use them?

We all know about the header and footer, but how often do you forget to wrap your main content between the two in the <main> tag? I know I have, more than I care to admit.

There are other HTML patterns to remember too:

Only have a single <h1> tag per page
- There was a rumor/myth that perpetuated pretty far into the tech community that <section> tags reset the page reader and that you could have multiple H1s on a page. This isn't true. There was a proposal for such, but it was never implemented.
Keep your heading tags in order
- You should only use your heading tags in an ascending order (by number). H1's should only be followed by H2's. H2's should only be followed by H3's. H3's should only be followed by H4's. Rinse and repeat.
Separate different generic content areas with <section> tags with proper headings. This lets your user know the content they're about to consume (while it may be related) is separate from what they just engaged with.
Use <article> tags to separate content that could exist independently of the rest of the content, e.g., forum post, a blog entry, etc..

There is a lot more that goes into writing proper HTML. It would take an entire novel (and some do exist) on how to write each section the right way, but keep things like this in mind when you're building, and overtime, you'll probably notice the quality of your HTML increasing while the effort to do so decreases with each project!

Here's a list of HTML elements you can use to check when and if you're using the right element.

A simple page could look something like this:

<body>
  <header>
    <nav>
      <ul>
       <li>
        <a href="/">Menu Item</a>
       </li>
      </ul>
    </nav>
  </header>

  <main>
    <h1>Page Title</h1>
    <article>
      <section>
        <h2>Section title</h2>
        <p>This would be your content description area. 
      </section>
    </article>

    <aside>
      <h2>Side Navigation</h2>

      <ul>
       <li>
        <a href="/">Menu Item</a>
       </li>
      </ul>
    </aside>
  </main>

  <footer>
    <nav>
      <ul>
       <li>
        <a href="/">Menu Item</a>
       </li>
      </ul>
    </nav>
  </footer>
</body>

Summary

Accessibility is important. Not only to those who need it, but also for your business. There's an entire discussion around how better accessibility can increase traffic, revenue, yadda yadda- but let's put it in numbers pertaining to your business.

Fines up to $55,000 for the first violation and $110,000 for each subsequent violation.
Those who receive Federal funding could have those funds revoked for being in non-compliance. It’s not anything you want to ignore.
--GetADAAccessible.com

Holding your company card a little closer right now? I would be.

I'll be the first to admit that I build a lot of websites incredibly incorrectly, from an HTML perspective. But the growth comes from knowing you can do better, and then striving to do so. If you're reading this article, then you're on that right path!

As developers, it's our responsibility to make the knowledge and entertainment on the web available and accessible to everyone. I try to take that responsibility seriously. Do you?

Building an Accessible Modal in Vue.

Drew Clements — Mon, 15 Nov 2021 13:32:33 +0000

Modals are a very common design element across the web today. However, a lot of websites exclude people using assistive-technologies when building their modals. This can lead to very poor and frustrating experiences for those people.

I'll be the first to admit that I have built dozens of these without building in accessible patterns. In fact, in my 2-3 years as a developer, I can say with confidence that only two of those were a11y compliant.

In this article, we're going to look at how to build a reusable and a11y compliant modal component in Vue (Nuxt). Once we're through, you'll be able to take this component/pattern to any of your other projects. This article assumes at least a foundational understanding of Vue.

Setting up the project

We're going to build this example in Nuxt. So, to get things started, we'll run npx create-nuxt-app a11y-tuts in our terminal to generate a Nuxt project. * Make sure you're in the correct directory where you want your project to live. *

It's going to ask you a few questions about config setups. Set those however you like. Here is how I answered

Programming Language: Javascript
Package Manager: Npm
UI Framework: None (I know, crazy. Right?)
Nuxt.js Modules: Axios
Linting Tools: ESLint
Testing Framework: None
Rendering Mode: Universal (SSR / SSG)
Deployment Target: Static (Static/Jamstack hosting)
Development Tools: jsconfig.json

Now that we have that complete, let's set up a simple scaffold for our app.

Scaffolding out the HTML

First thing is to delete the Tutorial.vue and NuxtLogo.vue files in the components/ directory. Next, we'll add SiteHeader.vue and SiteFooter.vue into that components folder.

We're not going to build out a full header and footer for this, but we do need at least one focusable element in each for demonstration purposes later.

<!-- components/SiteHeader.vue -->

<template>
  <header>
    <nuxt-link to="/">Header Link</nuxt-link>
  </header>
</template>

<!-- components/SiteFooter.vue -->

<template>
  <footer>
    <nuxt-link to="/">Footer Link</nuxt-link>
  </footer>
</template>

From there, we'll create a layouts folder in the root of our project and add a default.vue component. In that file, we're going to import our header and footer components and do a little CSS to get some layout going.

Quick CSS for some layout

We're setting our .site-wrapper element to a display:flex, then targeting our header and footer elements to set their flex-grow: 0 and our main element to flex-grow: 1. This ensures that the footer is always at the bottom of the page and that our <main> content area takes up as much of the screen as possible.

// layouts/default.vue

<template>
  <div class="site-wrapper">
    <SiteHeader />
    <main>
      <nuxt />
    </main>
    <SiteFooter />
  </div>
</template>

<script>
export default {};
</script>

<style>
body {
  overflow-x: hidden;
  margin: 0 !important;
}

.site-wrapper {
  min-height: 100vh;
  display: flex;
  flex-direction: column;
}

header,
footer {
  flex-grow: 0;
}

main {
  display: flex;
  flex-grow: 1;
}
</style>

Now we're ready to get to the fun part!

Key Points

Before we jump straight into building the component, let's first make a quick list of the specs we need to hit for this component to be a11y compliant.

1. On open, focus is initially set on the close button.
2. On close, focus is placed back on the element that triggered the modal.
3. When open, focusable elements outside of the modal are unreachable through keyboard or mouse interactivity.
4. Pressing the 'Esc' key closes the modal.

This is a short list, at a glance, but these 4 items are paramount to improving user experience for those using assistive technologies.

Building the Modal Component

The next step is to create a BaseModal component. You can name it whatever you like. I like to build my apps based on the Vue Enterprise Boilerplate- which is where the name BaseModal comes in.

You can read more about it in the previous link, but the quick summary is that you have a level of reusable dumb base components, in that they- for the most part- don't handle any data themselves. They simply emit events or values and provide a foundation of your app styles (BaseButton, BaseInput, etc..) that you can then extend as needed with confidence that all of your elements share a common design pattern. But, I digress.

The Modal Scaffold

There are four key parts our modal will start with: an open button, a close button, the background (the part that's usually a dark semi-transparent piece), and the content area itself.

With that in mind, let's put it together. We'll go ahead and mock some content in place as well and start styling stuff out.

// components/BaseModal.vue

<template>
  <button type="button">
    Open Modal
    <div v-if="isOpen" class="modal-wrapper">
      <div class="modal-content">
        <button type="button">Close Modal</button>
        <div>
          <h2>Here is some modal content!</h2>
        </div>
      </div>
    </div>
  </button>
</template>

<script>
export default {};
</script>

<style scoped></style>

You'll notice here that the outermost element is a button itself. That's done so that later, when we extend the reusability with a slot, you'll be able wrap most anything in this BaseModal component and have it trigger a modal. Images, buttons, cards- it's relatively endless.

Modal Styling

Styling the background

We want the background to take up the entirety of the screen, and in the future we'll also want to disable any background scrolling too.

Knowing that, we can set the position to be fixed on the .modal-wrapper class and the top, right, bottom, and left values set to 0. We'll throw a semi-transparent black background color on there too.

Remember, this is in Vue so we can add this CSS in our single file component.

/*-- components/BaseModal --*/

<style scoped>
.modal-wrapper {
  position: fixed;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  background-color: rgba(1, 1, 1, 0.75);
}
</style>

Styling the content area

And to center up our .modal-content area we'll set the display to flex on our .modal-wrapper- as well as setting align-items and justify-content to center. We'll also drop a background color of white and add some padding of 3rem to our .modal-content.

/*-- components/BaseModal --*/

<style scoped>
.modal-wrapper {
  position: fixed;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  background-color: rgba(1, 1, 1, 0.75);
  display: flex;
  align-items: center;
  justify-content: center;
}

.modal-content {
  background-color: white;
  padding: 3rem;
}
</style>

Your modal should be looking something like this. It isn't the "prettiest" thing, but we're going for function here.

Building the Modal Functionality

Here's where we get into the meaty parts of it. This is where the amount of moving parts scales up a bit.

We need a few things to happen here. Our open button should trigger the modal. The close button should close it, but we also have those other specs we need to be sure we hit as we build this out.

Setting up Vuex

We're going to use Vuex here to keep track of when a modal is open anywhere on the site. Doing this will allow us to trigger other key events up the component tree.

So, let's start by creating a modal.js file in our /store directory. Now, this file could get more complex than our example, especially if you got into dealing with multiple modals on a single page and wanting to know not only if a modal was open, but also which modal.

For our simple usage here, we'll init the state for pageHasModalOpen and default it to false, and we'll create a mutation and call it isModalOpen. We'll use the mutation to update when a modal is triggered anywhere in the app

// store/modal.js

export const state = () => ({
  pageHasModalOpen: false,
})

export const mutations = {
  isModalOpen(state, isModalOpen) {
    state.pageHasModalOpen = isModalOpen
  }
}

Triggering Events

With our Vuex state in place, we now have a place to globally store when a modal is open. Now, we need to make our BaseModal component aware of that state.

So, back in our BaseModal component, let's import the mapState from Vuex and then use a computed property to get access to our modal data

// components/BaseModal.vue

<script>
import { mapState } from "vuex";

export default {
  computed: {
    ...mapState("modal", ["pageHasModalOpen"]),
  },
};
</script>

In the instance that we have multiple modals on a single page, we'll want each to respond to if it specifically is open- and not our global state. We'll do that by creating an isOpen property in our data and setting the initial value to false.

// components/BaseModal.vue

<script>
import { mapState } from "vuex";

export default {
  data() {
    return {
      isOpen: false
    }
  },
  computed: {
    ...mapState("modal", ["pageHasModalOpen"]),
  },
};
</script>

Before we go any further here, let's jump up to our template and add some click events and v-ifs so we can start getting some pieces reacting.

We'll add an openModal call for our open modal button, closeModal for the close modal button, and lastly, we'll add v-if="isOpen" to our div that has the .modal-wrapper class. This makes it so that our background and content layer won't reveal itself unless it has been explicitly directed to by user input.

// components/BaseModal.vue

<template>
  <button @click="openModal" type="button">
    Open Modal
    <div v-if="isOpen" class="modal-wrapper">
      <div class="modal-content">
        <button @click="closeModal" type="button">Close Modal</button>
        <div>
          <h2>Here is some modal content!</h2>
        </div>
      </div>
    </div>
  </button>
</template>

Now lets write our openModal and closeModal methods and get our buttons actually doing something!

Our open and close modal methods will be almost identical, save for the fact that they'll be sending the opposite boolean value.

Our openModal method will first set our local isOpen to true and then we'll fire a request to our vuex store to update isModalOpen to true as well.

And we can go ahead and put our closeModal method in here too and just replace any instance of true to false

// components/BaseModal.vue

methods: {
  async openModal() {
    this.isOpen = true;
    await this.$store.commit("modal/isModalOpen", true);
  },
  async closeModal() {
    this.isOpen = false;
    await this.$store.commit("modal/isModalOpen", false);
  },
},

Now, let's do some clicking! Open modal works! Close modal... doesn't?!

That's because we need to utilize a portal to actually send our modal content outside of that wrapping button, because it's currently swallowing any click event that happens.

There's a lib that allows us to do this for Nuxt, but it's actually a native thing in Vue 3! So, let's npm install portal-vue and then add it into our modules in our nuxt.config.js

// nuxt.config.js

modules: [
  'portal-vue/nuxt'
],

Now there's two things we need to do. Import and use portal in our BaseModal component, and also set up a portal-target back in our default.vue layout.

Let's get the Portal component imported and registered in our BaseModal and then let's wrap the div with our v-if on it in a <Portal> tag (remember to close it too), move the v-if to the Portal element and add an attribute of to="modal"

Your BaseModal component should look something like this right now.

// component/BaseModal.vue

<template>
  <button @click="openModal" type="button">
    Open Modal
    <Portal v-if="isOpen" to="modal">
      <div class="modal-wrapper">
        <div class="modal-content">
          <button @click="closeModal" type="button">
            Close Modal
          </button>
          <div>
            <h2>Here is some modal content!</h2>
          </div>
        </div>
      </div>
    </Portal>
  </button>
</template>

<script>
import { mapState } from "vuex";
import { Portal } from "portal-vue";

export default {
  components: {
    Portal,
  },
  data() {
    return {
      isOpen: false,
    };
  },
  computed: {
    ...mapState("modal", ["pageHasModalOpen"]),
  },
  methods: {
    async openModal() {
      this.isOpen = true;
      await this.$store.commit("modal/isModalOpen", true);
    },
    async closeModal() {
      this.isOpen = false;
      await this.$store.commit("modal/isModalOpen", false);
    },
  },
};
</script>

<style scoped>
.modal-wrapper {
  position: fixed;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  background-color: rgba(1, 1, 1, 0.75);
  display: flex;
  align-items: center;
  justify-content: center;
}

.modal-content {
  background-color: white;
  padding: 3rem;
}
</style>

Let's jump back to our default.vue and set up our portal-target and give it a name of modal.

// layouts/default.vue

<template>
  <div class="site-wrapper">
    <SiteHeader />
    <main>
      <nuxt />
    </main>
    <SiteFooter />

    <PortalTarget name="modal"></PortalTarget>
  </div>
</template>

Now try opening and closing again. It should work both ways!! Congrats! Now let's start checking off some of the accessibility specs.

Adding in Accessibility

Let's bring back our list from earlier and we'll just work our way down it until we're through!!

On open, focus is initially set on the close button.

The good part is the clicking/triggering stuff is mostly done and we're just extending functionality.

Let's utilize refs to grab and focus the different elements. So, on our close modal button- since that's the one we need to focus on open- let's add the ref="closeButtonRef" to it.

// components/BaseModal.vue

<template>
  <button @click="openModal" type="button">
    Open Modal
    <Portal v-if="isOpen" to="modal">
      <div class="modal-wrapper">
        <div class="modal-content">
          <button @click="closeModal" ref="closeButtonRef" type="button">
            Close Modal
          </button>
          <div>
            <h2>Here is some modal content!</h2>
          </div>
        </div>
      </div>
    </Portal>
  </button>
</template>

Now, back down in our openModal method let's target that ref and focus it using javascript. Directly after the $store.commit let's add two await this.$nextTick()- and to be completely honest, I have absolutely no idea why two are needed, but it works and I haven't seen it done any other way. After that, we'll just target our ref and call the .focus() method on it.

// components/BaseModal.vue

async openModal() {
  this.isOpen = true;
  await this.$store.commit("modal/isModalOpen", true);
  await this.$nextTick();
  await this.$nextTick();
  this.$refs.closeButtonRef?.focus()
},

Now your close button should be focused when the modal is open. You may be missing some styles to make that apparent if you're following this one to one- but you can add some CSS and target the buttons focus state to make it more apparent

/*-- components/BaseModal.vue

.modal-content button:focus {
  background-color: red;
  color: white;
}

On close, focus is placed back on the element that triggered the modal.

The pattern is very similar for targeting the open button when the modal is closed. We'll add a ref to the open modal button, the $nextTicks() after the store.commit call, and lastly targeting the ref and calling the .focus() method.

// components/BaseModal.vue

async closeModal() {
  this.isOpen = false;
  await this.$store.commit("modal/isModalOpen", false);
  await this.$nextTick();
  await this.$nextTick();
  this.$refs.openButtonRef?.focus()
},

Add an open-button class to the button and add the selector to your :focus CSS and you'll get to see it working!!

// components/BaseModal.vue

.open-button:focus,
.modal-content button:focus {
  background-color: red;
  color: white;
}

When open, focusable elements outside of the modal are unreachable through keyboard or mouse interactivity.

Thanks to some really awesome packages, we no longer have to .querySelectorAll and jump through a bunch of javascript hoops to trap focus for modals.

We'll be using wicg-inert for our project. So let's run npm install wicg-inert in our terminal to get it into our project.

From there, we'll create a plugin module for it called wicg-inert.client.js- we're adding .client because we only want this to run on the client side.

// plugins/wicg-inert.client.js

import 'wicg-inert'

And now we'll register that plugin in our nuxt.config.js

// nuxt.config.js

plugins: ["~/plugins/wicg-inert.client.js"],

Now that we have access to the inert plugin, let's jump to our default.vue file and put it to use!

The idea of making something inert is essentially making any content (focusable or not) unreachable- and that's exactly what we need.

If you open your modal now and tab or shft + tab around, you'll see we can still actually get to everything behind our dark background. And that's what this is stopping.

First, we need to import our Vuex state again, because that's what we'll use to determine when to apply the inert attribute. So, similar to what we did in our BaseModal component, we'll import mapState from Vuex and then use a computed property to expose the value we need.

// layouts/default.vue

<script>
import { mapState } from "vuex";

export default {
  computed: {
    ...mapState("modal", ["pageHasModalOpen"]),
  },
};
</script>

From here, we'll add the inert attribute to our <SiteHeader>, <main>, and <SiteFooter> elements with the value pageHasModalOpen. So, when it sees that a modal is open, it will apply inert and block off any content within those elements.

// layouts/default.vue

<template>
  <div class="site-wrapper">
    <SiteHeader :inert="pageHasModalOpen" />
    <main :inert="pageHasModalOpen">
      <nuxt />
    </main>
    <SiteFooter :inert="pageHasModalOpen" />

    <PortalTarget name="modal"></PortalTarget>
  </div>
</template>

Viola! Open your modal and try to tab around. If you're following this one to one, you'll see you can only tab between the URL bar and the close button element. That's because everything is being hidden with inert!

Pressing the 'Esc' key closes the modal.

We've done a lot of work so far, and all the kudos to you for making it this far. I know I can be long-winded and I appreciate your continued reading!

One of our last moves to make this accessible is to close the modal if someone presses the esc key. Vue is super rad and gives us keybinding we can tap into to make this party incredibly easy.

Back in our BaseModal.vue, all we have to do is add @keydown.esc="closeModal" to our div with the .modal-wrapper class.

Boom! Another thing off the list. That actually concludes the accessible part of this write-up!!

Congrats! We built an accessible modal!

Named Slots for Reusability

Right now, all of our content is hardcoded into the component- but we can use Vue's named slots to make this a reusable component

Let's start by replacing our Open Modal text with <slot name="button" /> and our div just below our close button with <slot name="content" />.

Your template in BaseModal.vue should look something like this.

// components/BaseModal.vue

<template>
  <button
    class="open-button"
    @click="openModal"
    ref="openButtonRef"
    type="button"
  >
    <slot name="button" />
    <Portal v-if="isOpen" to="modal">
      <div class="modal-wrapper" @keydown.esc="closeModal">
        <div class="modal-content">
          <button @click="closeModal" ref="closeButtonRef" type="button">
            Close Modal
          </button>
          <slot name="content" />
        </div>
      </div>
    </Portal>
  </button>
</template>

From here, we can go back to our index.vue in our pages folder where we're using the BaseModal component and put our content back in there, targeting the named slots to make sure everything goes to the right spot.

// pages/index.vue

<template>
  <section>
    <BaseModal>
      <template v-slot:button>Open Modal</template>
      <template v-slot:content><h2>Here is some modal content.</h2></template>
    </BaseModal>
  </section>
</template>

And there you have it!! A reusable and accessibility compliant modal!

Wrapping Up

Well, I hope you enjoyed this write-up. What we did isn't that difficult or complex to build. It's all about knowing what the base a11y compliant specs are and at least making sure those are met. Fun fact, your mobile menu is a modal- build it as such!!

Hire Early. Believe Often.

Drew Clements — Mon, 25 Oct 2021 14:23:33 +0000

Hiring juniors has always been a subject that's close to my heart. If I had an avatar, he would be wearing a backpack. In that backpack would be a soapbox on the benefits of hiring juniors that I'd carry with me, ready to stand on at a moment's notice.

I think companies are missing out on absolute gold mines of programmers and talent for fear of their team velocity or bottom line.

In this article, I'm going to outline my personal thoughts on why hiring early-career devs could be one of the smartest moves a company could make.

And before you start angry typing in the comments, consider all of this, not with a "protect the company and its assets" mindset, but rather, an altruistic pay-it-forward way of thinking.

We are not here to push the cogs of the digital capitalist machine forward. We are here because we enjoy what we do, and we should make it a point to lift others up in their journey to do the same.

The Negatives

We'll get the downside stuff out of the way first. You could potentially list a lot of things that would be negatives towards hiring junior developers.

But, after meditating on this and discussing it with others, I've noticed that it really only boils down to THREE reasons.

Team/Product velocity
Increased potential for breaking production
Liable to leave after experience gained

At a glance, these are three strong reasons to not hire juniors. But are they, though?

Team/Product Velocity

One of the biggest arguments is that a junior will take more time to onboard and get familiar with the codebase. That may be true, but there is an onboarding cost for any developer brought on to a new team, and the difference between onboarding a senior and junior will likely be a much smaller percentage than you think.

Is 25% longer really that much of a difference in the grand scheme of things? Considering that you're offering your junior a potentially life-changing position? And 25% is being fairly generous.

Another argument is that they'll require more resources from the rest of the team with teaching, training, troubleshooting, and all of the dev stuff in between. Again, that's probably true, but consider the knowledge gained from both parties during any of those pairing sessions.

It's a win/win, because even if the senior developer knows exactly what's going on in their head, having to articulate it in a way that can be understood by someone else requires a deeper focus- and in many cases may even reveal something they themselves did not know on the subject.

Increase potential for breaking production

There's not much to say here. Yes, it's a possibility- for everyone.

Unit tests. CI/CD pipelines. Regression testing. Manual QA. Git history.

These are all things that negate, prevent and restore any breaks in production that most companies already have in place. The breaks are inevitable. Don't deny someone the opportunity to learn, grow, and contribute when the reason for the denial applies to everyone.

Liable to leave after experience gained

What company doesn't already expect this? A lot of companies already keep a steady flow of applications coming in because they expect literally this.

If you believe in your hires, be aggressive and pro-active at keeping their pay competitive and having consistent and open conversations on their growth- both from a performance and financial perspective. This one isn't even specific to juniors.

The Positives

I have a rather unorthodox view on hiring juniors that shape what my positives are. Here's a quick list them (from a company perspective):

Likely no bad-habits
Mold them into ideal developer for your team
Great checks for clear vs clever code
Incredibly ambitious
Thankful for the opportunity. Likely to become loyal employees.
Lower salary expectations

Hot take

Hire closer to the door. What do I mean by that? Hire people that have maybe explored a little react or vue, or insert framework here- but haven't really delved deep into any of them.

Find people who have some- and this is specific to front-end because that's the realm I come from- HTML, CSS, and Javascript knowledge, with maybe some cursory knowledge of the framework you'll be hiring them for, and give them a chance.

Why? For two reasons, mainly- and we'll get into specifics.

Less experience = less pay * more on this in a just bit
You could be changing their lives

With that said, let's get into specifics for the larger positives list and work our way down.

No Bad Habits

When you're hiring junior- and even more so if you're hiring closer to the door- they likely haven't built any bad habits that you or your team will have to train out of them.

If they do have any, it's very likely that they don't have a strong enough opinion to push back and insist on continuing that way.

I know bad hires exist and happen, but I've heard stories of senior devs leaving in as little as two weeks because they refused to follow their new job's style guide or workflow.

Mold Them into the Ideal Developer for Your Team

On the same note as the last point, because they have less experience and opinions- you can take that gap of knowledge and fill it with exactly what you need for them to be the ideal candidate for your team.

Your style guide, code formatting, tooling, etc... could be their default baseline. And that compounds to when they do have more experience and another developer is brought onto the team, guess who knows the tooling and style guide back to front and can guide new hires? Your recent (probably no-longer-junior) developer.

Great Checks for Clear vs Clever

What's one of the best ways to see if a function is complex for the sake of the flex? Put it in front of a junior developer and see if they can read what it's doing or find a less complicated way to achieve the same goal.

A simple "why don't we do it this way instead?" can reduce complexity and drastically improve maintainability and readability. Their suggestion doesn't always work. Sometimes the complexity is called for- but I've personally heard senior devs say "I've done it this (complicated) way for so long that I forgot you could even do it that other way."

Simpler code is easier to read, maintain, and handoff- why not add a solid check for that?

Incredibly Ambitious

This is an opinion based section

I have yet to meet a junior developer who wasn't willing to do (almost) anything to get that first or next job. "Oh, you're hiring for framework x? I don't know it- but give me a week and then we'll talk."

They're spending their nights and weekends grinding on Youtube, FreeCodeCamp, Egghead, Udemy, etc.. to give themselves and their families a new opportunity and possibly a new lease on life.

Imagine what they could do to your codebase with that drive and ambition. Imagine the new perspectives that would be brought to the table.

Thankful for the opportunity. Likely to Become Loyal Employees.

This goes hand-in-hand with the last section.

These juniors- at least the ones that I know- have been working tirelessly, for months and/or years to find that person that will take a chance on them and give them that life-changing break.

They will be so thankful for that opportunity- provided your culture doesn't suck, if it does, fix it- that they won't even consider looking at a job board or for other opportunities for a while.

Lower Salary Expectations

This is where it feels a little weird to talk about, but hear me out.

The closer to the door you hire, the lower the salary expectations will be. Closer to the door as in "just in the door of learning to code".

I'm not saying pay them unfairly. I'm saying pay them commensurate to their abilities. And there is a trade off here, but I feel the pro's listed above make the trade fair and beneficial for both.

So, your senior dev is hitting you for $120k+/yr. They have some of the same potential issues as juniors. Onboarding time, increased chance of breaking production, etc.. but they could have bad habits they're not willing to part ways with.

However, this junior is over here willing to take $60k/yr. They have enough understanding that will provide some forward momentum. No bad habits.

They're an unshaped blob of developer clay ready to take whatever shape you need them to.

That $60k/yr they're willing to take may seem like you're doing them wrong for paying so little (so pay them more 😉)- but that could very well be the most they've ever been offered in their life. Or, maybe it is less than they currently make, but the remote life and all of its benefits make it worth it for them.

On top of that, they'll go from learning in their spare time of a handful of hours a week to 6-8 hour days, 5 days a week.

Tell me you won't get your money back on that investment after 6 months of them working and learning full-time. They'd be beyond junior within 12 months- and arguably worth more than that initial $60k offer. So. Pay. Them. More.

Bake an aggressive pay-scale into their contract.

"We're starting you at $60k/yr, with the understanding that there will be some training needed from us and some learning/growth from you. If everything goes well and you're performing- then you'll get $70k/yr at 6 months. Keep it up and keep scaling your ability- $80k/yr at 12 months."

Again, ^ this is framed around the idea of hiring someone with foundational front-end knowledge, but would need some grooming into the framework. If you're hiring someone who's already familiar with the framework, then your first offer shouldn't be below $70k/yr.

Hire Early. Believe Often.

At the end of all of this, I know it compiles to a company taking a risk on a new hire. Companies don't like taking (uncalculated) risks. Juniors aren't uncalculated.

There are plenty of cases of companies hiring junior and them becoming some of the best employees to company has seen.

We have the opportunity to flood the industry with developers full of good practices and (in my case at least) such a gratitude for finally "making it" that a lot of them will turn around and pay it forward.

Which is all I'd like more companies and hiring managers to do. Pay it forward.

Someone took a chance and hired you early on- maybe before you were even ready. It worked, in their favor and yours.

Pay that forward.

Easy File Uploads in React with Simple File Upload

Drew Clements — Tue, 06 Jul 2021 12:30:27 +0000

What would you say are the two most difficult things to do in front-end programming for you? State management? Data integrity? Those are valid choices, and there’s plenty more that you could add, but for me-- the answer would be working with Amazon S3 and file uploads.

Most devs know that nothing about S3 is easy. The pricing model is ambiguous at best and the integration can be an entire nightmare in and of itself. That’s still only half of the problem. What about the file upload? The input? Everyone expects drag-and-drop these days but that’s not really an easy thing to build, and again, only half of the problem.

That’s where Simple File Upload comes in. Simple File Upload abstracts out the tough stuff so you can get to building the parts you love!

Today we’re going to build a quick file uploader with built-in S3 uploads using the React framework.

Setting up the Project

We’re going to keep this pretty barebones. We’ll write some CSS, but the main feature we’ll be focusing on is how simple it is to get the Simple File Uploader into your project and working!

I have a folder on my desktop where I keep all of my projects, so we’ll start by cd-ing into that directory and running npx create-react-app simple-file-uploader in the terminal.

From there we’re going to install Simple File Upload. They have a React package for it, so we’ll just npm install react-simple-file-upload, and voila- we have it ready to use.

Simple File Upload is a paid solution, so you’ll have to create an account and get an API key- which we’ll use later in the project. Once we have all of that ready then we can jump into the code!

Now let’s get our local server running. In your terminal you want to cd YOUR_PROJECT_NAME and then run npm run start. Boom! Let’s go!

Summary:

npx create-react-app simple-file-uploader
npm install react-simple-file-upload
Create an account at simplefileupload.com and grab your API key
CD into your project folder and run npm run start

Getting into the Code

First things first. Let’s jump over to our App.js file and get rid of the react boilerplate.

Strip it all of the way down until it looks like this.

// App.js

import './App.css';

function App() {

  return (
    <div className="App">
      <header className="App-header">
      </header>
    </div>
  );
}

export default App;

This gives us a clean base to work from and now we can get started building.

I always like to come up with a definition of done list when I’m building out projects or features. This is simply a quick list of key functionality we want to ensure exists. In this app we want to be able to drop images into our Simple File Uploader and have them render in a grid below.

Our Definition of Done could look something like this:
The simple file uploader widget is in the UI
The preview is disabled
The uploaded images render in a grid

We’ll refer back to this as we build.

Let’s start by giving it a quick “website” feel with some content in the header.

// App.js

<header className="App-header">
  <h1>Simple File Upload Demo</h1>
  <a className="btn" href="https://simplefileupload.com">
    Try it now!
  </a>
</header>

From here, let’s get our Simple File Upload widget into the UI. We’ll import the SimpleFileUpload package into the project. To do that, we'll add import SimpleFileUpload from ‘react-simple-file-upload’ back in our App.js file.

And we’ll go ahead and place the widget in the markup as well. Let’s put in a main tag to use as a wrapper for the uploader and our grid.

One very important thing to note about the upload widget is the onSuccess attribute available. This where you’ll call the function you want to happen when a file is successfully uploaded.

This is also where you’ll receive access to the S3 generated URL for your asset. This is where you could push that url to an array, write it to a database, package it up in an email- the sky's the limit.

// App.js

import './App.css';
import SimpleFileUpload from 'react-simple-file-upload';

function App() {

  return (
    <div className="App">
      <header className="App-header">
        <h1>Simple File Upload Demo</h1>
        <a className="btn" href="https://simplefileupload.com">
          Try it now!
        </a>
      </header>
      <main>
        <div className="upload-wrapper">
          <SimpleFileUpload
            apiKey="YOUR_API_KEY_GOES_HERE"
            onSuccess={handleUpload}
            preview="false"
          />
        </div>
      </main>
    </div>
  );
}

export default App;

You’re probably seeing an error right now. Your project is probably yelling at you because handleUpload doesn’t exist. Let’s fix that.

Let’s create that function just before your return statement. To quickly check that our uploader is working, we can just quickly console the url.

function handleUpload(url) {
   console.log(url)
  }

Now… upload a file! Did it work?! Sweet! So at this point our upload widget is functioning and we just need to build out our UI a little more.

So in very little code we’ve gotten a working drag-and-drop widget connected straight to Amazon S3 buckets. Isn’t that wild? That simple. That quick.

So now your file should be looking something like this.

// App.js

import './App.css';
import SimpleFileUpload from 'react-simple-file-upload';

function App() {

function handleUpload(url) {
   console.log(url)
  }

  return (
    <div className="App">
      <header className="App-header">
        <h1>Simple File Upload Demo</h1>
        <a className="btn" href="https://simplefileupload.com">
          Try it now!
        </a>
      </header>
      <main>
        <div className=’upload-wrapper’>
          <SimpleFileUpload
            apiKey=’YOUR_API_KEY_GOES_HERE’
            onSuccess={handleUpload}
            preview="false"
          />
        </div>
      </main
    </div>
  );
}

export default App;

Let’s check our Definition of Done and see where we stand:

~~The simple file uploader widget is in the UI~~
~~The preview is disabled~~
The uploaded images render in a grid

Looks like we’re almost done! All that’s left is to get our uploaded images into a grid!

Since we’re not using a database in this project, the easiest way to accomplish this will be to store the image urls in hook and have our UI display them all.

Our next step is to add import { useState } from ‘react’ at the top of our file. After that we’ll create the hook just below the line function App() {.

We’ll just call this uploadedImages. const [uploadedImages, setUploadedImages] = useState([]).

Now that we have that in place, we can change our handleUpload() to set the images in our hook rather than just logging them out.

function handleUpload(url) {
    setUploadedImages([...uploadedImages, url])
}

From there, we just need our front-end to map through the images and display them!

Add this code just below your .upload-wrapper div

<ul className="image-grid">
  {uploadedImages.length ? (
    uploadedImages.map((image) => (
      <li>
        <img src={image} alt="Fun images" />
      </li>
    ))
   ) : (
   <p>Your uploaded images will appear here!</p>
 )}
</ul>

There you go!! We’re now using Simple File Upload to send images straight to S3 and displaying them in a grid!

The last step is to dress this up just a little bit.

Move over to your App.css file and add the code below

.App header {
  padding: 1rem 4rem;
  display: flex;
  justify-content: space-between;
  align-items: center;
}

.App header h1 {
  font-size: 1.25rem;
}

.btn {
  background: linear-gradient(90deg, #b731dd 0, #4161eb 100%);
  padding: 0.5rem 1.25rem;
  border-radius: 0.25rem;
  text-transform: uppercase;
  font-weight: bold;
  transition: 150ms cubic-bezier(0.6, -0.28, 0.735, 0.045);
  box-shadow: 5px 5px 10px rgba(17, 17, 17, 0.25);
}

.btn:hover {
  transform: scale(1.05);
}

.App header a {
  color: white;
  text-decoration: none;
}

.App main {
  max-width: 1024px;
  margin: 0 auto;
  overflow: hidden;
}

.App .upload-wrapper {
  display: flex;
  justify-content: center;
}

.App main .image-grid {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  gap: 2rem;
  row-gap: 6rem;
  list-style: none;
  margin-top: 6rem;
  text-align: center;
  padding-left: 0;
}

.image-grid p {
  grid-column-start: 2;
  opacity: 50%;
}

.image-grid li {
  overflow: hidden;
  height: 200px;
}

.image-grid img {
  width: 100%;
  height: 100%;
  object-fit: contain;
  object-position: center;
}

What just happened?

You, my friend, just uploaded images to Amazon S3 in 6 minutes (according to this article’s read time)!

So now the tough stuff is out of the way and you can go build the fun parts of your app!

Focus-visible: The Unsung Hero

Drew Clements — Tue, 22 Jun 2021 18:22:04 +0000

You find a lot of edge cases building UI's. Accessibly opening a modal, scroll-lock, strange focus states, etc..., and the solution to those edge cases aren't always apparent.

Well, I just found one that I already knew the answer too but forgot- so I'm writing this article to cement in my head and share the knowledge with all of you!

What is :focus-visible?

According the MDN, :focus-visible is a pseudo-class that applies while an element matches the :focus pseudo-class and determines vie heuristics that the focus should be made evident on the element.

In human speak? The browser determines if the :focus came from a click event or keyboard event and applies the styles accordingly. In most cases, that means that it won't apply the :focus styles from a click event.

That means that you give your keyboard users the focus styles they may want/need/desire without having a potentially jarring user experience for your mouse users.

What was the problem?

The issue I ran into was that I needed an element to have focus styles for accessibility's sake- but I didn't need some of those focus styles to apply when it was clicked.

To be even more clear, the hover and focus styles are the same. I wanted the hover styles to apply on hover but I didn't need the focus styles to linger after the element was clicked.

.logo-link:hover,
.logo-link:focus,
.initial-display {
  .logo-text {
    @apply translate-y-0;
  }
  .logo-type {
    @apply opacity-100;
  }
  .logo-tagline {
    @apply opacity-80;
  }
}

You can see there wasn't much to the styles, but the client was adamant about this user experience.

The Solution

The answer to this problem was only 8 characters long!

Adding -visible to the end of the :focus pseudo-class was all it took.

.logo-link:hover,
.logo-link:focus-visible,
.initial-display {
  .logo-text {
    @apply translate-y-0;
  }
  .logo-type {
    @apply opacity-100;
  }
  .logo-tagline {
    @apply opacity-80;
  }
}

Now I can see clearly

I was absolutely ready to go town with javascript by using a click event to force .blur() and be as strong-handed as I needed to be to make it work.

I mentioned earlier that I knew this answer, but that I didn't come to this solution on my own. A co-worker suggested :focus-visible and it immediately came rushing back.

I ran into this exact problem a couple of months and the fix was the exact same thing!

Can I Use

There is one caveat to :focus-visible, and that is that it doesn't have full browser support yet.

You can see in the image below that it has decent coverage of around 70%, but it has 0 support in Safari, so you'll have to be sure to cover all of your bases and add in some polyfills.

Rebuilding Promise.all()

Drew Clements — Mon, 07 Jun 2021 12:54:15 +0000

I was presented with an interesting challenge recently. That challenge was to recreate a method provided by Javascript. Any guesses what that method was? That's right! Promise.all().

The purpose of the exercise was to get a deeper understanding of how promises in Javascript work. If you've worked with anything Promises or Async/Await before, then you know that there are specific things that have to happen in a certain way and order to work- and this is all by design.

Gathering Context

With that said, we can deduce a few things from Promise.all() and use that to scope what our function needs to do.

What do we know about Promise.all()? We know it accepts an array of promises. We know it returns an array of what those promises return. We know the returned array is itself a promise. We also know that it only does that last step if all promises succeed- so it errors if any of the passed in promises fail.

Our Definition of Done list could look something like this:

It accepts an array of promises
It returns a promise
It returns an array of those promises' returned value
It errors if any of the passed in promises fail

Jumping into the Code

We're only going to be writing a single function for this article. If you want to code along then you can pop open a new index.js file and use your terminal to test it once we're done.

Step one of this is to create the function. Since we're mimic-ing Promise.all(), we can call this function promiseAll

// index.js

function promiseAll() {

}

Not too tough, huh? The next step is to let the function know to expect an array of promises when it is called.

// index.js

function promiseAll(promises) {

}

That's Definition of Done number one off of our list!

~~It accepts an array of promises~~
It returns a promise
It returns an array of those promises' returned value
It errors if any of the passed in promises fail

Next we want to set this function up to return a promise.

I highlighted those two words because they almost literally tell us what we need to do next. How do you make a function return? How do you create a new Promise?

If you can answer those two questions, then you already know what our next code snippet should look like.

// index.js

function promiseAll(promises) {
  return new Promise((resolve, reject) => {

  })
}

See what I mean? We had to return a new Promise. And that's item two of of our checklist

~~It accepts an array of promises~~
~~It returns a promise~~
It returns an array of those promises' returned value
It errors if any of the passed in promises fail

Returning an Array of Promises

Number 3 on our checklist is where the difficulty ramps up a bit.

Let's break down what we need.

We need:

an array we can return
to get the returned values of the promises passed in

Let's take that one step further. We know we're only going to return the promises' values in an array if they all return successfully.

Knowing that, lets create an array called successes

// index.js

function promiseAll(promises) {
  return new Promise((resolve, reject) => {
    let successes = [];
  })
}

Now we need to somehow get the returned values of all promises passed in. Can you think of a couple of ways we can iterate through each promise?

We can use a for loop or the .map() method. Either here would work, but I'm going to use the .map() since I'm more familiar with it. Read up on .map() here

Let's map through our promises

// index.js

function promiseAll(promises) {
  return new Promise((resolve, reject) => {
    let successes = [];

    promises.map((promise) => {

    }
  })
}

Now we can do promise stuff within the scope of each individual promise passed in.

What we'll be doing here is calling each promise individually and using a .then() to then get access to its returned value.

We'll also want to add a .catch to handle any errors. This actually checks off the fourth thing on our list.

// index.js

function promiseAll(promises) {
  return new Promise((resolve, reject) => {
    let successes = [];

    promises.map((promise) => {
      return promise.then((res) => {

      }.catch((err) => {
        reject(err)
      }
    }
  })
}

Remember that our larger function is trying to return an array of returned values. Knowing that, we shouldn't immediately resolve our promises.

Instead, we'll push our returned values to our successes array we created earlier.

// index.js

function promiseAll(promises) {
  return new Promise((resolve, reject) => {
    let successes = [];

    promises.map((promise) => {
      return promise.then((res) => {
        successes.push(res)
      }.catch((err) => {
        reject(err)
      }
    }
  })
}

We're getting close!!

Do you know what should happen next? Let's recap.

Our function is returning a promise.
Our function is set to error if any of the passed in promises fail.
And we're pushing our returned values to a successes array.

So what's left? Now we need to resolve our promise, but there's a condition with it.

We only want to resolve if all passed in promises succeed.

We can do that with an if statement by comparing the length of our successes array to the length of the promises passed in.

// index.js

function promiseAll(promises) {
  return new Promise((resolve, reject) => {
    let successes = [];

    promises.map((promise) => {
      return promise.then((res) => {
        successes.push(res)

        if(successes.length === promises.length) {
          resolve(successes)
        }
      }.catch((err) => {
        reject(err)
      }
    }
  })
}

Now we're making promises we can keep!

Congratulations! You've just rebuilt the functionality of Promise.all() and that's the last thing on our list!

~~It accepts an array of promises~~
~~It returns a promise~~
~~It returns an array of those promises' returned value~~
~~It errors if any of the passed in promises fail~~

Running our Promise

Finishing up, let's run our function and see how it works.

Add these to the bottom of your index.js file.

const p1 = Promise.resolve(1);
const p2 = new Promise((resolve, reject) => setTimeout(() => resolve(2), 100));
promiseAll([p2, p1]).then((res) => console.log(res));

Now, in your terminal-- be sure you're in the right directory- and run node index.js.

You should see the fruits of your labor console.logged before you!

Bonus

There's a small bug in this code. Can you see what it is?

Given the nature of promises, we can assume that there is a good chance that the promises passed in won't return in the same order as when they're passed in.

We're using .push() to add our returned value to the successes array. This means that values will always be inserted to the end of the array, so if promise 2 returns before promise 1, it will actually show up in the first index of the successes array.

You can actually see this in our example now.

You would expect to see [2, 1] since we passed the args in this order (P2, P1)- but they're actually backwards! What we see in the terminal is [1, 2].

This is because P1 resolves immediately, whereas p2 returns a new promise and then resolves.

How would you fix this?

Hint: You could use the index of each passed in promise and then insert their returned value at that index of the successes array.

Full-tilt Driven Development: Unleashing the Optimist Within (with realistic expectations)

Drew Clements — Mon, 10 May 2021 14:38:32 +0000

I know what you're thinking. Another "blah blah driven development" pattern that people will swear is going to change how we build businesses, right? Wrong. This is not that at all.

This is a glance at how (I)- an individual far too prone to putting all of my eggs in the pot of gold at the end of the rainbow basket- is managing to satisfy my optimistic spirit without compromising the goals.

Separate the Goals from the Idea

Ideas can be nebulous. They can also have multiple paths to "success". We'll use Protegé as a case study throughout this article.

Now, the idea of Protegé was to build a place where early-career developers could find remote work opportunities. But how? Use a job board template from Wordpress or some other WYSIWYG editor? Build a newsletter? Roll our own solution?

The problem with any of these options is that none of them have a defined point of 'success'.

Is it when the product exists and works? Is it when you can confirm people are getting jobs from it? Or, is it when it starts making money?

Regardless of your choice here, it's a great idea to come up with minimum viable goals for your project. You see the same pattern applied to problem-solving and working on large tasks. Break it down into smaller and more manageable pieces.

Use those goals as stepping stones towards your idea.

Minimum Viable Goals

MVG's aren't throw-away goals. In fact, they are the exact opposite. They sit somewhere between your defined point of success and the smaller task-oriented goals you'll define during the building of your project.

You could also call them your mental safety net. The idea of these goals is to have a high chance of achievement, and ideally, they should be achievable from your efforts alone.

Goals that are heavily dependent on external forces (users, traffic, revenue numbers, etc...) are hard to predict and control.

I know how my brain works. I will hold myself responsible and accountable for any failures of my project, regardless of whether or not its outcome was within my realm of control.

Setting my MVG's within my realm of control serves a dual purpose. It removes the chance of me mentally bullying myself for failure when I had no say in its outcome, and also gives me a list of points to hold myself accountable for.

Again, using Protegé as the example- its MVG's were:

A company can click through the job flow and list a job
- This is a technical MVG. Whether or not a company actually used the feature is removed from the goal.
I can list Protegé on my portfolio.
- Again, whether or not someone uses it, or if it brings in any money isn't even considered when measuring this metric.

Based on these goals, Protegé is already a success!

Maintaining Reality Beyond MVG's

So, you've reached your MVG's- now what? This is the beautiful part.

It. Doesn't. Matter.

It doesn't matter what you do now because, at this point, your project is a success! You've done the original thing you sat out to do, and anything beyond this point is a bonus.

Leave it up to showcase. Write a series of articles detailing the build process. Turn it off altogether. Sell it. Market it. It. Doesn't. Matter.

What does matter, is that you consistently remind yourself that you've moved into territory where you will have less and less effect and control over the outcomes of the next steps you take.

By all means, push it as far as you wish- but always tell yourself something along these lines, "I built [Project Name]. I'm trying to accomplish [goal X] now. I've already accomplished my MVG's- so this project is a success, regardless of what happens moving forward."

Wrapping Up

I want to reiterate that this is not an article on how to successfully build a business as a raging optimist. This article is detailing the steps I've put in place for myself to safeguard my confidence and mental health while climbing every Mt. Everest my brain can think of.

Here's a quick recap of what we covered:

Separate your idea from your goals
Set minimum viable goals (early)
Maintain expectations beyond your MVG's

This approach may not be the solution for everyone. It may already be well-known and I'm just putting a different outfit on it- but it works for me.

I hope other insatiable optimists find some value here.

Now, get after it!

Using Components to Bootstrap Data for your App

Drew Clements — Fri, 30 Apr 2021 21:09:35 +0000

Have you ever discovered something that just made stuff click? Something so game-changing that it brightened the colors in your world almost instantly? I found one of those recently, and I wanted to share it!

What I'm referring to here is a little "hack" you can use to bootstrap data for your application to help ensure the data is where it needs to be, when it needs to be there. I believe this is a common pattern, but I'm unsure of what that specific component is referred to as- so we'll call it the bootstrapping component.

On a zoomed-out level, this component sits in your component tree and quietly fetches data anytime the app hits a refresh, page re-direct-- all of those situations where you'd expect some data from your state to disappear.

How it works

Here's how the bootstrapping component works on a very basic level.

It sits in the component tree
Data is fetched/mutated/merged (whatever you need it to do)
Data is placed into whatever state management tool you're using, making it available where needed.

This is obviously a very simplistic view of how it works, but if you had to elevator pitch this to someone, then this may be a good way to frame it.

Into the weeds

Now let's get into how you would build one of these. In this example, we're going to be looking at building it in a NextJS app that's set up with Firebase. This pattern is tool-agnostic and will work with a wide array of setups

We're jumping in at the point after Firebase is already set up in this project.

Creating the Component

We'll start by creating a component in the /store directory. Components are usually placed in a components/ folder, but this specific type of component doesn't care about what's being rendered, and in fact, doesn't render anything other than children passed to it- so we'll keep it in a different directory for clarity.

It's good practice to name these components similar to the data they'll be responsible for. We'll be using it to fetch user profile info in this case, so we'll call ours UserProfileProvider.

'store/UseProfileProvider.js'

import { useEffect } from 'react'

const UserProfileProvider = ({ children }) => {
  useEffect(() => {

  }, [])

  return <>{children}</>
}

export default UserProfileProvider

We'll need a useEffect later, so we'll go ahead and place an empty one for now

Placing the Component

Now that we have our component setup, let's place it in the component tree. We can focus on our bootstrapping component and the data it needs to handle once that is done.

Let's jump over to our _app.js in the /pages directory. You'll see we already have an AuthProvider component. This component is doing something similar to what we're building here, but it's specifically handling user auth- which can get complex quickly. That's an article for another day.

So, in our _app.js You'll see there's already a component tree forming from different pieces needed for the app. We're going to place our UseProfileProvider component as high up as we can, but within the AuthProvider component.

'pages/_app.js'

return (
    <AuthProvider>
      <UserProfileProvider />
      <GlobalLayout>
        <Component {...pageProps} />
      </GlobalLayout>
    </AuthProvider>
  )
}

export default MyApp

Ignore the GlobalLayout component. It's a UI focused component that ensures each page has the same header and footer

Now our bootstrapping component is in place and we can start making it do the thing with the stuff.

Wiring it up

Our bootstrapping component is going to be fetching user profile information whenever there is a logged-in user.

Based on that last sentence, we know that we only want this to run when we have a logged-in user. In this case, we have a currentUser hook available from our AuthProvider that will allow us to check for that.

Jumping back to our UserProfileProvider, we're going to import firebase and useAuth, as those are two things we'll need to make this work.

'store/UseProfileProvider.js'

import { useEffect } from 'react'
import { useAuth } from 'store/AuthContext'
import 'firebase/firestore'

const UserProfileProvider = ({ children }) => {
  const { currentUser } = useAuth()

  useEffect(() => {

  }, [])

  return <>{children}</>
}

export default UserProfileProvider

These imports have more going on in them, but at a basic level- useAuth is allowing us to check our AuthProvider for a currentUser, and firebase/firestore is providing the ability to call/read from our Firebase firestore.

From this point, we're going to move into our useEffect and write some logic for fetching the data we need.

The first thing we're going to do is write a function that will call firebase and return the profile info of our logged-in user.

One thing to note here is that we have a unique id of our current user available from the AuthProvider. We'll use that to make sure we're getting data from the right profile.

'store/UsesProfileProvider'

useEffect(() => {
    async function fetchUserProfile() {
      const userProfileInfo = await firebase.firestore()
        .collection('users')
        .doc(currentUser.userUid)
        .get()
    }
}, [])

What this function is doing is calling firestore and saying "hey, I need the data from the 'users' collection where the name of the document is matching this userUid".

Another thing worth noting is that Firebase is promise-based, so you'll either be using async/await or .then() to resolve your promises

We're not quite done yet!

This code will error if it were called without a currentUser. It would error because it would be asking Firestore for data based on this userUid, but if there's no user then there's no userUid- so Firestore would come back with an error essentially saying "you gave me nothing, I can't work with that."

The fix here is to wrap where we call this function inside of our useEffect in an if statement. It would look something like this.

'store/UsesProfileProvider'

useEffect(() => {
    async function fetchUserProfile() {
      const userProfileInfo = await firebase.firestore()
        .collection('users')
        .doc(currentUser.userUid)
        .get()

      setProfileInfo(userProfileInfo.data())
    }

    if (currentUser) {
      fetchUserProfile()
    }
}, [currentUser])

Now our fetchUserProfile function will only run when we have a logged-in user.

Notice that we also added currentUser to the dependency array at the end of our useEffect. This means that this code will run anytime the app boots up, whether it be from a page refresh, routing, or other scenarios, and also anytime data within our currentUser changes.

So, if our user logs in with another account, this code will run and give us fresh data to work with!

Ready for Use

Now that we have this bootstrapping component set up, we will always have fresh and relevant user profile info to work with!

Summary

I was recently shown this pattern and it instantly solved a problem I'd be fighting for a bit. I needed data to be available at first load, but to also update if anything with our current user changes, and to be returned on time for our users.

Anyways, I found this pattern extremely helpful to learn and it was also fun to build.

I hope whoever finds this article has the same takeaway!

Until next time!

Pt: 3 Needles to Nuxt: Building a Website for a Tooth and Nail Tattoos

Drew Clements — Wed, 21 Oct 2020 14:25:29 +0000

If you're jumping in here, here's part one.

Also, here's part two

Update Summary:

Thing have been moving forward for this project. Not as quickly as I would like, but progress is progress.

So far, my focus is getting static versions of the different homepage sections in place

The site is live on Netlify and you can check it out here.

What have I learned?

SVG's win a lot of the fights

The first thing I learned is that it is very difficult (for me at least) to use a complex SVG as a frame for images. I can only imagine compounding that with there being a carousel to deal with as well.

After fighting for hours, I relented and currently have a png placeholder for now. I'd love some advice/suggestions if you know of a way to accomplish this with svg's.

Carousels are rad

The second and super fun thing I learned was building a carousel with Vue Awesome Swiper. Just below the fold is a carousel that reveals itself from behind a cutout of a tattooer.

My first attempt at building this went horribly wrong. I tried to get overly complicated with positioning the carousel and using a clip-mask and a gradient.

Technically, it worked... on desktop... on chrome... only. I stripped it out and realized there was a much simpler way to go about it. Here's a quick overview of my solution

The carousel spans the full width of its container.
An empty div with a gradient matching the background color to transparent is absolutely positioned on top of the carousel and to the right.
The tattooer's image is positioned on top of those.

And here are the results!

Johnny Cool Hat is removed on mobile for a better user experience

You can check out some of the code here. I still need to break parts of it out into components. But hey, it's a work in progress.

Deploying to Netlify is a dream

I pushed the site to Netlify last night. Partly for fun, partly to test easier on different devices. I sent it to the client as well, and they're super stoked on the progress.

Netlify couldn't make deploying any easier. I clicked 'New Site', selected the repo I needed, and the rest was magic! And it rebuilds anytime I push to main!

What's next?

Finish homepage
Wire in Firebase
Attempt to build micro-cms with Firebase as back-end
If all else fails, abandon cms idea and deliver a solid static site