DEV Community: Steve Edwards

Dynamically Importing Vuex Store Modules From Directory Structure

Steve Edwards — Sun, 03 May 2020 18:09:06 +0000

This is a continuation of my previous post, where I went through the details of how to define Vue router route definitions in files throughout the app directory structure, and then import them into the main router index.js file. In this post, I'm going to be showing the same process for Vuex store modules. There are a couple small variations from the router import code, but nothing major.

First, here is the structure of a store module:

import * as types from '@/store/types';

const state = {
  events: [],
};

// getters
const getters = {
  getEvents: state => state.events,
};

// actions
const actions = {

};

// mutations
const mutations = {
  [types.SET_EVENTS](state, shifts) {
    state.events = shifts;
  }
};

export default {
  namespaced: true,
  name: 'event',
  state,
  getters,
  actions, 
  mutations
}

There is one small addition to this file for import purposes, and that is the name key in the exported object. This is because during the import process, since stores are separated by namespaces, a name property is needed. However, in looking through all of the available information returned from require.context(), I didn't see the value of the parent directory name, so I just added that value to the exported object.

With those defined, here is the store index.js file:

import Vue from 'vue';
import Vuex from 'vuex';
import Auth from '@/store/modules/auth'

Vue.use(Vuex);

const debug = process.env.NODE_ENV !== 'production';

Vue.config.devtools = true;

// Import all of the resource store files.
function loadStores() {
  const context = require.context('@/resources', true, /store.js$/i);
  return context.keys()
    .map(context)         // import module
    .map(m => m.default)  // get `default` export from each resolved module
}

const resourceModules = {};
loadStores().forEach((resource) => {
  resourceModules[resource.name] = resource;
});

resourceModules.auth = Auth;

export default new Vuex.Store({
  modules: resourceModules,
  strict: debug,
});

