DEV Community: Andrew Boyd

Using Zod with FormKit

Andrew Boyd — Thu, 18 May 2023 19:11:00 +0000

Starting with Beta 17 — FormKit ships with a new Zod plugin that you can use to validate your forms.

By leveraging Zod for your form validation you are able to use the same type-definitions to validate your application’s data on the front-end and the back-end — saving you time and reducing the opportunities for malformed data to find its way into your database.

The FormKit Zod plugin not only validates your data before it is submitted — it provides real-time validation feedback on a per-input level! No more giant block of Zod errors at the top or bottom of your form on submit. 🚀

It's easy to set up and use, so let's get started!

Installation

To start, we will need to install both the @formkit/zod and zod packages into our FormKit project.

# npm, yarn, pnpm — whatever you prefer
npm install @fomkit/zod zod

(Don't have FormKit set up in your project yet? Read the getting started docs here.)

Setup

Now in our project we will be able to import createZodPlugin from @formkit/zod and provide it with a schema we can define using the z import from zod.

createZodPlugin accepts two arguments:

zodSchema: The Zod schema that we define in our app (or more likely import from a shared location).
submitCallback: A function that receives valid formData and allows us to do something with it.

createZodPlugin returns a tuple with two values:

zodPlugin: The plugin that should be added to your target FormKit form.
submitHandler: The submit handler function to be attached to your target form. It is responsible for validating your form data against the provided Zod schema and calling your submitCallback when the data is valid.

The structure for setup in a Vue file looks like the following:

<script setup>
import { createZodPlugin } from '@formkit/zod'
import { z } from 'zod'

const zodSchema = z.object({
  // Zod schema here...
  // in a real app you probably import this 
  // from somewhere else.
})

const [zodPlugin, submitHandler] = createZodPlugin(
  zodSchema,
  async (formData) => {
    // a submit function here where we 
    // do something with our valid data.
  }
)
</script>

<template>
  <FormKit 
    type="form"
    :plugins="[zodPlugin]"
    @submit="submitHandler"
  >
     <!-- Your matching form structure here -->
  </FormKit>
</template>

A real example

Here is a full example — first the code block and then a live demo of the output — using the above setup code.

Note that there are no validation props on our FormKit components — all validation is being derived from the provided Zod schema.

<script setup>
import { createZodPlugin } from '@formkit/zod'
import { z } from 'zod'

const zodSchema = z.object({
  personalInfo: z.object({
    firstName: z.string().min(3).max(25),
    lastName: z.string().min(3).max(25),
  }),
  email: z.string().email(),
  features: z.string().array().min(2),
})

const [zodPlugin, submitHandler] = createZodPlugin(
  zodSchema,
  async (formData) => {
    // fake async submit handler, but this is where you
    // do something with your valid data.
    await new Promise((r) => setTimeout(r, 2000))
    alert('Form was submitted!')
    console.log(formData)
  }
)
</script>

<template>
  <h1>Validation from Zod schema</h1>
  <FormKit 
    type="form" 
    :plugins="[zodPlugin]" 
    @submit="submitHandler"
  >
    <FormKit type="group" name="personalInfo">
      <FormKit
        type="text"
        name="firstName"
        label="First Name"
      />
      <FormKit 
        type="text" 
        name="lastName" 
        label="Last Name" 
      />
    </FormKit>
    <FormKit 
     type="text" 
     name="email" 
     label="Your email" 
    />
    <FormKit
      type="checkbox"
      name="features"
      label="Zod features"
      :options="['Validation', 'Type-Safety', 'Reusability']"
    />
  </FormKit>
</template>

Here's the same example in an interactive demo with validationVisibility set to live for demonstration purposes. If your browser does not support the embed, click the Fork on StackBlitz button to open in a new tab.

Conclusion

That's a brief overview of the new Zod plugin that ships with FormKit. If you'd like to learn more you can read the official documentation on FormKit.com.

More of a visual learner? VueSchool.io has released a free 8-minute video that covers the FormKit Zod plugin. You can watch it for free here.

Now kneel before Zod!

Effortless Floating Labels for Inputs in Vue.js

Andrew Boyd — Wed, 08 Feb 2023 19:13:52 +0000

Have you ever seen those fancy floating label treatments on form inputs? They look something like this:

Wouldn't it be great if you could do that in your Vue projects in just a few lines of code?

Well — you can!

Setting up floating labels in your Vue Project

In order to quickly set up floating labels in our Vue project we'll be reaching for @formkit/vue, it's default theme from @formkit/themes and its floating label plugin from the @formkit/addons package — it's all free and open-source.

npm install @formkit/vue @formkit/themes @formkit/addons

Then in our Vue project, we'll install the supporting FormKit package and its floating label plugin.

// main.js
import { createApp } from 'vue'
import App from 'App.vue'
// FormKit imports
import { plugin as formKitPlugin, defaultConfig } from '@formkit/vue'
import { createFloatingLabelsPlugin } from '@formkit/addons'
import '@formkit/themes/genesis'
import '@formkit/addons/css/floatingLabels'

createApp(App)
  .use(formKitPlugin, defaultConfig({
    plugins: [createFloatingLabelsPlugin({
      // set to true to have floating labels be the default.
      // otherwise, use the `:floating-label` prop
      useAsDefault: true
    })]
  }))
  .mount('#app')

That's it! Now when we create a <FormKit /> input in the text family (things like text, textarea, number, url, date, etc) we will automatically have floating labels!

You can see it action and try it for yourself on the interactive FormKit playground:

https://formkit.link/9d2b7db47b0ed4eb1f6f49e545779101

Learn more about FormKit

FormKit is a free and open-source form framework for Vue.js.

Want to learn about FormKit and how it can help with form structure, validation, accessibility, and more?

Check out the floating label plugin docs at https://formkit.com/plugins/floating-labels
Join the FormKit Discord community for support, chat with the maintainers, and meet others using FormKit in their own projects: https://discord.gg/2q3UZkUQbR

Build a Multi-Step Form in Vue in 5 minutes.

Andrew Boyd — Mon, 06 Feb 2023 19:15:00 +0000

Few interactions on the web cause as much displeasure for a user as being confronted with a large, intimidating form. Multi-step forms can alleviate this pain by breaking a large form into smaller, approachable steps — but they can also be quite complicated to build.

In this guide, we'll walk through building a multi-step form with FormKit (a free and open-source form building framework) and see how we can provide an elevated user experience with minimal code. We'll be done in approximately 5 minutes. Let's get started!

Not familiar with FormKit? It's a free and open-source framework for building forms in Vue and you can learn more about it here.

Installation

To get started we need to install FormKit, its supporting default theme, and the FormKit Multi-Step plugin into our project:

npm install @formkit/vue @formkit/addons @formkit/themes

Then we add FormKit to our Vue app, add the Multi-Step Plugin to our FormKit config, and ensure that we're including the necessary styles:

// main.js
import { createApp } from 'vue'
import App from 'App.vue'
// FormKit imports
import { plugin as formKitPlugin, defaultConfig } from '@formkit/vue'
import { createMultiStepPlugin } from '@formkit/addons'
import '@formkit/themes/genesis'
import '@formkit/addons/css/multistep'

createApp(App)
  .use(formKitPlugin, defaultConfig({
    plugins: [createMultiStepPlugin()]
  }))
  .mount('#app')

Usage

Out-of-the-box, FormKit ships with every native HTML input available to you. Things like text, select, checkbox, etc.

createMultiStepPlugin registers two brand-new input types for you to use with FormKit — in exactly the same way you use any other input type.

multi-step: The wrapping group for the entire multi-step input.
step: The wrapping group for a given step within your multi-step input.

Using these inputs together is as simple as wrapping any markup you want to have present within a step in a multi-step form:

<FormKit type="multi-step">
  <FormKit type="step" name="stepOne">
    <!-- content for stepOne goes here! -->
  </FormKit>
</FormKit>

So — let's build a quick form for users who want to submit a talk to our upcoming fake conference, VueUniverse.

We'll want to:

Collect some contact information for the user.
Get a brief overview of the talk the user wants to give.
Ask the user how they heard about VueUniverse.

Those sound like good groupings for our steps — so let's get started:

<FormKit type="form">
  <FormKit type="multi-step">
    <FormKit type="step" name="contactInformation">
      <!-- collect name, email, and company info -->
      <FormKit 
        type="text" 
        label="Your Name" 
        validation="required"
      />
      <FormKit 
        type="email" 
        label="Your Email" 
        validation="required|email" 
      />
      <FormKit 
        type="text" 
        label="Your Company (optional)"
        help="Are speaking on behalf of an organization?"
      />
    </FormKit>

    <FormKit type="step" name="talkDetails">
      <!-- Get talk title, brief, and track -->
      <FormKit 
        type="text" 
        label="Talk Title" 
        validation="required"
      />
      <FormKit 
        type="textarea" 
        label="Talk Brief" 
        validation="required|length:100"
        help="What is your talk about?"
      />
      <FormKit 
        type="radio" 
        label="Talk Track"
        help="Which track are you submitting for?"
        :options="['Development', 'Testing', 'Leadership']"
      />
    </FormKit>

    <FormKit type="step" name="referral">
      <!-- Ask the user to share how they heard about us -->
      <h2>Thank you for taking the time to submit your talk</h2>
      <p>If you don't mind we'd love to know how you heard about VueUniverse.</p>
      <FormKit 
        type="radio" 
        label="How did you hear about VueUniverse?" 
        :options="['Online Ad', 'Friend or Coworker', 'Search Results', 'Other']"
      />
    </FormKit>
  </FormKit>
</FormKit>

And there we go! One component, FormKit, with a consistent API and we've got ourselves a working multi-step form with validation!

(for the best experience open this example in a new tab)

That's great! But there's two things we can change to make it better.

Since we're using the multi-step input as our entire form experience it would be great to have the submit button be inside the last step rather than external to the multi-step input.
We're asking users to go through a set flow, so it would be great if our tabs indicated progress. Additionally it would be great if we prevented the user from navigating to the next step until the current step is completed.

Thankfully, these are both very easy changes to implement.

First we need to set :actions="false" on our wrapping form type FormKit component to disable the default submit button. Then, using the stepNext slot we can insert our own submit button inside the last step in our multi-step form.
Second, we need to use the tab-style="progress" and allow-incomplete="false" props to show progress-style tabs and prevent the user from freely navigating through steps until validation is passed.

Here are the relevant sections of our form with those changes implemented:

<!-- remove default actions on the form -->
<FormKit 
  type="form"
  :actions="false"
>
  <!-- Set new props on our multi-step -->
  <FormKit 
    type="multi-step"
    tab-style="progress"
    :allow-incomplete="false"
  >
    ...
    <!-- In our last step, add a submit button -->
    <FormKit type="step" name="referral">
      ...
      <template #stepNext>
        <FormKit type="submit" />
      </template>
    </FormKit>
  </FormKit>
</FormKit>

And again, that's it! FormKit takes care of the rest for us. Here is our new and improved multi-step form experience after changing those 6 lines of code.

(for the best experience open this example in a new tab)

Best of all this form has accessible markup, built-in validation, and much more that we didn't have to worry about ourselves thanks to the underlying FormKit component architecture.

Conclusion

Quick, easy, powerful. Implementing a multi-step form in your project has never been simpler.

By leveraging FormKit in your Vue projects you can supercharge your form development and build rich and complex user-experiences in a fraction of the time — for free.

Want to learn more about FormKit and how it can help with form structure, validation, accessibility, and more?

Check out the multi-step docs at https://formkit.com/plugins/multi-step
Join the FormKit Discord community for support and to meet others using FormKit in their own projects: https://discord.gg/2q3UZkUQbR

Creating a Tailwind CSS theme for FormKit

Andrew Boyd — Thu, 10 Mar 2022 20:30:16 +0000

FormKit ❤️ Tailwind CSS

FormKit ships with first-class support for Tailwind CSS.

For small projects – using Tailwind CSS with FormKit can be as easy as using the inline class props available on the <FormKit /> component. For more advanced use cases FormKit ships with a package (@formkit/tailwindcss) that makes creating a robust Tailwind CSS theme a breeze.

The following guide will walk you through both processes and show you how they can work together to provide incredible flexibility when styling your FormKit inputs.

This guide assumes you are using a standard Vue 3 build tool like Vite, Nuxt 3, or Vue CLI that will allow you to import .vue single file components.

Inline usage for simple use cases

If FormKit represents a small portion of your project — say a single contact form on a brochure website — then you'll likely be able to apply all the styling you need using the ${sectionKey}-class props or the classes prop available on the <FormKit /> component.

Here's a contact form styled using only the classes prop for a FormKit form:

<template>
  <FormKit
    type="form"
    :actions="false"
    :config="{
      // config override applies to all nested FormKit components
      classes: {
        outer: 'mb-5',
        label: 'block mb-1 font-bold text-sm',
        input: 'text-gray-800 mb-1 w-full',
        help: 'text-xs text-gray-500',
        message: 'text-red-500 text-xs',
      },
    }"
  >
    <FormKit
      type="text"
      label="Name"
      help="First and last name"
      validation="required"
      :classes="{
        input: 'border border-gray-400 py-1 px-2 rounded-md',
      }"
    />
    <FormKit
      type="email"
      label="Email"
      validation="required|email"
      :classes="{
        input: 'border border-gray-400 py-1 px-2 rounded-md',
      }"
    />
    <FormKit
      type="textarea"
      label="Message"
      validation="required|length:10"
      :classes="{
        input: 'border border-gray-400 py-1 px-2 rounded-md',
      }"
    />
    <FormKit
      type="submit"
      label="Submit"
      :classes="{
        outer: 'mb-0',
        input: 'bg-blue-500 text-white font-bold py-2 px-3 rounded-md w-auto',
      }"
    />
  </FormKit>
