Forem: Zane Milakovic

How we built cross-region uptime verification (and why single-location monitoring is broken)

Zane Milakovic — Sun, 01 Mar 2026 16:15:52 +0000

If you've ever been woken up at 3am by a monitoring alert that turned out to be nothing, you already understand the problem.

Most uptime monitoring works like this: a server in Virginia pings your site every minute. If it gets a bad response, it sends you an alert. Simple, effective, and wrong about 20% of the time.

That number isn't made up — it's roughly what I saw across my own client sites over two years of using various monitoring tools. About one in five alerts was a false positive caused by network routing issues, transient DNS problems, or a brief hiccup at the monitoring provider's own data center.

The fix is obvious (in hindsight)

When a check fails, don't immediately alert. Instead, trigger verification checks from other regions. If Chicago says your site is down but Amsterdam, Virginia, and Singapore all say it's fine — that's not an outage. That's a network blip.

This is what I built into FlareWarden. Here's roughly how it works:

Step 1: Initial check fails. One of our 18 monitoring regions reports a failure. Timer starts.

Step 2: Cross-region verification. We immediately fire checks from multiple other regions. The number of confirming regions required is configurable — you might want 2 out of 3 for a personal project, or 4 out of 5 for production infrastructure.

Step 3: Consensus determines outcome. If verification checks confirm the outage, alert fires. If they don't, we log it as a regional issue and move on. You sleep through the night.

The whole verification loop typically completes in 30-60 seconds. Fast enough to catch real outages quickly, slow enough to filter out noise.

The parent/child thing

The other architectural decision I'm pretty happy with is the monitor hierarchy.

Traditional monitoring gives you a flat list: site A is up, site B is down. But that's not how web apps actually work. Your e-commerce site depends on Stripe for payments, Cloudflare for CDN, maybe Shopify for inventory. When Stripe goes down, your site isn't down — checkout is broken but the rest works fine.

FlareWarden uses a parent/child model. Your main site is the parent monitor. Dependencies like Stripe or your CDN are child monitors of type "dependency." When a dependency fails, the parent status changes to "degraded" rather than "down." Content monitors (checking that specific text exists on a page) are independent children — they alert you directly without affecting the parent status.

This means your status page automatically reflects what's actually happening: "Website operational, payment processing degraded" is way more useful than "Website down."

Auto-discovery

The last piece I wanted to get right was setup friction. Configuring monitors manually for every domain, every SSL cert, every third-party integration — it's tedious and you always miss something.

FlareWarden's Smart Setup scans your URL and automatically identifies: third-party service dependencies (we recognize 700+ services), SSL certificate details and expiry dates, critical page content that should always be present, and your overall tech stack.

You paste a URL, review what it found, and click confirm. Full monitoring in about two minutes.

If you want to try it

Free tier is 15 monitors with 5-minute checks, no credit card, no expiry. I'm running founding member pricing (40% off forever) on paid plans through June if you want faster checks or more monitors.

https://flarewarden.com

Would genuinely love technical feedback from this community. The verification logic, the monitor hierarchy, the auto-discovery — poke holes in any of it. That's how it gets better.

An Unexpected Benefit of Tailwind CSS

Zane Milakovic — Tue, 03 Dec 2019 00:00:00 +0000

CSS has been around for a long time now. I have been using it for over a decade. In that time, we went from keeping it as a single separate file to using naming conventions and pre-processors. Moving past Atomic, BEM, and SMACSS, we started to put the CSS directly into the JavaScript. And to be honest, it has slowed down development for me.

So when I built Khrome.dev earlier in the year, with the goal of building it in a single day, I choose to use Tailwind CSS as an experiment. It felt like moving back in time in a lot of ways, and I was really drawn to the approach of composing classes in HTML. Basically, never having used it before, it felt simple and easy to grasp. And it got out of my way to let me build quickly.

For those not familiar, Tailwind CSS is a utility-first framework that really tries to focus on giving you the building blocks to craft what you need. I am very much against CSS frameworks because of the opinionated styles. But Tailwind CSS is different, it's just basic properties with some well-defined defaults. Anything I didn't like, I replaced.

The Easiest Refactor Ever

Due to a project at work, I decided to migrate my personal blog I had just launched from Vue to Svelte. It was an experiment to ensure the technology choice was a wise one. I ended up liking the outcome and merging the branch into the master branch at the beginning of October.