You can see where I use the exported name property in the call to loadStores(). Then, once all of the store modules under the /resources directory are adde to the resourceModules object, I manually add the store for the Auth module (since it's outside of the /resources directory), and then pass it all to the modules key in the new Vuex.Store() constructor. After verifying in the Vue Dev tools that the store exist, I'm off and running.

Dynamically Generating Vue Router Routes From Directory Structure

Steve Edwards — Sun, 03 May 2020 18:00:29 +0000

I'm working on a Vue starter kit for a Javascript platform that I've used for a few years, and I have the need - well, the desire to make it as easy for the developer as possible - to automatically import route definitions from multiple locations and add them to the Router() definition, instead of loading them all from the router index file.

In applications such as Vue apps that have multiple types of files that are used together to create the app, there are primarily two ways to organize the files. For instance, in Vue, let's say that we have multiple resources, and each resource has three components:

The component (.vue file)
The router definition file
The Vuex module file

You could choose to organize your files in two different ways:

By feature - each directory has a .vue file, a router file, and a Vuex file
By functionality - one directory each for components, one for router files, and one for Vuex files.

In my case, I'm going to group by feature, which I will refer to as a resource (to match the platform naming convention). Using the example resources, of user, event, and job, this will be my directory structure:

/src
  |
  ---/resources
         |
         ---/user
              |
               ---User.vue
               ---routes.js
               ---store.js
            /event
              |
               ---Event.vue
               ---routes.js
               ---store.js
            /job
              |
               ---Job.vue
               ---routes.js
               ---store.js

The contents of a routes.js file will look like this:

import Event from '@/resources/event/Event'

export default [
  {
    path: '/events',
    name: 'event',
    component: Event
  },
];

Including an additional Auth.vue component (which is outside the /resources directory), our base router index file will look like this:

import Vue from 'vue'
import Router from 'vue-router'
import Home from '@/components/Home'
import Auth from '@/components/Auth';

Vue.use(Router);

let routes = [
  {
    path: '/',
    name: 'home',
    component: Home
  },
  {
    path: '/login',
    name: 'auth',
   component: Auth
  },
];

export default new Router({
  mode: 'history',
  routes,
})

If I were to manually add the router objects for my three resources, I could do it like this:

import Vue from 'vue'
import Router from 'vue-router'
import Home from '@/components/Home'
import Auth from '@/components/Auth';
import Event from '@/resources/event/Event';
import Job from '@/resources/job/Job';
import User from '@/resources/user/User'; 

Vue.use(Router);

let routes = [
  {
    path: '/',
    name: 'home',
    component: Home
  },
  {
    path: '/login',
    name: 'auth',
    component: Auth
  },
  {
    path: '/events,
    name: 'event',
    component: Event
  },
  {
    path: '/Job',
    name: 'job',
    component: Job
  },
  {
    path: '/user',
    name: 'user',
    component: User
  },
];

export default new Router({
  mode: 'history',
  routes,
})

However, I want to avoid having to manually update this file every time I add a resource, so instead I do it dynamically:

import Vue from 'vue'
import Router from 'vue-router'
import Home from '@/components/Home'
import Auth from '@/components/Auth';

Vue.use(Router);

let baseRoutes = [
  {
    path: '/',
    name: 'home',
    component: Home
  },
  {
    path: '/login',
    name: 'auth',
    component: Auth
  },
];

// Import all of the resource routes files.
function loadRoutes() {
  const context = require.context('@/resources', true, /routes.js$/i)
  return context.keys()
    .map(context) // import module
    .map(m => m.default) // get `default` export from each resolved module
}

const resourceRoutes = loadRoutes();
resourceRoutes.forEach((route) => {
  routes.push(route[0]);
});

export default new Router({
  mode: 'history',
  routes,
})

The magic happens in the loadRoutes() function. As described to me in the answer to my Stackoverflow post, require.context() returns a context module, which exports a keys function that returns an array of all possible requests (i.e., the matching paths), each of which could be passed to the context itself (which invokes its resolve function) to import the corresponding module. The returned array from loadRoutes() function looks like this:

resourceRoutes = [
  {
    0: [
          {
            path: "/event",
            name: "event",
           component: {
             name: "Event",
             ...
           }
        ]
  },
  {
    1: [
          {
            path: "/jobs",
            name: "job",
           component: {
             name: "Job",
             ...
           }
        ]
  },
...
]

so I just loop through each returned item, get the first array item, and add it to the routes array. And voila!, it's done.

There are a couple benefits to this approach. First, it keeps my code modularized and keeps my main router file from getting more and more cluttered. Second, this looks toward the future; down the road, I will be creating a Vue CLI plugin that will allow a user to add all of the necessary files for a new resource that has been added to the platform, and it is easier to create a new file with a pre-determined content than it is to modify the contents of an existing file.

Creating a Fast Site with Nuxt and CSS

Steve Edwards — Mon, 23 Mar 2020 04:14:38 +0000

As a developer who has spent the majority of his years working on the back end of website projects, my front end skills have not always been very developed, to put it mildly. At those times when I did need to do theming work, I would rely on tools like Bootstrap, Bulma, or Vuetify to handle the bulk of it for me. However, over the last year, after hearing so much about the features that have been added to HMTL and CSS over the past few years, I decided to start learning about CSS.

In particular, CSS Grid and Flexbox intrigued me, because layout has always been fairly difficult, so I started out by taking the free courses from Wes Bos on Grid and Flexbox. I also want to be able to learn to design my own layouts, so I got Adam Wathan’s Refactoring UI (although I haven’t been able to get started on it yet).

I was starting to look around for a project to work on, when I was presented with an opportunity to do a website for a local non-profit. Still not feeling comfortable with designing my own theme, I went browsing on the internets and came across the iCare theme on Theme Forest. After getting approval from the organization, I purchased the theme.

Selecting the Site Toolset

In this particular case, SEO was very important to the organization, and being familiar with the Vue ecosystem (I work with Vue in my day job), I decided to go with Nuxt, because of its server side rendering capabilities. For the back end, I looked at a couple of different options. I knew I wanted to use a headless CMS. I worked with Drupal for a number of years, so I’m very familiar with content modeling and structure, but I wanted something that I didn’t have to set up myself. I considered a GitHub pages-type structure where I write in markdown files and commit directly to a repository, but there were a couple problems with that. First, that would work great for me, but I am the only technical person in the organization, and if I were to get hit by the proverbial bus (or fire engine, in my case) I wanted a non-technical person to be able to manage site content in my absence. I really like ButterCMS (the CMS I use for this site), because it has a very flexible data modeling and content management user interface, and the API is drop dead easy to use. However, in order to get the full data modeling capabilities, the cost is $99/month, and that was cost prohibitive for the organization. I started looking at the many hosted headless CMS options, and narrowed it down to Prismic, Sanity, Contentful, Zesty, and Strapi. After considering all the different pros and cons (cost, API ease of use, data modeling capabilities, etc) of each one, I decided to go with Prismic. The Content Query API takes a little getting used to, and the API docs can be a little confusing, but the UI is fairly intuitive and flexible, and it has good code documentation for various frameworks and languages (including VueJs and Nuxt). For just one user it is free, and adding two more users only costs $7/month, so that fit right in the organization’s budget.

From a hosting standpoint, my own site is hosted in Netlify, and it is a popular and flexible platform that I am already familiar with, so choosing it was a no-brainer.

Implementing the Theme

My initial plan with the iCare theme was to just incorporate it into Nuxt, add the data, and be off and running. However, the theme contains multiple other dependencies (much custom JS, jQuery, PopperJS, FontAwesome, etc.) and although I tried and tried, I could never get everything to work without a bunch of re-work. After banging my head against that for a while, I decided to build my theme from scratch with CSS Grid. So I started from the front page, and built it out, doing my best to make it look exactly like the iCare theme, but only in appearance, not underlying structure. After a while, I got the header, the footer, and the central content area complete in a full page format. However, it wasn’t responsive at all (you couldn’t even scroll to the side on a smaller screen), and although I had read about media queries and flexbox, I wasn’t sure exactly how to implement them in my theme.

Instead of doing more head banging, I called on my friend Chris Bloom. Chris is the Director of Frontend Engineering at Phase2 Technology, and a real CSS guru. He and I go back to working in Drupal for Sony Music a few years ago, so I’ve known him for a while. He’s also a big proponent of Tailwind CSS, and I’d recently seen him present on using it in VueJS). I gave him access to my theme repo and said “can you make this responsive?”, and he said “sure!”, and a couple days later, sent me a merge request.

I studied it for a while, made some changes, and got stuck, so Chris took an hour and a half and on a video call, and walked me through everything he had done (if you want to someone who is passionate about CSS, get Chris talking about CSS. Just sayin’.). The two things I learned from what he showed me were 1) using media queries and 1) Tailwind-type utility classes.