</template>

This is a low-barrier way to apply Tailwind CSS styles to your FormKit forms. But what if you have multiple forms? Copy-pasting class lists between components is not ideal and can lead to inadvertent variations in styling across your project over time.

Let's explore how we can apply Tailwind CSS classes globally to all FormKit inputs within our project.

Using `@formkit/tailwindcss`

FormKit ships with a first-party package called @formkit/tailwindcss that makes it simple to create a Tailwind CSS theme for FormKit.

This package allows you to author your theme as a JavaScript object grouped by input type and sectionKey. Additionally, it exposes a number of Tailwind CSS variants based on FormKit state such as formkit-invalid: and formkit-disabled: which allow you to dynamically change your input styling.

To get started we first need to add the package to our project.

npm install @formkit/tailwindcss

From there we need to:

Add the @formkit/tailwindcss plugin to our project's tailwind.config.js file.
Import generateClasses from @formkit/tailwindcss and use it where we define our FormKit config options.

// tailwind.config.js
module.exports {
  ...
  plugins: [
    require('@formkit/tailwindcss').default
  ]
  ...
}

// app.js
import { createApp } from 'vue'
import App from './App.vue'
import { plugin, defaultConfig } from '@formkit/vue'
import { generateClasses } from '@formkit/tailwindcss'
import '../dist/index.css' // wherever your Tailwind styles exist