The refactor took a lot longer than expected, but not because of Svelte or Vue. It was replacing the functionality I was getting from Gridsome that really cost me time. I had to replace the GraphQL file system interface to processing the markdown files. I also had to write custom code to handle the RSS feed and sitemap generation.

The only part that was not hard, was the styling. The act of actually migrating the HTML and Styles from Vue to Svelte.

Refactoring a Component

Vue uses a template structure that is basically HTML with some custom templates. Here is my Hero tile on the homepage of Khrome.dev. I choose a simple presentation component on purpose.

<template>
  <div
    class="bg-regal-blue text-white overflow-hidden bg-repeat"
    style="background-image: linear-gradient(to bottom, rgba(40,69,105,0) 0%,rgba(36,60,90,1) 80%), url('./dots.svg');"
  >
    <div class="hero container-inner mx-auto flex flex-col justify-between py-16">
      <div class="mt-8 sm:mt-0">
        <g-image src="../../static/code_review.svg" alt="hero" class="mx-auto sm:mx-0" />
      </div>
      <div class="text-4xl font-bold w-full text-center mt-16">
        <div class="text-white">
          I build
          <strong class="text-orange-700">products</strong>  &amp; 
          <strong class="text-orange-700">teams</strong>.
        </div>
      </div>
    </div>
  </div>
</template>

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

Here is the same component in Svelte.

<div
    class="bg-regal-blue text-white overflow-hidden bg-repeat"
    style="background-image: linear-gradient(to bottom, rgba(40,69,105,0) 0%,rgba(36,60,90,1) 80%), url('./dots.svg');"
>
  <div class="hero container-inner mx-auto flex flex-col justify-between py-16">
    <div class="mt-8 sm:mt-0">
      <img src="../../static/code_review.svg" alt="hero" class="mx-auto sm:mx-0" />
    </div>
    <div class="text-4xl font-bold w-full text-center mt-16">
      <div class="text-white">
        I build
        <strong class="text-orange-700">products</strong>  &amp; 
        <strong class="text-orange-700">teams</strong>.
      </div>
    </div>
  </div>
</div>

It is really difficult to notice the difference. Basically the <template> tag needed to be removed, and the Gridsome specific <g-image> tag needed to be replaced with a plain old HTML compliant <img> tag.

The Benefits of Utility-first frameworks

At first glance, this may seem like a silly example. But that is the beautify. For every line template code that I migrated over, I only brought with it the CSS I used.

Another way to look at this --- during the redesign I made a few decisions, like removing the search interface. Those components were not brought over, and the CSS was not included automatically.

Yes, you can get some of those benefits from CSS in JS or having component-specific CSS files. But I did not have to change any tooling. And if I removed part of a component, the CSS for that piece is gone as well.

Utility-first frameworks like Tailwind CSS, are an elegant and simple solution to solving the issues we all face when refactoring or removing dead HTML. How do we ensure the CSS is also correctly removed?

Originally published on Khrome.dev.

The Rise of Privacy Focused Analytics

Zane Milakovic — Mon, 02 Dec 2019 00:00:00 +0000

Privacy is growing to be a more significant concern in your user's minds. Every week it seems that a new scandal is surfacing over at Facebook that is making headlines. Or we have a smart gadget that hides a microphone for years. Zoom's teleconference software was recently revealed with a security mistake. It was installing a hidden unsecured server for the 's consent. The trending headlines teach us not to trust the tech companies with our information. Why should your users trust you?

Changes are happening in the public eye. The EU signed the GDPR in 2016, the biggest data privacy regulation in over 20 years. Companies recently facing scrutiny are scrambling to try to change their public image. Yes, Facebook announced on the switch to be a privacy-focused company, but they rely on ad revenue. How can they be?

How can we trust these mega tech corporations to power our analytics? Actionable insights these tools provide come at a cost, the abuse of our user's data. There is a reason Google Analytics is free. The data they collect is the payment, and then some. It's time you and I are responsible for our users. After all, we both want to make products that users can trust.

The Data We Need

The point of website analytics is to delve information that is meaningful to us about our users. The information we need boils down to a few themes.

We need to understand growth.
We need to understand some basics about our audience.
We need to understand what technology we need to support.

Growth

