DEV Community: Jake Dohm

Auto-registering all your components in Vue 3 with Vite

Jake Dohm — Mon, 10 May 2021 20:40:02 +0000

Why auto-register components?

I'm actually a big fan of manually importing components in Vue applications. It makes it very clear where every component comes from, doesn't rely on ✨magic✨, and most IDEs can do auto-imports for you anyway so it's not much more work for you.

That said, in an environment where I'm not building an SPA, and I'm using Vue as a progressive enhancement tool, I want all of my components to be available in HTML. To make this happen, I have to register all of them in the root Vue instance....

import { createApp } from 'vue'
// import each component
import Fruits from './components/Fruits.vue'
import Vegetables from './components/Vegetables.vue'

const vueApp = createApp({
  // register each component
  components: { Fruits, Vegetables }
})

This process is tedious, and makes component auto-registration totally worth it IMO.

How

So, to auto-register our components, we need to do a few things:

Get a list of each component
Import that component
Register it on our Vue instance

Luckily, Vite has an amazing feature which takes care of steps #1 and #2 for us

Step 1+2: Glob Imports.

Glob Imports is feature of Vite that allows us to import multiple files based on a filepath.

There are two ways to use Glob Imports in Vite: lazy or eager. If you use the standard glob method, the imports will be processed as dynamic imports, so the components will be lazy-loaded. In our case, we want to import all of the components directly into our main bundle, so we'll use the globEager method.

Note: Glob Imports is a Vite feature, and is not part of any JS or "platform" standards.

Here's how Glob Imports works:

// import multiple components
const components = import.meta.globEager('./components')

And here's the result of that import:

// code produced by vite

// magically autogenerated module imports
import * as __glob__0_0 from './components/Fruits.vue'
import * as __glob__0_1 from './components/Vegetables.js'

// our components variable now contains an object with key/values
// representing each module's path and definition
const components = {
  './components/Fruits.vue': __glob__0_0,
  './components/Vegetables.vue': __glob__0_1
}

Step 3: Registering components

Now that we've actually imported each component, and we have a list containing the path and definition, we need to define these components on our Vue instance.

To do that, we'll loop over each entry in our components object, figure out the component's name based on the file name, and then register the component on our Vue instance.

Object.entries(components).forEach(([path, definition]) => {
  // Get name of component, based on filename
  // "./components/Fruits.vue" will become "Fruits"
  const componentName = path.split('/').pop().replace(/\.\w+$/, '')

  // Register component on this Vue instance
  vueApp.component(componentName, definition.default)
})

Putting it all together

import { createApp } from 'vue'

const vueApp = createApp()

const components = import.meta.globEager('./components/*.vue')

Object.entries(components).forEach(([path, definition]) => {
  // Get name of component, based on filename
  // "./components/Fruits.vue" will become "Fruits"
  const componentName = path.split('/').pop().replace(/\.\w+$/, '')

  // Register component on this Vue instance
  vueApp.component(componentName, definition.default)
})

How to make a GraphQL Query (or Mutation!) in PHP with Guzzle

Jake Dohm — Wed, 21 Oct 2020 22:43:58 +0000

1: Define a Query

First, we're going to start off with creating a query. This will be a simple query that will ask for the "name" field for our site.

$query = 'query { site { name } }';

Now, this works, but it gets awkward and inconvenient to have to keep our whole query on one line. To fix this, we can use a Heredoc which will allow us to break our query into multiple lines.

$query = <<<GQL
  query {
    site {
      name
    }
  }
GQL;

Note: Make sure the ending GQL; statement is not indented at all as that breaks Heredoc syntax.

2: Make the HTTP request

$graphqlEndpoint = 'https://example.com/graphql-api';
$client = new \GuzzleHttp\Client();

$response = $client->request('POST', $graphqlEndpoint, [
  'headers' => [
    // include any auth tokens here
  ],
  'json' => [
    'query' => $query
  ]
]);

This is a pretty standard request, but there are two notable things:

We're making a POST request. All (properly configured) GraphQL endpoints will only accept a POST request.
We're using json not body.
We're not doing any authentication, but you probably will. This will often either be a token you can add as a header, or it will be basic HTTP authentication that you can pass as a top-level option to Guzzle (see docs).

3: Retrieve the response

$json = $response->getBody()->getContents();
$body = json_decode($json);
$data = $body->data;

4: Put it all together

$query = <<<GQL
  query {
    site {
      name
    }
  }
GQL;
$graphqlEndpoint = 'https://example.com/graphql-api';
$client = new \GuzzleHttp\Client();

$response = $client->request('POST', $graphqlEndpoint, [
  'headers' => [
    'Content-Type' => 'application/json',
    // include any auth tokens here
  ],
  'json' => [
    'query' => $query
  ]
]);

$json = $response->getBody()->getContents();
$body = json_decode($json);
$data = $body->data;

Defining "Done"

Jake Dohm — Mon, 18 May 2020 17:58:55 +0000