createApp(App)
  .use(
    plugin,
    defaultConfig({
      config: {
        classes: generateClasses({
          // our theme will go here.
          // ...
          // text: {
          //   label: 'font-bold text-gray-300',
          //   ...
          // }
          // ...
        }),
      },
    })
  )
  .mount('#app')

Once this setup is complete we are ready to begin writing our Tailwind CSS theme!

Our first Tailwind CSS input

To start, let's apply some classes to a text style input. This will cover a large surface area because we'll be able to easily re-use these styles on other text-like inputs such as email, password, date, etc.

To specifically target text inputs we'll create a text key in our theme object and then apply classes to each sectionKey as needed.

Here is a text input with Tailwind CSS classes applied using our default FormKit config values:

import { createApp } from 'vue';
import App from './App.vue';
import { plugin, defaultConfig } from '@formkit/vue';
import { generateClasses } from '@formkit/tailwindcss';

createApp(App)
  .use(
    plugin,
    defaultConfig({
      config: {
        classes: generateClasses({
          text: {
            outer: 'mb-5',
            label: 'block mb-1 font-bold text-sm',
            inner: 'bg-white max-w-md border border-gray-400 rounded-lg mb-1 overflow-hidden focus-within:border-blue-500',
            input: 'w-full h-10 px-3 bg-transparent border-none focus:outline-none text-base text-gray-700 placeholder-gray-400 focus:outline-none',
            help: 'text-xs text-gray-500',
            messages: 'list-none p-0 mt-1 mb-0',
            message: 'text-red-500 mb-1 text-xs',
          },
        }),
      },
    })
  )
  .mount('#app');