This is a pretty basic concept that has been a staple since the early days of the web. Are we gaining or losing visitors? Where are those visitors going on our site? How are they getting to our site?

Demographics

As the internet grew and sites became more global, we started asking about our users. From what countries are our visitors from? Are we supporting the locales?

Technology

We need to understand how to support our audience. Techniques have exploded for capturing user data. The devices to access the web have changed. There is more surface area than ever. What browsers are they using? What physical devices did they connect with? What was the screen size of those devices?

These basic data concepts can power a wave of changes to our business from changing where to advertise due to inbound sources changing. Or we may focus on our mobile experience because the user base shifted over the last few months.

The Cost of Privacy

Privacy-focused solutions tend to capture a lot less data. Does this make them less beneficial? But it depends on your specific needs. Analytics suites tend to have a lot of tools that go underused and don't serve any of the sites using them. But your paying for these extra features with the data you capture about your users.

Most of the information our business need to get recorded in privacy-focused tools. So what is the difference? What are you giving up? The answer is it depends.

A privacy-focused toolset means we may understand less about our users. But we were also less invasive and more transparent. Google Analytics, for example, shows demographic data around age or gender. It does so by marring data about your users from across the internet. Your site visitors viewing habits and interests are also identified. Many of these are invasive data points. Yes, they may help you target an ad campaign. After all ad buying one of Google's primary sources of revenue. So if we lose all that information, how do we capture it? What did we do before Google Analytics? We use to survey our audience. The users self identify, and opt into questions they were willing to answer. And it was responsible and transparent.

Privacy-focused analytics can have a higher cost. Either a monetary cost like a monthly fee. Even though the fee is very low, it can feel hard to justify if you spent years not pay for Google Analytics. Or the tools need more overhead like self-hosting, infrastructure, and technical setup.

You will have to judge for yourself if you can live without the features, or do the setup. But the result is you will be no longer tracking unneeded data about your users.

The New Breed of Analytics

Privacy-focused analytics is not new. In the early days of the web analytics captured very little information. The mechanisms to capture data and marry data were not available. Yet, we use to drown ourselves in our site graphs month to month charting success.

Google Analytics and others of its ilk were sparks that lit the fire. It moved analytics off our systems and small providers and into the cloud. It expanded analytical capabilities. It drove insights into our business and taught us new questions to answer. It gave us insights on how to spend on ads. It became self-serving to the corporation and could remain free. In the beginning, it might have been innocent. Remember, Google’s motto used to be "Don't be evil." It's hard to argue that is still the case.

Recently, several companies have released privacy-focused analytics. These products give us most of the capabilities we need.

Simple Analytics

This software is based on a premise, let’s make analytics simple. And the creator @AdriaanvRossum delivers on exactly that goal.

You type the domain you are going to add, and you’re left with this snipped.

    <script async defer src="https://cdn.simpleanalytics.io/hello.js"></script>
    <noscript><img src="https://api.simpleanalytics.io/hello.gif" alt=""></noscript>

Once inserted into your site, the analytics page automatically updates with data. Pretty slick!

This is the shortest and easiest analytics snipped I have seen. There is no complicated tracking code or additional javascript closures inserted into the page. Just a linked file off of a CDN, and a small .gif for tracking sites when JavaScript is disabled.

There is a really great benefit for not having a unique tracking code. I don’t have to disable tracking in my lower environments and review apps. Because they are not khrome.dev or www.khrome.dev they are simply not counted. Pretty convenient since I host on with zeit.co and make great use of review deployments.

Of all the examples here, Simple Analytics has very high scrutiny in the data they store, to make sure no processes could be considered device fingerprinting. Based out of Europe, they are very cautious to make sure their clients do not need to have any disclaimer based on the tracked metrics. For example, IP addresses are not stored, even in an anonymous hashed form. This an in compliance with PECR in the UK. And all of the data is stored in Iceland, which has one of the highest standards for data protection and encryption. To

I am currently using Simple Analytics on my own site. Based on the research I have done, they seem to be the most compliant, especially in Europe. I have found the experience to be as easy as described. Visit Simple Analytics to sign up. Using this link will give you a 7-day trial, plus one month free!

Fathom Analytics

The brainchild of Jack Ellis and Paul Jarvis, two independent developers. They also wanted to build a privacy-focused analytics solution.