What does "done" mean? Well, it means you've decided that you're finished. With a task, a project, a JIRA ticket, whatever. But it's very possible that when you say you're done, you're actually 80% of the way to finished, and the last 20% will eventually come around to haunt you and steal your time and money.

Different Types of Done

There are many different valid types of "done". Here are a few of them I could think of, sorted by timeline (ish):

Code works (matches a spec or design)
Code produces accessible and performant UI
Code is tested (either manually or automated)
Ready for internal review (maybe a PR review)
Ready for stakeholder review (client, product manger)
Client has approved
Client has given the go-ahead for launch
Project is launched
Internal team has recapped project internally, and "resolved" that project.

These are all very real states, but if you call all of them "done" you'll never know when you're really done, and you'll underestimate the amount of work left to do, and it will cause problems.

Problem #1: Frustration

When you say you're done with something, your brain believes you. So when you inevitably have to come back and finish the last 20% you get frustrated. Because you were done. It was finished. So, the work that should've included in the definition of "done", becomes nagging "extra" work.

Problem #2: Team Friction & Expectations

When you haven't defined "done" for your team, it's going to cause problems. Take for example a web agency with two developers and a project manager. Here's how they all individually define done:

Dev #1: The project is finished when: it looks like the designs and it doesn't have any glaring functionality bugs.
Dev #2: Everything that Dev #1 said, and: every page has lighthouse score of 90+, it has been audited for SEO issues, and every page is accessible and is at least AA compliant.
PM: The project is finished, functional, matches the team's development standards, and: it has been documented, pushed to Staging for review, and you've set up users for any stakeholders who should have access.

You can immediately see where problems will arise. Dev #1 and Dev #2 are working with entirely different standards of work, and their PM is coming from a completely different perspective. This will cause friction, and lose you money.

Problem #3: Inconsistency

Do you think McDonald's got to where it was, a literal global superpower, without consistency? No, that's one of the things that made it great! You can step into any McDonald's in the World and ask for a #1 and you'll receive the same thing every time. Consistency is key.

Consistency is key, no matter what you're doing. You work for an agency? You need to produce consistently Good Work 😉 or your clients will work with someone else. You work for a product company? You need to produce consistent, stable software or people won't use it (or won't stay). Are you building a component library? You need to have a consistent API across components, and you need to make sure good documentation and examples are always written before you launch a new component.

In any line of work, defining "done" is a crucial part of producing consistent work.

How to define done

Talk with your (complete) team: Bring everyone in that you work with together, and come up with language and processes around what "done" means for each department, and each type of project.

Define done for each aspect of a project: QA should have a "done". Dev should have a "done".

Set up your workflow tools to recognize different "done" states: For instance, at Good Work, we have Trello columns for To Do, Ready for Review (internal), Ready for Review (client), and Done (which means really done).

Lastly

You might be thinking:

I don't have the power to define "done"

This might be true. You might not be a manager or even the most experienced dev on your team. That's fine! Start by defining "done" for yourself and communicating it clearly to your manager(s) and collaborators. Set clear expectations for yourself, and let anyone you work directly with know what your expectations of them are.

Disclaimer #1: I'm no expert. I've never taken an Agile course. I'm not a scrum master. I don't manage a team. But I work with a team, and I've seen when things have gone poorly and when they go well.

Disclaimer #2: I'm not the first, or last, person to write about this. This is one of the core principles of Agile (probably, who even knows) and so it has been covered in depth before me, and will be again after me.

Registering Global Components with Vue 3

Jake Dohm — Wed, 22 Apr 2020 13:49:42 +0000

Vue 3 is now in beta (learn more) so I decided to test it out (using vue-next), and one of the things I had to tweak in my current application is how I was registering my "global" components.

I'll talk about why these changes are necessary below, but if you're just here for the meat of the post, the examples really speak for themselves so here are the actual code changes:

Before

import Vue from 'vue'
import Header from './components/Button.vue'
import App from './App.vue'

// Register Button component globally
Vue.component('Button', Button)

// Create and mount Vue instance
new Vue({
  render: h => h(App)
}).$mount('#app')

After

import { createApp } from 'vue'
import Header from './components/Button.vue'
import App from './App.vue'

// Create Vue instance
const app = createApp(App)

// Register Button component globally
app.component('Button', Button)

// Mount Vue instance
app.mount('#app')

Why are these changes necessary?

Hey, you ask great questions!! Vue 3 changed the way "instances" of Vue work so that they could make the Vue prototype immutable. So now you customize an "instance" of Vue (created with createApp) instead of directly changing the Vue prototype. I'm not sure exactly why this change was made, but that's how things work in Vue 3.

This also means if you're running an app that has multiple Vue instances that share configuration, you'll now need to either 1) duplicate some code or 2) create your own abstraction to share configuration. I'll write more about this soon!

Wrapping up

If you have any questions about this, or any Vue 3 changes, drop me a comment or find me on Twitter @jakedohm . I plan on writing more about Vue 3, so let me know what you'd like me to cover!

Using Tailwind in SASS with Gatsby JS

Jake Dohm — Thu, 12 Dec 2019 20:41:45 +0000