Using variants

That's looking good! But it's fairly static at the moment. It would be nice if we could react with different styles based on the state of our inputs.

The @formkit/tailwindcss package provides a number of variants you can use in your class lists to dynamically respond to input and form state.

The currently shipped variants are:

formkit-disabled:
formkit-invalid:
formkit-errors:
formkit-complete:
formkit-loading:
formkit-submitted:
formkit-multiple:
formkit-action:
formkit-message-validation:
formkit-message-error:

You can use these variant the same way you would use built-in Tailwind CSS variants such as dark: and hover:.

Let's add some variants for formkit-invalid and formkit-disabled to our text input styles.

export default {
  text: {
    outer: 'mb-5 formkit-disabled:opacity-40',
    label: 'block mb-1 font-bold text-sm formkit-invalid:text-red-500',
    inner: `
      max-w-md
      border border-gray-400
      rounded-lg
      mb-1
      overflow-hidden
      focus-within:border-blue-500
      formkit-invalid:border-red-500
    `,
    input: 'w-full h-10 px-3 border-none text-base text-gray-700 placeholder-gray-400 focus:outline-none',
    help: 'text-xs text-gray-500',
    messages: 'list-none p-0 mt-1 mb-0',
    message: 'text-red-500 mb-1 text-xs',
  },
};