One of the more interesting things about Fathom Analytics is the amount of care and work put into tracking more than just pageviews. Fathom Analytics uses a fairly complex hashing solution with table lookup to estimate the number of unique visitors and unique pageviews. What is critical though, is that they can not determine the individual path of a single user. You can read more about that in a post they wrote about anonymization.

While version 1.0 seemed to have issues with my SPA, version 2.0 promised to fix these problems. I have not tested this since last summer with version 1.0. But I know Paul Jarvis was receptive of the feedback on Twitter and promised to address it in version 2.0.

What is really promising about Fathom Analytics, is the amount of data that is captured. The presentation is not only one of the strongest in version 2.0 of the data. But it includes metrics not found elsewhere, like "Average Time on Site", "Bounce Rate" and "Unique Visits". I am a really big fan of the previous months' comparisons as well. Clicking on "N Current Visitors" also gets you a great breakdown of the pages that are currently being viewed. A pretty nifty trick that makes the whole interface feel a little smoother.

Netlify Analytics

This addition to privacy-focused analytics is very new. Launching just a few weeks ago, it is already making some headlines. You do need to be a Netlify customer and pay $9 a month for the feature though, which does appear to be fairly limited in data.

One of the coolest tricks is that you don’t need to install it. Once you activate it, it's live on your website, using data the CDN captures. Which basically means you don't have any client-side JavaScript that is capturing the data. It is a very neat trick.

Bandwidth Bar Chart

Sources Table

Pageviews Chart

Originally published on Khrome.dev.

Creating Compelling and Useful 404 Pages

Zane Milakovic — Sun, 01 Dec 2019 00:00:00 +0000

A custom 404 page has become a hallmark of well-polished websites. It allows expressing the creative brand of the site. Sometimes it shows a neat trick and easter eggs.

404 Page Examples

Take dev.to 404 pages as an example. It is an incredibly simple page that shows the glitching gif logo of the dev.to brand. It does not offer anything extra, except a link back home.

GitHub takes things a step future with their 404 pages. They use Star Wars as a pop culture reference to relate to the inner geek in me. GitHub goes a step further than most sites by tracking the users' mouse movement to create a parallax effect. I remember that this brought me a moment of joy when I found this page.

Another enjoyable example is from the folks over at Carwow in the UK. They build a mini-game into the 404 page that feels very retro-inspired. So while not the most practical 404 pages, it gave the development team someplace to show off. The brand charm comes through when you lose, where they try to convert you to a test drive.

Suggestions Useful 404 Pages

There is much debate about what makes a useful 404 page. Dev.to does not provide many methods to recover, while GitHub by contract shows the full header and footer of the website and a second search bar.

In general, it's hard to say anything negative about giving help to users landing on a 404 page so they can recover. Bad 404 pages can cause users to leave the site altogether. A useful 404 page conveys to the user you care about helping them find the relevant information. It could also mean saving a customer or creating a new conversion.

Show consistent navigation so users can self recover.
Provide a secondary search to encourage users to find the content they seek.
Make suggestions based on the users' search history, current trending content, or just what you want to feature.
Provide links to any monitoring or status pages in case the 404 page shown was by some other error.
Show your brand and messaging off and delight.

My Blogs 404 Page

For my site, I decided to leave things clean and minimalistic during the launch of my website. I left the header and footer on the page. I then spruced it up with an excellent illustration from unDraw.io that I color matched.

Originally published on Khrome.dev.

Would you build social images with code?

Zane Milakovic — Wed, 31 Jul 2019 02:03:36 +0000

Really simple question. If I build an interface allowing for the sharing and creation of themes for social images, would you use it?

Imaging coding social twitter images, or dev.to banners in HTML and CSS and sharing that theme with others. Then being able to reuse it easily to create other social images.

Interested?

This is inspired by the work I did here khrome.dev of image generator

If people are interested, I will put a signup page up and start building it this weekend.

What features would you need to use this?

Custom Decorators with Storybook & Vue

Zane Milakovic — Thu, 18 Jul 2019 00:00:00 +0000

Storybook has excellent Vue support. While it did not support Vue at launch, it now does. So it has become my goto technology while fleshing out base components. It is critical to my development process, and I think it should be considered for your process as well.

No longer do I need to stub out pages or hack together a test page. Instead, I can focus on my design language. Each story is a base component, making it incredibly clear and more comfortable to process. It has sped up my development in unexpected ways.