I recently had project to convert a site to Gatsby, and it was using both Tailwind CSS and SASS, so I had to figure out how to convince those two to play nice. I tried a few different solutions that were not ideal, and then found a simpler way to do it. So here it is!

Note: I started on this article before the Gatsby documentation had an official recommendation for this, and just got around to finishing it, but thankfully their recommendation is the same as what I ended up doing. This article contains a few extra steps for a "from scratch" setup, but if you can find the official documentation here: https://www.gatsbyjs.org/docs/tailwind-css/#option-3-scss

Step 1: Install Dependencies

# Using npm
npm install gatsby-plugin-sass node-sass tailwindcss --save

# Using Yarn
yarn add gatsby-plugin-sass tailwindcss --dev

Step 2: Configure gatsby-plugin-sass to use Tailwind

The gatsby-plugin-sass plugin you installed has a fantastic option allowing you to configure it to use PostCSS plugins, like autoprefixer. Which works out nicely because Tailwind is actuall a PostCSS plugin! So, to use Tailwind directives within your CSS, you can drop the following code into your Gatbsy configuration file.

// gatbsy-config.js

plugins: [
  {
    resolve: `gatsby-plugin-sass`,
    options: {
      // Configure SASS to process Tailwind
      postCssPlugins: [require('tailwindcss')],
    },
  },
  // ... more plugins ... 
]

Step 3: Generate Tailwind Config File

To configure Tailwind, we'll need to add a Tailwind configuration file. Luckily, Tailwind has a built-in script to do this. Just run the following command (again, in your project's root directory).

./node_modules/.bin/tailwind init

This will create a tailwind.js file containing Tailwind's default configuration.

Step 4: Add a SASS/SCSS File With Tailwind Directives

Everything should be ready to go, all we need to do now is to actually use Tailwind within our styles! First, create a global.scss file. I put mine at src/css/global.scss. Then, add the following Tailwind directives to your new file:

// global.scss

@tailwind preflight;

@tailwind components;

@tailwind utilities;

Two notes:
1) gatsby-plugin-sass works with both scss and sass files.
2) For this step, I opted to create a new global.scss file, but you could just as easily put the Tailwind directives in an existing SASS file.

Step 5: Import Our Tailwind CSS

The last thing we need to do is to import our new SASS file into a page or layout so that our Tailwind CSS is actually injected into our pages. In layout.js, or wherever you want your Tailwind CSS to appear, add the following import:

// layout.js

import '../css/global.scss'

You're Finished!

That's it, you should have a beautiful SASS + Tailwind + Gatsby setup!

If you run into any trouble along the way, let me know in the comments and I'll happily help out and/or revise this article with any corrections!

Adding an "Update Browser" Banner for Legacy Browsers

Jake Dohm — Tue, 19 Nov 2019 20:29:29 +0000

Every day Internet Explorer gets older and users are (slowly) migrating away to more modern browsers. As IE's marketshare decreases, it makes more and more sense to drop IE support and spend that time you would've spend bug-fixing other things like accessibility! But, if you don't optimize your site for IE, the experience will be subpar, which could lead your users to navigate away from your site thinking it is broken for everyone.

Oh how I wish there was a way to solve this problem!!

Hold on a second, I'm getting a call...

*answers the phone*

Smart Person: Hey, I heard you were monologuing about how IE looking bad could reflect badly on your site's reputation. I just wanted to tell you, this problem has been solved...

Me: Oh, sure it has 🙄. The solution is probably complex and takes hours or days to implement, right?

SP: Nah, it's like, 8 lines of CSS.

Me: Yeah sure, but how much JavaScript do I have to load?

SP: None. Literally none.

Me: Hmm, sounds too good to be true, but I'd love to try it out, can you send it over?

*fax machine starts up*

*code prints out*


/* Hide IE banner by default */
.ie-notice {
  display: none;
}

/* Show IE banner on IE10/11 */
@media screen and (-ms-high-contrast: active),
       screen and (-ms-high-contrast: none) {
  .ie-notice {
    display: block;
  }
}

Okay, all joking aside, this solution really does work. The @media query that we're using here is taken from the Media Query section on BrowserHacks.com, and can be adjusted to work for any browser that has a trait that can be feature detected with media queries.

Side note: If you're not familiar with feature detection, it's worth learning about! Here are some articles here on Dev.to to help you out: https://dev.to/search?q=feature%20detection

One more thing

There's an awesome site called OutdatedBrowser.com that you can link to from your compatibility banner to help your users download a modern browser.

Here's an example of some content you could use for your banner:

<div class="ie-notice">
  <div class="container">
    <p>
      Your web browser is out of date. Update your browser for more security,
      speed and the best experience on this site.
    </p>
    <a class="button" href="http://outdatedbrowser.com">Update your browser</a>
  </div>
</div>

I work for an awesome company called Good Work. We are an expert team of web developers helping design teams at agencies, brands and startups build things for web and mobile.

If you're looking for someone to help out on Gatsby, Vue, Tailwind, or other projects, don't hesitate to reach out!