Creating a full theme

Now we're cooking! To create a comprehensive theme we need to define class lists for the sectionKeys of all of the other input types we'll use in our project.

Before we go too far though, there are some improvements we can make.

The generateClasses function in @formkit/tailwindcss allows for a special input type key called global that will apply to all inputs. This is helpful for targeting sectionKeys such as help and messages that are often styled identically across all input types within a project.

Let's create class list definitions for all input types included in FormKit. We'll group common types of inputs into "classifications" to avoid being too repetitive.

// We'll create some re-useable definitions
// because many input types are identical
// in how we want to style them.
const textClassification = {
  label: 'block mb-1 font-bold text-sm formkit-invalid:text-red-500',
  inner: 'max-w-md border border-gray-400 formkit-invalid:border-red-500 rounded-lg mb-1 overflow-hidden focus-within:border-blue-500',
  input: 'w-full h-10 px-3 border-none text-base text-gray-700 placeholder-gray-400',
}
const boxClassification = {
  fieldset: 'max-w-md border border-gray-400 rounded-md px-2 pb-1',
  legend: 'font-bold text-sm',
  wrapper: 'flex items-center mb-1 cursor-pointer',
  help: 'mb-2',
  input: 'form-check-input appearance-none h-5 w-5 mr-2 border border-gray-500 rounded-sm bg-white checked:bg-blue-500 focus:outline-none focus:ring-0 transition duration-200',
  label: 'text-sm text-gray-700 mt-1'
}
const buttonClassification = {
  wrapper: 'mb-1',
  input: 'bg-blue-500 hover:bg-blue-700 text-white text-sm font-normal py-3 px-5 rounded'
}