The ecosystem within Storybook also covers many of my concerns. I love the "knobs" plugin. It allows me to stress test each component by mixing settings. The a11y plugin gives me a high-level view of the current state of the component to ensure that everything is accessible. To simulate different viewports, I use the breakpoint component. These tools ensure that I think about these concerns much earlier in my process. Also, my work is better for it.

The Problem

I did run into a small issue recently, in any case. How to build for multiple themes at once? One of the patterns I rely on is the use of background colors to modify the pallet in the foreground. I like the concept of breaking up the page. Moreover, as content shifts in my marketing pages, I want the flexibility to change the pallet on the fly. Here is an example of the same signup banner across three different pallets.

So I want to demonstrate with a simple <base-badge> component. This component takes a label in its default slot and shows it in a colored badge. It is excellent for notification counts and tagging content. Here is an example of it in Storybook.

BaseBadge Breakdown

Here is the BaseBadge.vue file.

Note - This uses TypeScript and nuxt-property-decorator of which I am a massive fan.

<template>
  <span class="badge" :class="{ secondary, small, large }">
    <slot></slot>
  </span>
</template>

<script lang="ts">
import { Component, Prop, Vue } from "nuxt-property-decorator";

@Component({})
export default class BaseBadge extends Vue {
  @Prop(Boolean) private secondary!: boolean;
  @Prop(Boolean) private small!: boolean;
  @Prop(Boolean) private large!: boolean;
}
</script>

<style scoped>
.badge {
  display: inline-block;
  text-align: center;
  color: #fff;
  fill: #fff;
  background-color: #ee0028;
  border-radius: 2px;
  padding: 4px 6px;
  text-decoration: none;
  font-size: 16px;
  font-weight: 400;
  line-height: 1.1;
  letter-spacing: 0.025rem;
  text-transform: uppercase;
}

/* Grey Modifications - Badge */
.__bg-grey .badge {
  background-color: #da0629;
  color: #fdfcfb;
  fill: #fdfcfb;
}

/* Dark Modifications - Badge */
.__bg-dark .badge {
  background-color: #f32144;
  color: #010b19;
  fill: #010b19;
}

.secondary {
  background-color: #010b19;
}

/* Grey Modifications - Secondary */
.__bg-grey .secondary {
  background-color: #010b19;
  color: #fdfcfb;
  fill: #fdfcfb;
}

/* Dark Modifications - Secondary */
.__bg-dark .secondary {
  background-color: #ffffff;
  color: #010b19;
  fill: #010b19;
}

.small {
  font-size: 14px;
  padding: 4px 8px;
  border-radius: 16px;
  line-height: 1;
  letter-spacing: 1.25;
}

.large {
  font-size: 20px;
  padding: 6px 12px;
  letter-spacing: 0.1rem;
  line-height: 1;
}
</style>

For those new to Vue and TypeScript, I am going to break this down quickly.

<template>
  <span class="badge" :class="{ secondary, small, large }">
    <slot></slot>
  </span>
</template>

The template section is relatively standard and straightforward Vue. We are creating a span that contains the text passed to the default slot. The interface accepts a size and a color pallet. The default is assumed to be standard size and primary color pallet.

<script lang="ts">
import { Component, Prop, Vue } from "nuxt-property-decorator";

@Component({})
export default class BaseBadge extends Vue {
  @Prop(Boolean) private secondary!: boolean;
  @Prop(Boolean) private small!: boolean;
  @Prop(Boolean) private large!: boolean;
}
</script>

Notice the <script lang=" ts"> where we tell Vue to process this as TypeScript.

The import line is used to pull in our decorators and classes from nuxt-property-decorator which is a nice wrapper around four other modules. This just cleans up the interface instead of having to pull in vue-property-decorator, vue-class-component, vuex-class, and nuxt-class-component separately.

The @Component({}) decorator defines the class as a component. The @Prop(Boolean) defines props for the Vue component. Notice that Boolean/boolean repeated during the prop declaration, this sets up both TypeScript type checking and Vue prop type checking. Notice that we do not have any state or logic to deal with inside the Vue component. I wanted to focus on the CSS instead.

CSS Styling

.secondary {
  background-color: #010b19;
}

/* Grey Modifications - Secondary */
.__bg-grey .secondary {
  background-color: #010b19;
  color: #fdfcfb;
  fill: #fdfcfb;
}