Quick Start: Gridsome + Craft CMS GraphQL API

Jake Dohm — Mon, 02 Sep 2019 03:13:33 +0000

Craft CMS is a fantastic CMS that just got a whole lot easier to use with Gridsome (or any static site generator). The Craft team appears to have noticed the trend of people starting (or hoping) to use Craft as a "Headless CMS". Now, in the newest release (Craft 3.3), they've added an out-of-the-box GraphQL API which is perfect for pulling your content into a static site generator like Gridsome or Gatsby.

Let's jump right into how to use the new GraphQL API to integrate with Gridsome.

5 Steps

1. Set up your Craft installation

To use the GraphQL API, you need to have a Craft installation running 3.3+ and licensed as Craft Pro*. If you have a current Craft installation and running a lower version than 3.3, you can update by changing the craftcms/cms version in your composer.json to "^3.3.0" and then running composer update.

*in development you can use the Craft Pro trial

2. Create a schema

Schemas are the way you can access your Craft data through GraphQL. Each schema comes with an access token, that you provide to Craft with your GraphQL query to identify which schema to pull data from. Each schema has its own permissions set, so you can limit access to types of data based on which schema they're allowed querying.

For this step, head over to Control Panel > GraphQL > Schemas, then create a new schema, give it the proper data permissions, and copy the access token.

3. Set up a route to your GraphQL API.

Add the following route to routes.php. This will allow you to send GraphQL queries to example.com/api.

// routes.php
return [
  'api' => 'graphql/api'
];

4. Set up your Craft API as a Gridsome data source

Assuming you have a working Gridsome installation up and running, the actual integration of your CMS data into the Gridsome GraphQL store is extremely simple!

First, you'll need to install the Gridsome source plugin for GraphQL:

npm install @gridsome/source-graphql
yarn add @gridsome/source-graphql

Then, add the following to your gridsome.config.js:

// gridsome.config.js
{
  use: '@gridsome/source-graphql',
  options: {
    url: process.env.CRAFT_API_URL,
    fieldName: 'craft',
    typeName: 'craft',
    headers: {
      Authorization: `Bearer ${process.env.CRAFT_API_TOKEN}`,
    }
  }
}

This gets us 90% of the way to a working integration, but it still won't work quite yet! You may have noticed the references to process.env variables for our API URL and token. This is what we'll set up in the next, and final, step.

5. Create a `.env` in your Gridsome project

If you're familiar with Craft, you've seen a .env file before. .env contains all of your "environmental variables": information specific to the environment you're working in. Gridsome takes this same approach to environmental variables, so we're going to create (or add to) a .env file in our Gridsome project.

# .env - in Gridsome project
CRAFT_API_URL=http://example.test/api
CRAFT_API_TOKEN=schemaAccessToken

That's it!

Now run gridsome develop and you're off to the races! You should be able to query your Craft data from anywhere within Gridsome now. To test everything, head over to the GraphQL playground and try sending the following request:

query {
  craft {
    ping
  }
}

If everything's working properly, the ping field should return pong.

If you have any comments/questions don't hesitate to leave a comment! I also love hearing when my articles were helpful to you, so leave a comment if these steps worked for you!

Using Axios with Craft and Vue

Jake Dohm — Fri, 22 Mar 2019 14:44:09 +0000

I spent a solid chunk of my morning digging through StackOverflow articles, documentation, and Twitter threads to try to find out how to submit a login form with Axios. If you've ever tried to use Axios or a similar library to make requests on a Craft CMS site, you know it's a very hairy experience.

But not anymore! I'm going to show you how to configure Axios to play nice with Craft, and then how to tie that into Vue. Note: the Vue part is optional, most of this article (steps 1-3) will work with any or no framework.

Preface

Before we get into how to accomplish a clean setup, it's nice to understand some of the challenges that we're facing. Here are the two main issues with using Axios with Craft:

Craft expects your data to be serialized, not JSON: If you attempt to send a JSON object to Craft, it won't accept it.
Craft expects a CSRF token, so that it can validate the request.

With these issues in mind, let's get started!

Guide

Step 1: Create an Axios instance

Our first step is to install Axios (npm install axios || yarn add axios), and create an instance of it that we'll use to make requests.

import axios from 'axios'

const axiosInstance = axios.create()

You can now use this Axios instance to make requests. Running axiosInstance.get('/endpoint') will work as expected!

You may be thinking "why create an instance when you can use Axios directly?" Great question! Creating an instance of Axios will allow us to configure it specifically for Craft, and attach our instance to Vue for use in any component.

Step 2: Add your CSRF token

Generally when making requests to Craft, I see people passing their CSRF token with every request, doing something like this:

const data = { greeting: 'Hello, World!' }
data[window.csrfTokenName] = window.csrfTokenValue
axios.post('/', data)

// note: this code won't actually work, because "data" isn't serialized

That method works fine, but it's clunky to have to attach your CSRF token to each request. Thankfully, there's a solution to this problem!

The Right Way™️

Craft will allow you to pass a X-CSRF-Token header with your request to bypass sending it along as a query parameter. Let's configure our Axios instance to send that header along automatically with each request, so we don't have to even think about it.