// We'll export our definitions using our above
// classification templates and declare
// one-offs and overrides as needed.
export default {
  // the global key will apply to _all_ inputs
  global: {
    outer: 'mb-5 formkit-disabled:opacity-50',
    help: 'text-xs text-gray-500',
    messages: 'list-none p-0 mt-1 mb-0',
    message: 'text-red-500 mb-1 text-xs'
  },
  button: buttonClassification,
  color: {
    label: 'block mb-1 font-bold text-sm',
    input: 'w-16 h-8 appearance-none cursor-pointer border border-gray-300 rounded-md mb-2 p-1'
  },
  date: textClassification,
  'datetime-local': textClassification,
  checkbox: boxClassification,
  email: textClassification,
  file: {
    label: 'block mb-1 font-bold text-sm',
    inner: 'max-w-md cursor-pointer',
    input: 'text-gray-600 text-sm mb-1 file:mr-4 file:py-2 file:px-4 file:rounded-full file:border-0 file:text-sm file:bg-blue-500 file:text-white hover:file:bg-blue-600',
    noFiles: 'block text-gray-800 text-sm mb-1',
    fileItem: 'block flex text-gray-800 text-sm mb-1',
    removeFiles: 'ml-auto text-blue-500 text-sm'
  },
  month: textClassification,
  number: textClassification,
  password: textClassification,
  radio: {
    // if we want to override a given sectionKey
    // from a classification we can do a spread
    // of the default value along with a new
    // definition for our target sectionKey.
    ...boxClassification,
    input: boxClassification.input.replace('rounded-sm', 'rounded-full'),
  },
  range: {
    inner: 'max-w-md',
    input: 'form-range appearance-none w-full h-2 p-0 bg-gray-200 rounded-full focus:outline-none focus:ring-0 focus:shadow-none'
  },
  search: textClassification,
  select: textClassification,
  submit: buttonClassification,
  tel: textClassification,
  text: textClassification,
  textarea: {
    ...textClassification,
    input: 'block w-full h-32 px-3 border-none text-base text-gray-700 placeholder-gray-400 focus:shadow-outline',
  },
  time: textClassification,
  url: textClassification,
  week: textClassification,
}

Selective overrides

And there we have it! All FormKit inputs are now styled with Tailwind CSS classes across our entire project.

If we ever need to override any specific one-offs within our project, we can do so using the section-key class props or the classes prop on a given FormKit element.

Of particular importance when performing an override is the $reset modifier.

When the FormKit class system encounters a class named $reset it will discard the current class list for the given sectionKey and only collect class names that occur after the $reset class. This is helpful for systems like Tailwind CSS where it can be cumbersome to override a large number of classes when you need to deviate from your base theme.

<template>
  <FormKit
    type="text"
    label="I use the global theme we defined"
    help="I play by the rules"
  />
  <FormKit
    type="text"
    label="I'm special and have a $reset and custom styles"
    help="I'm a rebel"
    label-class="$reset italic text-lg text-red-500"
    help-class="$reset font-bold text-md text-purple-800"
  />
</template>

Next steps

This guide has walked through creating a Tailwind CSS theme for all input types included in FormKit, but there is still more that could be done!

Here are some ways to take the above guide even further:

Add dark-mode support using the built-in Tailwind CSS dark: modifier.
Combine multiple variants such as formkit-invalid:formkit-submitted: to add extra emphasis to invalid fields when a user tries to submit an incomplete form.
Publish your theme as an npm package for easy importing and sharing between projects.

If you want to dive in deeper into FormKit there's plenty to learn about the core internals of the framework as well as the FormKit schema which allows generating forms from JSON with conditionals, expressions, and more!

Now go forth and make beautiful forms!

Details Matter: Add a Visual Grid System to your Front-end Development Process

Andrew Boyd — Tue, 07 Jul 2020 15:49:20 +0000

Front-end engineers are responsible for translating visual designs into working code for the web. The target that we aim for is a faithful translation of source design files into code. The holy grail would be to put a screenshot of the design and a screenshot of the accompanying final product side-by-side and be unable to tell which was which.

Above are screenshots of the design file for Outdoor Dreams alongside the final browser build (with the front-end visual grid turned on). Are you able to tell which one is from the browser and which one is from Sketch?

As front-end engineers, to varying degrees, we often miss the mark. Sometimes it's because the designs themselves were unfeasible — lacking in consistency and not lending themselves to being faithfully reproduced within a given project’s budget. Other times it’s because we set ourselves up for failure by allowing guesswork to enter our process through poor architecture. It's time to level up.

Evolution of the digital design ecosystem

The tooling available to digital designers has evolved by leaps and bounds over the past several years. We’ve gone from the dark days of using print-focused design tools such as Adobe Photoshop to create web layouts to witnessing an explosion of digital-native design tools in the form of Sketch, Adobe XD, Figma and more. Beyond that, the design language of the web itself has evolved — more and more designers are breaking the bounds of what audiences have come to expect from layouts on the web.