/* Dark Modifications - Secondary */
.__bg-dark .secondary {
  background-color: #ffffff;
  color: #010b19;
  fill: #010b19;
}
</style>

Looking at just a small subset of the CSS, you can see that we are modifying .secondary three times. The default pallet is considered the "Primary" theme and sets the background color. When the component is within an element with the .__bg-grey or .__bg-dark class applied, it gets modified.

The structure I use for different sections within my site is to have a section define the background color. Then the contents within respond to that.

<section class="__bg-dark">
    <base-badge secondary/>
</section>

The goal is to ensure that as the parent section changes the theme, all the children behave accordingly, modifying their color pallets accordingly.

The Storybook Story

The Storybook setup is relatively basic. It uses the standard patterns for using Vue within Storybook, as well as a few "Knobs."

Basic Storybook Story

First, we import storiesOf method from the @storybook/vue module. The method allows us to create a story and define it in a namespace. We also import our BaseBadge.vue component.

Tip - I place all my base component within a folder called "Components." The purpose is to make it clear to others what components can be combined to create more significant sets of components. Base Components typically have minimal to no state and are the lowest level component in Vue.

import { storiesOf } from "@storybook/vue";
import BaseBadge from "../components/BaseBadge.vue";

const stories = storiesOf("Components/Base Badge", module);

Next, we are going to display the BaseBadge on the page. We add the story to Storybook using the stories.add method. I name the page for all root instances of my components "Default" unless I have different implementation setups.

The template is just a simple ES6 template string that exports the same contents you would have in a Vue template.

stories.add(
  "Default",
  () =>
    ({
      components: { BaseBadge },
      },
      template: `
        <base-badge>
          New
        </base-badge>
      `
    } as object)
);

Adding Knobs

We have a basic rendering, but we can't test any of the stress cases. We want to be able to change the text, modify the size and color pallet. First, we want to import the interface types we need from @storybook/addon-knobs.

import { radios, text } from "@storybook/addon-knobs";

Then we want to extend the story definition object to include a props object that tells Storybook what "knobs" to enable and the rules and labels for each knob. In this case, we use text knob to define the content within the badge. The radio knob is used to select the theme and size of the badge.

    {
      components: { BaseBadge },
      props: {
        text: {
          default: text("Text", "NEW")
        },
        theme: {
          default: radios(
            "Theme",
            {
              Primary: "primary",
              Secondary: "secondary"
            },
            "primary"
          )
        },
        size: {
          default: radios(
            "Size",
            {
              Small: "small",
              Normal: "normal",
              Large: "large"
            },
            "normal"
          )
        }
      },
      template: ``,
    }

Lastly, we want to modify the template to use the values from these knobs.

            <base-badge v-bind="{
              secondary: theme === 'secondary',
              small: size === 'small',
              large: size === 'large',
            }">
              {{text}}
            </base-badge>

Here is the whole story completed. While we have not solved for the multiple background colors, we have built the Vue component and the Storybook story for it.

import { storiesOf } from "@storybook/vue";
import { radios, text, boolean } from "@storybook/addon-knobs";
import BaseBadge from "../components/BaseBadge.vue";

const stories = storiesOf("Components/Base Badge", module);

stories.add(
  "Default",
  () =>
    ({
      components: { BaseBadge },
      props: {
        text: {
          default: text("Text", "NEW")
        },
        theme: {
          default: radios(
            "Theme",
            {
              Primary: "primary",
              Secondary: "secondary"
            },
            "primary"
          )
        },
        size: {
          default: radios(
            "Size",
            {
              Small: "small",
              Normal: "normal",
              Large: "large"
            },
            "normal"
          )
        }
      },
      template: `
        <base-badge v-bind="{
          secondary: theme === 'secondary',
          small: size === 'small',
          large: size === 'large',
        }">
          {{text}}
        </base-badge>
      `
    } as object)
);

So far we have built this. The thing I showed you in the beginning.

Building our Decorator

Storybook uses decorators to extend the functionality of a story. These decorators look a little different than the ES7 decorators we see in typescript, but the concept is similar. We want to extend the functionality of the core object and introduce new behavior.

Building a decorator in Storybook is reasonably straightforward. It is just an export of an object from a method. The data method within the object is used to return properties for the template. The template then has access to anything data returns.