First, we need to output our CSRF token with Twig and put it somewhere that we can access.

{# index.twig #}

<script>
window.csrfToken = "{{ craft.app.request.csrfToken }}"
</script>

Then we can configure our Vue instance to add the X-CSRF-Token header:

const axiosInstance = axios.create({
    headers: {
        'X-CSRF-Token': window.csrfToken
    }
})

We've resolved one of our two challenges: Passing the CSRF token. Now let's tackle the second!

Step 3: Tell Axios to serialize your data

Before writing this article and trying to figure out a smooth workflow, here's how I would've tackled this problem.


import { stringify } from 'qs'

axios.post('/', stringify({ data: 'things' }))

Again, this works, but it's not ideal.

After some digging, I found a configuration option for Axios called transformRequest which allows us to transform the data we pass into a post request before sending it.

Let's update our Axios instance to automatically stringify our data:

import { stringify } from 'qs'

const axiosInstance = axios.create({
    headers: {
        'X-CSRF-Token': window.csrfToken
    },
    transformRequest: [
        function(data) {
            return stringify(data)
        },
    ],
})

Now we have a fully working Axios instance that takes care of passing our CSRF token and converting our data to the format which Craft expects!

Check out the difference between these snippets, and try to tell me that this configuration work isn't worth it!

// before
import { stringify } from 'qs'

const data = { greeting: 'Hello, World!' }
data[window.csrfTokenName] = window.csrfTokenValue
axios.post('/', stringify(data))

// after
axiosInstance.post('/', data);

Step 4: Attach your Axios instance to Vue

This last step makes it even easier to use Axios within our Vue components. We can attach our configured Axios instance to our Vue instance.

const axiosInstance = axios.create(config) // see above for config

Vue.prototype.$axios = axiosInstance

You can then make requests from within methods, lifecycles, etc. in your Vue components like this.$axios.get('/'). Here's a more real example:

Vue.component('things', {
    methods: {    
        getThings(data) {
            this.$axios.post('/', data);
        }
    }
}

Full Example

Here's the complete Twig/JS code for reference!

{# index.twig #}

<script>
    window.csrfToken = "{{ craft.app.request.csrfToken }}"
</script>

// index.js

import axios from 'axios'
import { stringify } from 'qs'

const axiosInstance = axios.create({
    headers: {
        'X-CSRF-Token': window.csrfToken,
    },
    transformRequest: [
        function(data) {
            return stringify(data)
        },
    ],
})

Vue.prototype.$axios = axiosInstance

Emulating Components in Twig

Jake Dohm — Tue, 22 Jan 2019 14:31:12 +0000

Components are one of my favorite things about JavaScript frameworks like Vue.js. They allow you to follow DRY principles by removing repetition of code in your markup, and they provide a fantastic developer experience. When I work in Twig templates, not having access to bona fide components is definitely one of the things I miss most. Because of that, I've been looking for a solution to this problem for a while.

Before I talk about the solutions I tried out, and the one I've landed on, let me first give you my criteria for what features I need out of components, or a component replacement.

Criteria

Props: I should be able to pass named parameters (usually referred to as "props") into my component.
Slots: I should be able to pass chunks of markup (HTML, text, whatever) into my component, and the component should determine what to do with that markup (i.e. where to render it).

If you have experience with Vue.js or another component-based framework, these concepts should be very familiar to you. If not, you'll have to trust me that once you've used these component features, trying to write markup without them is painful 😂

Explored Solutions

There were two main Twig features that I thought I could use to achieve component-like functionality within Twig: Macros and Includes.

Macros

So I started experimenting with Macros. If you're not familiar, Macros are the "functions" of Twig. Here's an example Macro (see more in the Twig docs):

{% import _self as components %}

{% macro button(props) %}
    <button>{{ props.content }}</button>
{% endmacro %}

<p>{{ components.button({ content: 'Click Me' }) }}</p>

Using Macros satisfied one criterion, passing props, but it didn't solve my problem of wanting to pass markup into my "component" via named slots.

Includes

Next, I tried Twig's Includes. Includes are a way to break up your code into multiple files, and I often use them to break up my page templates so they're smaller and to make things easier to search and find. But, they have a built-in feature, "with", that allows you to pass context (i.e. variables) into the include which made me hopeful that I could hack them into working well as components!

But again, they only satisfied the first criteria. There was no (built-in) way to pass in chunks of markup to be rendered within the component's markup.

Side note: Technically, for both Macros or Includes, I could do something hacky like assigning a variable to a bunch of markup and passing that variable in, but that felt very wrong and un-intuitive.

Final Solution

After giving up hope, I eventually stumbled upon Twig's Embeds. I read the documentation, and instantly got excited because Embeds seemed to satisfy both criteria right out of the box! I immediately coded up an example on TwigFiddle (twigfiddle.com) and I found that Embeds fully met both of my criteria: Using the "with" functionality and "blocks" I could pass props and chunks of markup into the embed.

Here's an example of embed declaration, and its use:

{% embed "page.twig" with {
    social: ['facebook', 'twitter', 'snapchat']
} %}
    {% block header %}
        <div>Header Content</div>
    {% endblock %}

    {% block main %}
        <div>Main Content</div>
    {% endblock %}
{% endembed %}

{# File: page.twig #}

<div class="page-component">
    <header>{% block header %}Default Header Content{% endblock %}</header>

    <main>{% block main %}Default Main Content{% endblock %}</main>

    <footer>{% block footer %}Default Footer Content{% endblock %}</footer>

    {% if social is defined %}
        <ul class="social">
            {% for item in social %}<li>{{ item }}</li>{% endfor %}
        </ul>
    {% endif %}
</div>

This method of emulating components in Twig isn't without its drawbacks, but I think it works well for most scenarios. Here are a few notes about the pros and cons of embeds:

Pros

You can pass in both props (variables) and slots (blocks).
You can specify default content for each block.
Using the "with only" feature, you can encapsulate your component so it won't implicitly receive any variables from the context in which it's used.

Cons

You have to specifically reference the embed's file path in every usage
You do have to use the "only" keyword to make sure your parent template's variables don't leak into the component.

Final Thoughts

I don't think Embeds are a fantastic long-term solution, and I'd love to have component functionality natively in Twig, but I was happy to find something that satisfies my needs and allows me to clean up my templates in the way that I'm comfortable with.

I'm also intrigued by Twig Components Bundle, a Symfony package that appears to add component functionality to Twig, based on the component system of Vue.js. But, I haven't tried it out yet. I'll make sure to report back if I do!

I work for an awesome company called Good Work. We are an expert team of web developers helping design teams at agencies, brands and startups build things for web and mobile.

If you're looking for someone to work with on your web projects, don't hesitate to reach out!

Using Tailwind with Gatsby JS

Jake Dohm — Thu, 03 Jan 2019 15:50:14 +0000

I'm beginning to rebuild my personal website using Gatsby JS, and of course I want to use my favorite CSS framework, Tailwind CSS! I searched around for a guide on how to use Gatsby and Tailwind together, and couldn't find anything with a full solution, so I decided to write this article as The Definitive Guide™ for how to set up Tailwind with Gatsby 😄.

FYI: If you follow this guide, hot reloading will still work and you'll also get reloading when you change your Tailwind configuration file!

Step 1: Install gatsby-plugin-postcss

gatsby-plugin-postcss is a Gatsby plugin that allows you to use PostCSS features in CSS files that you import into pages/components. Tailwind is built on PostCSS, so this is a great starting point!

To install the plugin, use your favorite package manager.

# Using NPM
npm install --save gatsby-plugin-postcss

# Using Yarn
yarn add gatsby-plugin-postcss

Step 2: Configure Gatsby to Use the PostCSS Plugin

Now that we've installed a plugin, we need to configure Gatsby to use it!

Open up your gatsby-config.js, and add 'gatsby-plugin-postcss' to the plugins array.

// gatsby-config.js

module.exports = {
    siteMetadata: { ... },
    plugins: [
        'gatsby-plugin-postcss',
        // ...
    ]
}

Step 3: Add PostCSS Config File

Our PostCSS plugin is installed, and Gatsby is using it, so all that's left is to configure the PostCSS side of things! To configure PostCSS, create an empty postcss.config.js file in your project's root (the same folder as the gatsby-config.js file).

Step 4: Install Tailwind

Now before we configure PostCSS to use Tailwind, we need to install it.

# Using NPM
npm install tailwindcss --save-dev

# Using Yarn
yarn add tailwindcss --dev

Step 5: Generate Tailwind Config File

To configure Tailwind, we'll need to add a Tailwind configuration file. Luckily, Tailwind has a built-in script to do this. Just run the following command (again, in your project's root directory).

./node_modules/.bin/tailwind init

This will create a tailwind.js file containing Tailwind's default configuration.

Step 6: Configure PostCSS

Okay, we've installed and configured Tailwind, now back to our PostCSS config. We need to add Tailwind to PostCSS's list of plugins.

// postcss.config.js

const tailwind = require('tailwindcss')

module.exports = () => ({
    plugins: [tailwind('./tailwind.js')],
})

In the example above, you'll see we're passing in a file path. That is the path to our configuration file. So if you'd like to move or rename the Tailwind configuration file, just remember to change the file path in your postcss.config.js file.

Note: You can add any other PostCSS plugins that you'd like to use, like autoprefixer, before or after Tailwind in the array of plugins.

Step 7: Add CSS File With Tailwind Directives

Everything should be ready to go, all we need to do now is to actually use Tailwind within our CSS! First, create a global.css file. I put mine at src/css/global.css. Then, add the following Tailwind directives to your new file:

// global.css

@tailwind preflight;

@tailwind components;

@tailwind utilities;

For this step, I opted to create a new global.css file, but you could just as easily put the Tailwind directives in an existing CSS file.

Step 8: Import Our Tailwind CSS

The last thing we need to do is to import our new CSS file into a page or layout so that our Tailwind CSS is actually injected into our pages. In layout.js, or wherever you want your Tailwind CSS to appear, add the following import:

// layout.js

import '../css/global.css'

You're Finished!

That's it, you should have a fully functional Tailwind + Gatsby setup, with Tailwind configuration, and Hot Reloading!

If you run into any trouble along the way, let me know in the comments and I'll happily help out and/or revise this article with any corrections!

I work for an awesome company called Good Work. We are an expert team of web developers helping design teams at agencies, brands and startups build things for web and mobile.

If you're looking for someone to help out on Gatsby, Vue, Tailwind, or other projects, don't hesitate to reach out!

New Mac Setup

Jake Dohm — Mon, 31 Dec 2018 16:03:48 +0000

A couple of months ago I purchased a 2015 27" iMac to use as my main development machine for work. As I started installing and configuring all of the apps and software I needed, I thought it would be fun to document everything, and share it with you all!

Let me know in the comments the apps that y'all have installed that would make my life easier!

I'll share the following categories of setup: Apps, Apps for Development, Apps for Work, Chrome Extensions, CLI Tools, and Configuration.

Apps

Chrome (daily browser)
Spotify
1Password
Alfred App (+ Powerpack)
Spectacle (window management)
Dropbox
Things (task management)
Notion (writing/organization)

Development Apps

Github Desktop
Sequel Pro (DB Management)
VS Code (extensions below)
- Cobalt2 Theme (Wes Bos)
- Import Cost
- Prettier - Code formatter (Esben Petersen)
- Vetur (Pine Wu)
- VS Live Share
- Twig (whatwedo)
- Twig for Craft 2 (Selvin Ortiz)
Transmit (FTP+)

Work Apps

Harvest app
Sketch
Photoshop (Adobe CC)
Illustrator (Adobe CC)

Chrome Extensions

1Password
Vue.js Dev Tools
Adblock (and Plus)
Poper Blocker
Privacy (awesome credit card privacy tool)

CLI Tools (in order)

Homebrew
Composer
Laravel Valet (local dev)
MariaDB
Node
Yarn
Xcode Command Line Tools

Configuration

I love almost everything about the way macOS works, so I only had to configure one thing: By default, screenshots are saved in PNG format, and medium/large screenshots usually end up around 2mb (in my experience). I would rather have screenshots saved as JPGs, because they are much smaller, and usually end up under 1mb.

To change this default, you can run a single command in Terminal:

defaults write com.apple.screencapture type jpg

Once you've changed the default, you have to restart a small bit of the OS for it to take effect:

killall SystemUIServer

Then you're done, and your screenshots will automatically be saved as .jpg files.

Finally

That's it! I purposefully did not install some applications that I have on my personal computer, because I am intending to use my iMac exclusively for work, so I'm trying to make it harder to get sidetracked 😬

5 Helpful Language Features Proposed for JavaScript (2018 edition)

Jake Dohm — Sat, 01 Dec 2018 16:32:02 +0000

Proposals

The features that I mention in this article have been proposed to TC39, the committee that moves JavaScript forward, but are not yet part of the standard that JavaScript conforms to.

There are 5 stages that a proposal goes through to land in JavaScript: Strawman, Proposal, Draft, Candidate, and Finished.

All of the following features are stage 1 proposals, which means they have met the guidelines for what a proposal must be, and have been presented to TC39. If you're interested in learning more about proposals and the process, head over to the official TC39 proposals repo.

Now, to the proposals!

Last Item

lastItem is proposed to be added to the array prototype, which would make it super easy to grab the last item in an array. I love this feature, because I think it's a step in the right direction to solve some common ergonomics issues in JavaScript.

const food = ['🌮', '🥑', '🥓'];

/* New syntax */
const bacon = food.lastItem; // 🥓

/* Old syntax */
const bacon = food[food.length - 1];

Optional Chaining

Optional Chaining is a proposal that streamlines the access of properties on potentially null or undefined types.

The reason we need this is because if object.thing isn't defined, and you write object.thing.test, JS won't just return null or undefined, it will actually throw an error: 🚩"Cannot read property 'test' of undefined".

const inputElement = document.querySelector('input[name=email]');

/* New Syntax */
const street = user.address?.street; // returns street value, or null
const inputValue = inputElement?.value; // returns input value, or null

/* Old Syntax */
const street = user.address && user.address.street;
const inputValue = inputElement ? inputElement.value : undefined;

How it works: If the item before the ? is null OR undefined, it will return null without processing the next item, otherwise it processes the next bit of the "chain". So in the example above, if the object user doesn't have a key of address, then it will return null. If it does, it will process the .street part, and return the value of user.address.street.

I was not a fan when I first saw this proposal, but I've come around on it. The syntax is a bit funky, but it will definitely simplify your codebase.

Null(ish) Coalescing Operator

This proposal allows you to check if a variable or statement is undefined or null and return a fallback value if it is.

/* New Syntax */
const one = undefined ?? 'Fallback'; // 'Fallback'
const two = null ?? 'Fallback'; // 'Fallback'

/* Old Syntax */
const one = undefined || 'Fallback';
const two = null || 'Fallback';

From looking at the above examples, you might think the Null Coalescing operator is totally unnecessary because it does the same thing as the OR operator. But they behave differently.

/* The differences between ?? and ||  */

const diffOne = 0 ?? 'Fallback'; // 0
const diffOne = 0 || 'Fallback'; // 'Fallback'

const diffTwo = '' ?? 'Fallback'; // ''
const diffTwo = '' || 'Fallback'; // 'Fallback'

const diffThree = false ?? 'Fallback'; // false
const diffThree = false || 'Fallback'; // 'Fallback'

How it works: The null coalescing operator returns the first thing that isn't null or undefined.

This is different from the way we usually check variables using || because the OR operator returns the first thing that's truthy. This means that if the value is false, an empty string, or null, it will not be returned; That can be a problem if one of those (false, null, empty string) is a valid value.

Do Block

The "do block" is a very interesting proposal, but it takes some getting used to. The syntax is simple: you write do, and then in brackets code you'd like to be executed. This feature would allow you to do some cool things that have been hard (or seemed hacky) in the past. Like when you have complex criteria for how to define a variable:

/* New Syntax */
const x = do {
    if (foo()) { f() }
    else if (bar()) { g() }
    else { h() }
};

/* Old Syntax */
let x = foo() ? f() : bar() ? g() : h();

// OR 

let x = (() => {
    if (foo()) return f();
    else if (bar()) return g();
    else return h();
}();

As mentioned in the official proposal, this syntax is especially helpful when used in templating languages like JSX.

return (
  <nav>
    <Home />
    {
      do {
        if (loggedIn) {
          <LogoutButton />
        } else {
          <LoginButton />
        }
      }
    }
  </nav>
);

Replace All

Wait, why do we need this again? We were already able to do string.replace('this', 'that'), right? But, replace only replaced the first instance of a string, unless you used a Regex. Again, this features solves a common "small problem" and makes things easier, especially for beginners 😄.

const string = '248.434.5508';

/* New syntax */
string.replaceAll('.', '-'); // returns '248-434-5508'

/* Old syntax */
string.replace(/\./g, "-");

Learning More

If you're interested in learning more about any of these potential features, you can check out the links to the official proposals below, or you can review all of the JS proposals.

Last Item: https://github.com/keithamus/proposal-array-last
Optional Chaining: https://github.com/tc39/proposal-optional-chaining
Null(ish) Coalescing Operator: https://github.com/tc39/proposal-nullish-coalescing
Do Block: https://github.com/tc39/proposal-do-expressions
Replace All: https://github.com/tc39/proposal-string-replace-all

DEV Community: Jake Dohm

Auto-registering all your components in Vue 3 with Vite

Why auto-register components?

How

Step 1+2: Glob Imports.

Step 3: Registering components

Putting it all together

How to make a GraphQL Query (or Mutation!) in PHP with Guzzle

1: Define a Query

2: Make the HTTP request

3: Retrieve the response

4: Put it all together

Defining "Done"

Different Types of Done

Problem #1: Frustration

Problem #2: Team Friction & Expectations

Problem #3: Inconsistency

How to define done

Lastly

Registering Global Components with Vue 3

Before

After

Why are these changes necessary?

Wrapping up

Using Tailwind in SASS with Gatsby JS

Step 1: Install Dependencies

Step 2: Configure gatsby-plugin-sass to use Tailwind

Step 3: Generate Tailwind Config File

Step 4: Add a SASS/SCSS File With Tailwind Directives

Step 5: Import Our Tailwind CSS

You're Finished!

Adding an "Update Browser" Banner for Legacy Browsers

One more thing

Quick Start: Gridsome + Craft CMS GraphQL API

5 Steps

1. Set up your Craft installation

2. Create a schema

3. Set up a route to your GraphQL API.

4. Set up your Craft API as a Gridsome data source

5. Create a .env in your Gridsome project

That's it!

Using Axios with Craft and Vue

Preface

Guide

Step 1: Create an Axios instance

Step 2: Add your CSRF token

Step 3: Tell Axios to serialize your data

Step 4: Attach your Axios instance to Vue

Full Example

Emulating Components in Twig

Criteria

Explored Solutions

Macros

Includes

Final Solution

Pros

Cons

Final Thoughts

Using Tailwind with Gatsby JS

Step 1: Install gatsby-plugin-postcss

Step 2: Configure Gatsby to Use the PostCSS Plugin

Step 3: Add PostCSS Config File

Step 4: Install Tailwind

Step 5: Generate Tailwind Config File

Step 6: Configure PostCSS

Step 7: Add CSS File With Tailwind Directives

Step 8: Import Our Tailwind CSS

You're Finished!

New Mac Setup

Apps

Development Apps

Work Apps

Chrome Extensions

CLI Tools (in order)

Configuration

Finally

5 Helpful Language Features Proposed for JavaScript (2018 edition)

Proposals

Last Item

Optional Chaining

5. Create a `.env` in your Gridsome project