Media Queries

According to MDN, media queries “are useful when you want to modify your site or app depending on a device's general type (such as print vs. screen) or specific characteristics and parameters (such as screen resolution or browser viewport width).” In this particular case, we just defined four queries that were minimum width sizes (borrowed from Tailwind’s breakpoints):

@media (min-width: 640px) {
  .container {
    max-width: 640px;
  }
}

@media (min-width: 768px) {
  .container {
    max-width: 768px;
  }
}

@media (min-width: 1024px) {
  .container {
    max-width: 1024px;
  }
}

@media (min-width: 1280px) {
  .container {
    max-width: 1280px;
  }
}

The thing that it took me a while to get my head around was that for any of these queries, because we were only using min-width, the styles used in that media query would apply for any size up to full screen size, unless overridden in another query of a higher size. For instance, in the example above, if there had been no .container selected in the query for min-width: 1024px or 1280px, the max-width for the .container class would be 768px. What this also means is that there are actually 5 sizes; the four sizes listed above, and anything below 640px wide; namely, phones.

A good example of where this comes into play is with the main nav bar. Typically, in order to get a row of menu items, you would create a list of items using <ul> and <li> tags, and then set display: inline-block (or even display:flex) on the <li> elements. However, in a mobile view, we want them stacked vertically, and since that is the default list structure, we don’t have to apply CSS to make that happen. Then, when the screen is wide enough that we do want them to be horizontal, we can use a media query to make them inline.

@media (min-width: 768px) {
  .flex {
    display: flex;
  }
}

I finally understood that this is what is meant by mobile first design; designing for the smaller screen, and then adding things as your screen gets wider.

Utility Classes

As I get it, the idea behind utility classes is that each class does only one thing, and the name reflects what it does. For instance, a simple example would be aligning text:

.text-left {
  text-align: left;
}

Then, you just apply the classes to a given element as needed. The downside is that you get a longer list of classes for a given element, but at the same time, you can also tell what that class is doing, as compared to a class with many attributes.

Combining Media Queries and Utility Classes

Now we can combine media queries with utility classes to easily modify section widths depending on screen sizes. As an example, on the events details page, we have these elements:

<div class="container">
  <div class="content-area sm:flex justify-between">
    <div class="event-content-left sm:w-2/3 md:w-770">

And here is the CSS to go along with them:

 @media (min-width: 640px) {
    .container {
      max-width: 640px
    }

  .sm\:flex {
    display: flex;
  }

  .sm\:w-1\/3 {
    width: 33%;
  }

  .sm\:w-2\/3 {
    width: 66%;
  }
}

@media (min-width: 768px) {
  .container {
    max-width: 768px;
  }

  .md\:w-1\/3 {
    width: 33%;
  }

  .md\:w-2\/3 {
    width: 66%;
  }

  .md\:w-770 {
    width: 770px;
  }
}

And here is what’s happening:

At a screen width of 640-767px:

The width of .container has a max-width value of 640px.
The display: flex property is added to the .content-area element.
The width of the .content-area element is set to 33%.
The width of the .event-content-left element is set to 66%.

At a screen width of 768-1023px:

The width of the .event-content-left element is set to 770px.
.display:flex is still set.
The width of the .content-area element is still set to 33%.

One interesting thing to note is the difference between the class declarations in CSS and applications in HTML for the sm: and md: classes; the : and / characters have to be escaped in the CSS (sm\:w-1\/3), but is not in the HTML (sm:w-1/3).

Forms

The one last feature I needed to implement was forms. Fortunately, Netlify has a solution for forms. The basic gist is that you create your form as you normally would (in this case, in a .vue single file component), and then create a .html file that has only the HTML form content (in my case, I created them under the /static/form_dummy directory), Netlify finds that file and automagically handles it, saving the submissions in your site dashboard. You can also set up email notifications when a form is submitted. On top of that, they even provide spam protection using Akismet, along with additional protection using a honeypot field.

Conclusion

The end result is a very fast, lightweight, static site that is cheap to host, and with an easy to manage content CMS. The primary benefit for me was that I was able to use the process of building the site to do a lot of learning about CSS Grid and Flexbox, media queries, utility classes, and how to put them all together. What added more satisfaction was that it wasn't just a learning project that I came up with; it was a very real website for a very real organization that does a lot of great things.