In this case, the data method is returning objects of CSS styles. This object follows the rules of using styles in JS for Vue. So box-shadow becomes boxShadow and is the key while the value is a string of the contents for that CSS property.

We then use :style="wrapper" bindings to apply those styles to the HTML elements.

Finally, the <story /> component within the template, tells Storybook where to inject our root story. For every instance of <story />, Storybook makes a copy of the template the decorator is applied too. We want this applied to our <base-badge> template.

const sectionStates = () => ({
  data: () => ({
    wrapper: {
      margin: "0 2rem 2rem",
      border: "thin solid transparent",
      boxShadow: "rgba(0, 0, 0, 0.15) 0rem 0.125rem 0.3125rem 0rem",
      borderRadius: "0.3125rem",
      padding: "2rem"
    },
    light: {
      backgroundColor: "#ffffff"
    },
    grey: {
      backgroundColor: "#fdfcfb",
      boxShadow: "rgba(0, 0, 0, 0.2) 0rem 0.125rem 0.3125rem 0rem"
    },
    dark: {
      backgroundColor: "#010b19",
      boxShadow: "rgba(0, 0, 0, 0.5) 0rem 0.125rem 0.3125rem 0rem"
    },
    heading: {
      fontSize: "0.75rem",
      margin: "0",
      padding: "0.5rem 0 0.5rem 2rem",
      color: "#737373",
      textTransform: "uppercase"
    }
  }),
  template: `
    <div>
      <div :style="heading">On Light Background</div>
      <div class="__bg-light" :style="[wrapper, light]"><story/></div>
      <div :style="heading">On Gray Background</div>
      <div class="__bg-grey" :style="[wrapper, grey]"><story/></div>
      <div :style="heading">On Dark Background</div>
      <div class="__bg-dark" :style="[wrapper, dark]"><story/></div>
    </div>
    `
});

export { sectionStates as default };

The thing that makes this work with multiple backgrounds is the inclusion of the .__bg-light, .__bg-grey, and .__bg-dark CSS classes. These are using in my global styles to augment any children.

Note - I called this sectionStates because the standard Vue component that defines the background color in my project is a section. So it has a few colored states that children components have to react too.

Including our Decorator

The next step is to make use of this decorator in the story we built earlier. First, we want to add the addDecorator method to our imports. This method is used to apply custom decorators to Storybook stories.

import sectionStates from "../utils/sectionStates.ts";
import { storiesOf, addDecorator } from "@storybook/vue";

Finally, we chain the storesOf method and call addDecorator method passing in sectionStates.

const stories = storiesOf("Components/Base Badge", module).addDecorator(
  sectionStates
);

The output is three instances instead of one. Each instance has a different background color. Every child within each instance is respecting its parents' container. The outcome perfectly mimics the behavior of the BaseSection.vue component.

As a bonus, this allows us to validate the accessibility of each change. We see all the possibilities across all backgrounds pallets.

Conclusion

This pattern is beneficial in many situations -

Building multiple themes like this example
Supporting shared components across multiple brands
Working with other types of external modifiers that work by CSS namespacing.

In general, this is very easy to do, provided your comfortable with CSS in JS, and you follow the strict class naming structure.

Originally published on Khrome.dev

HTML Elements with Flex-box Quirks

Zane Milakovic — Tue, 09 Jul 2019 03:37:39 +0000

I have interviewed many frontend developers. One of the methods I have used during the candidate screening process is to give a CSS pair programming exam. The exam allowed my team to have an accurate way to rule out candidates that did not have strong HTML and CSS knowledge. Given that one of the current trends in the industry is to focus on frameworks, I find that knowledge of basic web fundamentals is lacking. Attention to detail is always an issue with young developers as well.

The setup for the interview was simple - the interviewing candidate would start a phone conversation with the interviewer. We would give them a collaborative link to a CodePen. After a few minutes of explanation of what we were expecting, they would start coding.

The task was simple; we asked them to create the styling for a simple login form. We provided the HTML, and they could not modify it. Using a picture of the solution as a guide, they would start.

The Problem

During about ~50 interviews with this method, we kept seeing the same issue. Young developers would rely heavily on flex-box and fail at aligning the content vertically within a fieldset. Even talented developers that nailed all the colors and understood the details struggled.

It turns out that the browsers have some nasty quirks when it comes to flex-box.