There was a time as an engineer where you’d be safe to assume a design would map to a 12-column grid and any number of off-the-shelf CSS grid systems would suit your needs. 12-columns has been historically considered an ideal number of columns to work with due to 12 being such a highly divisible number. Many tools emerged onto the scene under the assumption that whatever you wanted to build could be suitably done with 12 columns.

In present-day, however, designers have declared “conventional wisdom be damned!” and the days of the 12-column one-size-fits-all layout system are gone.

Good! More power to them. It’s time to rethink our preconceived limitations for layout on the web and allow it to mature into the editorial design-forward platform we all know it’s capable of being. As front-end engineers, it’s our responsibility to rise to the challenge and ensure that we’re equipping ourselves to hit the mark being set for us by our designer colleagues. But how do we remove the guesswork and give ourselves the tooling necessary to faithfully reproduce the designs we are tasked with developing?

A flawed process

The current standards for a typical front-end development process are not ideal. We reference design files as we write our code — comparing the designs and the browser results side-by-side via visual inspection. This process involves tinkering with the design file to get the exact measurements you need, writing the code to produce those measurements in the browser, and then comparing the results visually to confirm they look correct — or at least correct within tolerable approximation. We spend a large amount of our time adjusting our code to accurately represent provided designs but when it's time to verify the results we do so via error-prone visual inspection.

This sucks. It's time to level up our process so that we can produce better results. “Good enough” isn't good enough.

The designs we reference are painstakingly produced with a precise grid and visual overlays to assist the designer. In the browser, the absence of those helpful visual indicators means that small imperfections often go overlooked (or worse, ignored). Why don’t we bring those visual indicators into the browser as part of our engineering process so that we can better hit the mark of 1:1 parity between design and front-end development? It’s a good question and one that we’re actively addressing at Braid.

Now you see it

Our answer is this: Precisely recreate the visual grid overlay in the browser and use a system that enforces it. The designer you’re collaborating with deliberately configured the grid, intentionally adhered to it, at times tastefully deviated from it, and a part of their soul withers if you completely ignore it. Give yourself the advantage of removing the guesswork. See for yourself when you've faithfully reproduced a design.

To assist our own team with this we authored Griddle, an open-source set of .scss functions and mixins that allow engineers to configure a flexible visual grid system for their projects. Griddle comes out of the box with a Vue component that adds a visual overlay to your project in the browser.

In short (read the readme.md for the long version), Griddle aspires to make minimal assumptions about your grid system. Your designer provided you with a 14-column grid with a 72px / 32px column-to-gutter ratio at the largest breakpoint? No problem. Configure your overrides for Griddle in your own .scss files using the layout information found in the source design file.

Once installed and configured, you'll be able to toggle the Griddle overlay in your project (control + shift + L) revealing an identical set of visual column indicators in your browser as the ones seen in your design program. You can try it out in a few different configurations here, here, or on our own site here if you want to see it in action for yourself.

Conclusion

By equipping ourselves with the same visual grid overlay being used by our designer colleagues we remove almost all of the guesswork inherent to visual side-by-side inspection.

Griddle itself is nothing magical, it’s a fixed-position overlay being calculated with some basic math from your provided configuration. Use it, or write your own. But no matter what you do, ensure that you’re taking steps to set yourself up for success. Rise to the occasion and aspire to faithfully reproduce the work being entrusted to us as front-end engineers. 1:1 is the target, and in many cases, there’s no reason to not hit that mark.

Oh, and in case you’re curious, in the comparison screenshot at the beginning of the article, the browser version is on the left. 🙂

DEV Community: Andrew Boyd

Using Zod with FormKit

Installation

Setup

A real example

Conclusion

Effortless Floating Labels for Inputs in Vue.js

Setting up floating labels in your Vue Project

Learn more about FormKit

Build a Multi-Step Form in Vue in 5 minutes.

Installation

Usage

Conclusion

Creating a Tailwind CSS theme for FormKit

FormKit ❤️ Tailwind CSS

Inline usage for simple use cases

Using @formkit/tailwindcss

Our first Tailwind CSS input

Using variants

Creating a full theme

Selective overrides

Next steps

Details Matter: Add a Visual Grid System to your Front-end Development Process

Evolution of the digital design ecosystem

A flawed process

Now you see it

Conclusion

Using `@formkit/tailwindcss`