The Truth

Flex-box is buggy. Philip Walton has a great readme on his GitHub that breaks out all the intricate quirks with flex-box by the browser vendor. While flex-box came out in 2009, the spec got finalized in 2011. Years later, many of the bugs still exist.

Fieldset

In the exam above, the fieldset element was the biggest surprise challenge. In Chrome and Edge, the display: flex property does not get applied by the browser. This issue has been frustrating developers for years. Years later, both Google and Microsoft have either punted on the bug or flagged it as "by design."

So avoid flex-box on fieldset. Unless you are using Firefox or Safari, turns out they fixed this bug.

Button

The button element does not support the align-items property in Chrome. Safari does not support justify-content. Good news though, you can place the content within div or span.

Summary

Even though Safari fixed fieldset, the summary element can't be a flex container still.

Bonus - CSS Challenge

You can see the solution to the CSS exam below. Want to test your CSS skills? Fork the CodeSandbox and remove the CSS. See if you can reproduce the original without using flexbox.

Originally published on Khrome.dev

Custom 404 Pages on Zeit Now v2 Platform

Zane Milakovic — Fri, 05 Jul 2019 23:54:26 +0000

A custom 404 page has become a hallmark of well-polished websites. It allows expressing the creative brand of the site. Sometimes it shows a neat trick and easter eggs.

404 Page Basics

Take dev.to 404 page as an example. It is an incredibly simple page that shows the glitching gif logo of the dev.to brand. It does not offer anything extra, except a link back home.

Suggestions Useful 404 Pages

In general, it's hard to say anything negative about giving help to users landing on a 404 page so they can recover. Bad 404 pages can cause users to leave the site altogether. A useful 404 page conveys to the user you care in helping them find the relevant information. It could also mean saving a customer or creating a new conversion.

Show consistent navigation so users can self recover.
Provide a secondary search to encourage users to find the content they seek.
Make suggestions based on the users' search history, current trending content, or just what you want to feature.
Provide links to any monitoring or status pages in case the 404 page shown was by some other error.
Show your brand and messaging off some. Delight.

The State of Default 404 Pages on Now

Zeit launched the second version of the Now platform (Now v2) without custom 404 pages. This forces customers to use the built-in default 404 pages. While the design is sharp and works great to fit the Zeit brand, it offers the user no assistance. It is also very opinioned and stands out against most brands. In short, you should replace it.

Replacing the Default 404 Page

The first thing we need is a new 404 page. I used Gridsome, which had me create a 404.vue in the src/pages folder. Now when I build the project, a 404.html file is created in the /dist folder.

Zeit uses a now.json file to customize the build process. Most users need this file so they can specify how the site is built, and customize the routing experience.

The typically static site deployed on Now looks something like this -

{
  "version": 2,
  "builds": [{ "src": "package.json", "use": "@now/static-build" }]
}

Now uses this JSON file to create a static build based on the output of npm run build in your package.json file. If you deployed with just this configuration, you would get the default Now v2 404 pages.

To setup custom 404 pages, we have to add routes.

Adding Routes

{
  "version": 2,
  "builds": [{ "src": "package.json", "use": "@now/static-build" }],
  "routes": [
    { "src": "/(.*)", "dest": "/$1" },
    { "handle": "filesystem" },
    { "src": "/.*", "status": 404, "dest": "/404" }
  ]
}

The first line in the routes array, says that any traffic that enters should look for content within the destination directory. Routing can be a little confusing in Now v2. By default, the /dist folder that gets created after running npm run build with most static site generators, is treated as the root of your output.

The {"handle": "filesystem"} line tells Now to expose the filesystem as available routes. If you had three HTML files - A.html, B.html and C.html in your /dist folder, each of these would be mapped and available automatically.

At this point, going to /404 on your site shows you the custom 404 page, but going to /not-a-real-page does not. We have mapped the file system to make it available, but we have not told our routes to catch anything that has fallen through. So users won't see the show the 404 page when it's needed.

The last line captures anything that was not found by the filesystem and sends the request to the 404.html page correctly. It also sends the correct status of 404 to the users' browser.

Final Results

I decided to leave things clean and minimalistic for the launch of my site. I left the header and footer on the page. I then spruced it up with an excellent illustration from unDraw.io

Let me know what you think in the comments.

Originally published on Khrome.dev