DEV Community: Liam

Abstracting Seasonal Components

Liam — Fri, 08 Aug 2025 17:21:16 +0000

It could be said that one of the core purposes of software engineering is Abstraction. Reducing complexities and making reusable software empowers us to work with higher-level concepts. Why spend time editing 3 files when you can just edit one?

Reusable components are the cornerstone of UI development. It is consistent, faster, and it makes maintenance much easier.

To make something reusable, we need to identify variable and constant elements. Constants stay inside the base component, while variables are exposed as parameters (props) so each instance can customize them.

In my case, I have three Hero sections on a website - Fall, Winter, and Summer - that share the same structure and style but differ in content:

Property	Type in Abstraction	Notes
"Real Farm Fun" Tagline	Variable (currently constant)	Same across all heroes now, but could change in future. Pass as prop to keep flexible.
"Celebrate fall…" Description	Variable (currently constant)	Same now, but keep configurable for special events.
Backdrop image	Variable	Each hero uses a different image.
Call-to-action	Variable	Different sets of buttons and descriptions.
Season info	Variable	Shows “we’re open” or other seasonal info.
Styling & structure	Constant	Shared layout, typography, and positioning are fixed in the base component.

Given this, the prop contract for the reusable hero component includes:

Backdrop Image: Image source (and optional blur placeholder)
Call-to-action:
- An array of buttons
  - Labels, href, and icons
- CTA description
Season Info
- Title
- Content
Tagline & Description: Passed as props to allow flexibility, even if often the same

The base component (AbstractHero) implements the shared structure and styling. Seasonal heroes provide only the variable content.

The Code

Before:

export default function HeroSummer() {
  return (
    <section className={styles.hero}>
      <Image
        src="/summer.webp"
        width={1500}
        height={1000}
        priority
        placeholder="blur"
        blurDataURL="/summer-xs.webp"
        alt="Old McDonald's"
      />
      <div className={styles.cover}>
        <div className={styles.top}>
          <h1 className={styles.tagline}>Real Farm Fun</h1>
          <div>
            <p className={styles.description}>Celebrate fall in Berkeley County, West Virginia with pumpkins, hayrides, and fun for the whole family</p>
          </div>
        </div>
        <div className={styles.bottom}>
          <div className={styles.cta}>
            <p>Available through August 20</p>
            <div className={styles.buttons}>
              <a href="/reservations" onClick={() =>
                track(
                  'Reservations',
                  { location: 'Hero Summer' }
                )
              }>
                <ArrowLeft size={24} weight="bold" />
                Book Your Event
              </a>
              <a href="https://docs.google.com/forms/d/e/1FAIpQLSdNLOwNjhKnsI4QT18MCGOrEvxXP164zfLpXQOZSSBcJQxo3A/viewform?usp=header" target="_blank" onClick={() => {
                track(
                  'Vendor Application',
                  { location: 'Hero Summer' }
                )
              }}>
                Vendor Application
                <ArrowSquareOut size={24} weight="bold" />
              </a>
            </div>
          </div>
          <div className={styles.seasonInfo}>
            <div className={styles.card}>
              <h2>Open Soon</h2>
              <p>We'e still getting ready for the season</p>
            </div>
          </div>
        </div>
      </div>
    </section>
  )
}

This code is one of three seasonal hero components (Fall, Winter, and Summer) that share the same structure but differ in content. The problem is that the variable content (images, text, buttons) is tightly mixed in with the constant structure (layout, styling, markup). If I want to adjust the structure, I have to repeat that change in all three files.

Here’s where the concepts from our earlier Variable vs Constant table come into play: the layout, styling, and placement of elements are constants that should live in a single place, while text, images, and button data are variables that each season can define independently.

After:

Abstract Hero Component

export default function AbstractHero({
  backdrop,
  tagline = "Real Farm Fun",
  description = "Celebrate fall in Berkeley County, West Virginia with pumpkins, hayrides, and fun for the whole family",
  cta,
  seasonInfo
}) {
  return (
    <section className={styles.hero}>
      {backdrop && backdrop.src && typeof backdrop?.src === 'string' &&
        <Image
          src={backdrop.src}
          placeholder={backdrop.blurDataURL ? "blur" : undefined}
          blurDataURL={backdrop.blurDataURL || undefined}
          priority
          alt={backdrop.alt || "Seasonal Hero Backdrop"}
          width={1500}
          height={1500}
        ></Image>
      }
      <div className={styles.cover}>
        <div className={styles.top}>
          <h1 className={styles.tagline}>{tagline}</h1>
          <div>
            <p className={styles.description}>{description}</p>
          </div>
        </div>
        <div className={styles.bottom}>
          {cta &&
            <div className={styles.cta}>
              {cta.description &&
                <p>{cta.description}</p>
              }
              {cta.buttons && Array.isArray(cta.buttons) &&
                <div className={styles.buttons}>
                  {cta.buttons.map((button, index) => {
                    const isExternal = typeof button.href === 'string' && button.href.startsWith('http');
                    return (
                      <Link
                        key={index}
                        href={button.href}
                        onClick={button.onClick}
                        target={
                          isExternal ? '_blank' : undefined
                        }
                      >
                        {button.Icon &&
                          <button.Icon size={24} weight="bold" />
                        }
                        {button.label}
                      </Link>
                    )
                  })}
                </div>
              }
            </div>
          }
          {seasonInfo &&
            <div className={styles.seasonInfo}>
              <div className={styles.card}>
                {seasonInfo.title && <h2>{seasonInfo.title}</h2>}
                {seasonInfo.content && <p>{seasonInfo.content}</p>}
              </div>
            </div>
          }
        </div>
      </div>
    </section>
  )
}

This is the base abstraction. All the constants from the earlier table live here: the layout, structure, styling, and placement. The variables are exposed as props: backdrop, tagline, description, cta, and seasonInfo. This means the seasonal hero components only need to supply the data that changes.

export default function HeroSummer() {
  return (
    <AbstractHero
      backdrop={{
        src: "/summer.webp",
        blurDataURL: "/summer-xs.webp"
      }}
      cta={{
        description: "Available through August 20",
        buttons: [
          {
            href: '/reservations',
            label: 'Book your event',
            onClick: () => {
              track(
                'Reservations',
                { location: 'Hero Summer' }
              )
            },
            Icon: Calendar
          },
          {
            href: 'https://docs.google.com/forms/d/e/1FAIpQLSdNLOwNjhKnsI4QT18MCGOrEvxXP164zfLpXQOZSSBcJQxo3A/viewform?usp=header',
            label: 'Apply to be a vendor',
            onClick: () => {
              track(
                'Vendor Application',
                { location: 'Hero Summer' }
              )
            },
            Icon: ArrowSquareOut
          }
        ]
      }}
      seasonInfo={{
        title: "Open Soon",
        content: "We'e still getting ready for the season"
      }}
    />
  )
}

Now the seasonal component is dramatically smaller and easier to read, containing only the variable data. Any change to the structure, layout, or styling happens in AbstractHero. This is the practical payoff of separating constants from variables in your abstraction.

UI Improvements Pt. 1

Liam — Sat, 26 Jul 2025 22:36:45 +0000

Background

This is my first blog post regarding the King Street Emporium Project, so some context is needed.

For my college capstone project, I designed and developed a cigar catalog for a cigar lounge, The King Street Emporium. The site is still great backend-wise. However, it was my first design project, and it is in dire need of improvement as I've learned a lot since then.

I've already made the following improvements, but I'm only about halfway done.

See the Case Study!

Hero Section

Before	After

Featured Cigars

Before	After

New Arrivals

Before	After

Search By

Before	After

Brand Showcase

Before	After

Title and Pagination

Before	After

Catalog Cards

Before	After

Feature Flags

Liam — Sun, 20 Jul 2025 22:08:07 +0000

When Pumpkin Season is in full swing, we need a way to update the website on the fly without having the dev boot up VS Code on a laptop.

The reasons we might need to update the website are many: a feature could be broken, we might want to notify users of something, or we might want to wait for a certain time to roll out a certain feature.

Being able to switch certain features on and off, manually or conditionally, is something that many business websites have need of. The solution for this is Feature Flags

What are Feature Flags?

Also known as a feature toggle or feature switch, Feature Flags are a technique used by web or application developers that allows developers to enable or disable certain features without manually altering the code.

They are implemented by embedding conditional logic into the code. Before a certain feature would be used, the code asks the flag manager "Is this feature enabled right now?" before it runs the code for that feature.

What use do we have for Feature Flags?

Use Case	Reason
Seasonal Hero Sections	Since there are different Hero sections for different seasons, Feature Flags can enable the website to automatically switch them out based on time conditions.
Vendors & Vendor Promotions	The vendor menus won't be ready until close to the season start. We can work on developing them, and even deploy them, but they can be hidden to the user until we manually switch on this feature flag.
Night Maze Advertisement	When it gets close to night maze season, we can have a banner appear at the top of the home page that links to `/activities/night-maze`, making it the most optimally visible event. This is sure to increase visitors for the Night Maze
Opening Weekend Countdown	We can show a countdown to the opening day on the home page, but once it's done, it should be hidden. Obviously on opening day we won't have time to deploy a removal. Feature flags can do this automatically
Weather Advisory	In the case that there is rain or flooding and we have to close, we can enable a Weather Advisory banner on the home page, which shows the weather forecast for specified dates
Maze Game	Even though the Maze Game is unlikely to break, it's still a higher-risk feature than most on the website. In the case that there are issues with it, we can quickly shut it off with feature flags until we have time to fix it.
Contact Form	Just like the Maze Game, if there are issues with the Contact Form, we need to make sure people aren't still using it while we work on a fix. This enables us to hide it on the fly.
Facebook Feed	If the Facebook Feed `iframe` stops working, we can hide it with feature flags and only have a link to our Facebook page

Implementing Feature Flags

At first, I wanted to use Statsig's feature flags, since they can be directly integrated with Vercel. However, their Free plan only allows 10k events per month. This won't stand against the influx of visitors in September, and we won't have time to fix it by then. The paid plan includes 5M events per month, however it is extremely pricy at $120/mo.

So, my solution is to make our own robust feature flags system inside the website.

This solution involves defining flags in a flexible format, and evaluating them when they are called upon.

Definition

Our feature flags will be stored in JSON format in /public/flags/featureFlags.json.

Each flag will include:

A default value: this is the Boolean value which will be passed if the conditions are not evaluated as True. If there are no conditions, the flag will simply be evaluated as the default.
An operator: usually AND or OR, this tells the evaluator how to evaluate multiple conditions. AND requires all conditions to be true, and OR requires only one condition to be true.
An array of conditions: Each condition is an object which contains a criteria like time, and a value. Depending on the criteria, other attributes may be required.

Some flags may include:

An array of arguments: Although kind of hacky, this is a content-management feature within the feature flags system. If certain features require additional static information, they can be included here. Each argument will have a key, a type, and a value.

Based on these requirements, here's what our JSON format will look like:

{
  "use_fall_hero": {
    "default": false,
    "operator": "AND",
    "conditions": [
      {
        "criteria": "time",
        "operator": "after",
        "value": "2025-09-22T13:49:00-05:00"
      },
      {
        "criteria": "time",
        "operator": "before",
        "value": "2025-11-02T18:00:00-05:00"
      }
    ]
  },
  "show_vendors": {
    "default": false,
    "conditions": []
  },
  "show_flood_banner": {
    "default": false,
    "conditions": [],
    "args": [
      {
        "key": "dates",
        "type": "dates",
        "values": [
          "2025-07-18",
          "2025-07-19",
          "2025-07-20"
        ]
      }
    ]
  }
}

Evaluation

In order to evaluate whether a certain feature flag is enabled, we will create a public function that checks each condition based on provided context.

`isFeatureEnabled`

We'll start off defining isFeatureEnabled with key and context parameters. key is the name of the flag in the JSON file (like show_vendors) and context is an object containing information that will be needed to evaluate the conditions (like the current time)

Then the function will use that key to obtain the feature flag from featureFlags.json

// /public/lib/featureEvaluator

export function isFeatureEnabled(key, context = {}) {
    const flag = featureFlags[key] // <- imported from featureFlags.json
    if (!flag) {
        console.warn(`Feature flag not found: ${key}`);
        return false;
    }
    // ... //
}

Then, we'll extract our defaultValue, operator, and conditions with fallback defaults:

const { default: defaultValue = false, operator = 'AND', conditions = [] } = flag;

If there are no conditions, we can skip evaluation logic and return the default value:

if (!conditions.length || conditions.length === 0) return defaultValue;

After that, we'll use map to go through each condition and evaluate it with evaluateCondition, which will be defined in the next section. For now, this function takes a condition object and a context object, and either returns true or false.

The map function creates an array of Boolean values as our results.

const results = conditions.map((condition) => evaluateCondition(condition, context));

After they have all been evaluated, we will check which operator this flag uses, and return a Boolean value according to the correct operation:

if (operator === 'AND') return results.every(Boolean);
if (operator === 'OR') return results.some(Boolean);

`evaluateCondition`

This function evaluates a single condition based on provided context:

function evaluateCondition(condition, context) {
  // ... //
}

Within evaluateCondition, a switch-case block is used to separate the logic for different criteria:

switch(condition.criteria) {
    case 'time': {
      const target = new Date(condition.value);
      if (condition.operator === 'before') return now < target;
      if (condition.operator === 'after') return now > target;
      break;
    }

    case 'env': {
      if (condition.operator === 'equals') return context.env === condition.value;
      if (condition.operator === 'in') return Array.isArray(condition.value) && condition.value.includes(context.env);
      break;
    }
    // ... //
}

Finally, if the criteria doesn't match any cases, false is returned. Additionally, the break statements in the previous snippet cause the program to exit the switch block and return false:

switch (condition.criteria) {
    // ... //

    default:
        console.warn(`Unknown criteria: ${condition.criteria}`);
        return false;
}

return false;

Web emails with SendGrid

Liam — Sun, 20 Jul 2025 20:23:29 +0000

Although Old McDonald's site is intended to be mostly an informational website, there are two big requirements that depend on user submission: Contact Forms and Raffle Entries

While we could use a full Customer Relationship Management (CRM) system, this would be unnecessarily complex and costly for our needs. Instead, the simplest and most cost-effective solution to facilitate user communication is good old email.

Sendgrid is a well-known cloud-based email delivery platform that will allow us to send emails from our website without the need for our own email server.

Why Sendgrid?

Feature	Why this matters	Cost
100 emails per day	It's unlikely that we'll get over 100 submissions each day between the contact form and maze game raffle entries.	$0
Delivery Optimization	This ensures that our emails don't end up in the spam folder	$0
Reliable API	We won't have to worry about outages	$0

Total cost
Free

Sender Identity

In order to use Sendgrid, we first have to create a Sender Identity. Put simply, this is the email address that our emails will appear to be sent from.

We have the option of using Domain Verification which allows us to use our domain as the email address without actually setting up an email hosting provider. For example, we can make our emails look like this:

Contact Form Submission
From:	Old McDonald's Pumpkin Patch (no-reply@oldmcdonaldspumpkinpatchwv.com)
To:	Me (me@example.com)
Name: John Doe Email: johndoe@example.com Hi, I'm submitting this contact form to let you know that bla bla bla bla

Implementation

First, we'll create an API route in our Next.js site at /api/email

Sendgrid offers a very handy npm package which we will be using instead of directly sending requests to their API. So first, we'll import sendgrid, and give it our API key from the environment:

import sendgrid from "@sendgrid/mail";

sendgrid.setApiKey(process.env.SENDGRID_API_KEY);

Since this Next.js site uses the App Router, we can define handlers as exports using HTTP method functions, like so:

/**
 * POST handler: Send an email.
 */
export async function POST(req) {
  // ... //
}

Then, inside this handler, we will extract the body from the API request, and ensure that it contains all of the necessary fields:

const body = await req.json();
const { to, subject, text, html } = body

if (!to || !subject || !text || !html)  {
    return NextResponse.json(
        { error: "Missing required fields" },
        { status: 400 }
    );
}

After we've made sure we have everything we need for the email, we'll kick off sendgrid.send() in a try block.

This is where we can set the custom sender identity for this email as described in the previous section

try {
    await sendgrid.send({
        to,
        from: { 
            email: "no-reply@oldmcdonaldspumpkinpatchwv.com",
            name: "Old McDonald's Pumpkin Patch"
        },
        subject,
        text,
        html,
    });

    return NextResponse.json({ success: true });
} // ... //

Finally, we'll add a catch block to properly log and pass errors to the response

try {
    // ... //
} catch (error) {
    console.error("Sendgrid error:", error);
    return NextResponse.json(
        { error: "Failed to send email: " + error },
        { status: 500 }
    );
}

Usage

Now, the endpoint POST /api/email can be used to send emails, like so:

// /components/contactForm.js

const response = await fetch ('/api/email', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
    },
    body: JSON.stringify({
        to: ['oldmcdonaldsglencoefarm@gmail.com', /* other emails ... */ ],
        subject: 'Contact Form Submission',
        text: `Name: ${formData.name}\nEmail: ${formData.email}\n\n${formData.message}`,
        html: `<p>Name: ${formData.name}</p><p>Email: ${formData.email}</p><p>${formData.message}</p>`,
    })
});

// ... //

Maze Game - finally on the web

Liam — Mon, 26 May 2025 23:17:35 +0000

Developer Summary

The Maze Game is a client-side experience driven by QR code scanning, localStorage, and conditional UI flows. Here's a breakdown of its key components and logic:

1. QR Code Entry (`/maze-game/[code]`)

Users scan a QR code that opens a route with a unique code param.
On page load:
- The [code] is added to localStorage.foundCodes if it’s not already present.
- Displays a confirmation (e.g., name and image).
- After a short delay, user is redirected to /maze-game.

2. Game Dashboard (`/maze-game`)

On load:
- Retrieves foundCodes and submissions from localStorage.
- Fetches the current season’s valid codes from the server.
Compares:
- Filters local codes to include only those valid for the current season.
- If all season codes are found:
- Checks if the current year is in localStorage.submissions.
- If not, displays the submission form.

3. Submission Flow

On form submission:
- Sends user details via an email API.
- Records the current year in localStorage.submissions to prevent repeat entries.

4. Storage Format

// localStorage.foundCodes = ["alpha", "bravo", "charlie"]
// localStorage.submissions = ["2024"]

5. Persistence Notes

localStorage is used for persistence across page reloads and sessions.
There is no backend account system; uniqueness is enforced by year-based checks.

Consideration of body-image component styling upgrade

Liam — Mon, 26 May 2025 22:53:06 +0000

I've done a little work making the AndImage component look a little better, but I'd like some feedback, since it does take up a bit more space.

Before:

After:

Interactive Map

Liam — Fri, 23 May 2025 22:58:49 +0000

Lots of features have been added since the last blog post. The addition of an interactive map is the biggest game-changer.

The map is based on the Leaflet module, which is entirely open-source and free. It can pull imagery from any source, so I chose OpenStreetMap, since it is also free.

Geo Features

In order to give visitors a true-to-scale overview of the farm's layout, I overlayed markers, zones, and paths on the map based on real coordinates.

Icons

Most icons are stored on the server as SVGs, and then processed through a custom "icon factory" when they are needed. This makes it easy to add new icons, and reuse existing ones.

Popups

The map has been made interactive by allowing certain elements to be clicked on, which will reveal a 'popup' with more content.

Geolocation

Utilizing the JS navigator.geolocation API, I implemented a simple geolocation feature that refreshes every 8 seconds. Users can click the GPS button to center the map on their location.

Zoom Visibility Control and Limits

In order to reduce crowding and maintain the aesthetic appeal of the map, some icons and tooltips will disappear when zoomed out to certain levels.

Additionally, zooming has been limited to level 16, and capped at level 19, since that is the maximum level OpenStreetMap will provide tiles for.

Fly Links

This feature fully incorporates the map with the rest of the website. I've made a lightweight system that allows linking to specific coordinates via the URL query.

This will enable visitors to be pointed directly to the location they're looking for without pouring over the map.

New Heroes

Liam — Sat, 17 May 2025 00:19:21 +0000

I wasn't satisfied with the previous hero section designs, so I went ahead and redesigned them to look a bit more modern

Summer/Spring Hero

Fall Hero

Winter Hero

Hero Sections: A small visual study

Liam — Fri, 16 May 2025 20:01:15 +0000

A 'Hero' is a large banner at the top of a website's home page. As it is the first thing a visitor sees when they enter a website, it's the one chance to make a first impression.

What makes a good Hero section

A central graphic

This can be an image or a video. For our purposes, we'll only need an image.

This image should be high-quality and meaningful. A purely decorative image won't do. It should convey the proposition of a fall festival in some capacity.

The image shouldn't be too busy either. Negative space is necessary, as the purpose of the central graphic is to complement the other components of the section, not override them.

Text

The text block is where you capture interest. It consists of one or both of two parts:

Tagline

The headline delivers the core message in just a few words. Luckily, we already have a very fitting tagline: "Real Farm Fun". This should be displayed in a large, strong, legible font.

Description

This text supports the tagline, or provides additional information. It should be concise, but can be longer than the tagline.

Additionally, it should be amply spaced away from other components, so that it doesn't clutter them, and draws attention to itself

Call-To-Action (CTA)

This is the single most important part of the section. It is the subject of the section's inspiration, and the driver for interaction with the website.

Typically, the CTA is shown as a button, or a link. It should be visually prominent, standing out so the viewer cannot miss it. Just like every other component, it should have ample breathing room to draw attention and reduce clutter.

Finally, if there is more than one CTA, they should be distinct from each other, with a dominant action and others being secondary

Let's take a look at other great Hero sections

Text over images: Here, white text is placed directly over an image. No blurring, no text backgrounds. Despite being overlaid on a sky, the text remains easily readable because the sky is sufficiently dark, providing just enough contrast.

What we can learn from this?
When using a graphic as a backdrop, always compare its most extreme colors with the website's theme colors to ensure sufficient contrast and readability

Unlike the previous example, the graphic here has way too much contrast to be used as a backdrop, as is the case for most product graphics.

So instead, this hero clearly separates the text from the graphics by placing them on either side. However, it cleverly corrects the visual balance by adding another graphic, and another text (user stats), but with the sides swapped. With that, text and graphics are evenly distributed over the screen.

What can we learn from this?
By thoughtfully distributing both text and graphics, you can prevent visual imbalances. This can be done by adding additional supporting text, and secondary graphics

Season Progress Bar

Liam — Fri, 16 May 2025 07:33:27 +0000

I had an idea, and I brought it forth

A progress bar which shows an overview of the whole year, the current date, and "Pumpkin Season" highlighted.

This should give visitors a visual aid for when the business is open

Seasonal Heroes: Initial Looks

Liam — Fri, 16 May 2025 03:59:58 +0000

As mentioned in the previous Blog, I will be utilizing feature flags to change the home page's Hero section depending on the season.

Here's a look at their current designs:

Spring/Summer Hero

Fall Hero

Winter Hero

Alpha Prototype Complete!

Liam — Fri, 16 May 2025 01:31:43 +0000

The first phase of the project, a high-fidelity interactive prototype, is finally complete! This iteration is a sort of detailed rough draft showcasing the design and functionality of the website, mostly using placeholder content.
This version enables the stakeholders to explore a tidy, functional product and give me feedback on what should be adjusted or added next.

Gallery

The final straw for this iteration was the addition of the Gallery page.
I've implemented a simple, maintainable gallery solution: the gallery automatically displays any images added to the public/gallery/ directory. This means images can be uploaded directly into this folder, and they'll automatically appear with the next site build.

To achieve this functionality, the /gallery route is rendered dynamically on the server:

export const dynamic = 'force-dynamic';

Rendering the page server-side allows the use of Node's built-in fs module to directly access files on the server:

const galleryDir = path.join(process.cwd(), 'public', 'gallery');

let allFiles;

try {
    allFiles = await fs.readdir(galleryDir);
} catch (e) {
    console.error('Could not read gallery directory:', e)
    allFiles = [];
}

// Filter to only image files (jpg, png, gif, etc.)
const images = allFiles.filter((file) =>
    /\.(jpe?g|png|gif|webp|avif)$/i.test(file)
)

What's next?

I'll be utilizing Statsig to implement feature flags which will allow us to hide and show seasonal Hero sections without interacting with code.

Currently the Hero section says:

Open soon
Real Farm Fun
Available Through August 20:
Book Your Event | Vendor Application

Clearly, this Hero is only really valid until fall, when it'll have to be changed to say something like "Open Now" and link to the Visit page.
By using feature flags, I can make and test predefined content for the Hero section, but have them hidden until they are enabled in Vercel.

This feature is being tracked as Issue #2

Feature flags for hero #2

macglencoe posted on May 15, 2025

Using Statsig, we can turn on or off certain features of the website. This will make it easy to hide and show predefined content, depending on the season, with no coding involved.

Spring/Summer Hero

This is the currently defined hero. It should say something like "Open Soon", and provide links to booking options and a vendor application

Fall Hero

This one should say something like "Open Now" and "Come visit us", and link to Activities, and the Visit page

Winter Hero

This one should say "See you next year" and specify that we'll be opening in September. Link to Gallery, and to the Facebook page saying "follow us for updates"

View on GitHub

DEV Community: Liam

Abstracting Seasonal Components

The Code

Before:

After:

UI Improvements Pt. 1

Background

Hero Section

Featured Cigars

New Arrivals

Search By

Brand Showcase

Title and Pagination

Catalog Cards

Feature Flags

What are Feature Flags?

What use do we have for Feature Flags?

Implementing Feature Flags

Definition

Evaluation

isFeatureEnabled

evaluateCondition

Web emails with SendGrid

Why Sendgrid?

Sender Identity

Implementation

Usage

Maze Game - finally on the web

Developer Summary

1. QR Code Entry (/maze-game/[code])

2. Game Dashboard (/maze-game)

3. Submission Flow

4. Storage Format

5. Persistence Notes

Consideration of body-image component styling upgrade

Interactive Map

Geo Features

Icons

Popups

Geolocation

Zoom Visibility Control and Limits

Fly Links

New Heroes

Summer/Spring Hero

Fall Hero

Winter Hero

Hero Sections: A small visual study

What makes a good Hero section

A central graphic

Text

Tagline

Description

Call-To-Action (CTA)

Let's take a look at other great Hero sections

Season Progress Bar

Seasonal Heroes: Initial Looks

Spring/Summer Hero

Fall Hero

Winter Hero

Alpha Prototype Complete!

Gallery

What's next?

Feature flags for hero #2

Spring/Summer Hero

Fall Hero

Winter Hero

`isFeatureEnabled`

`evaluateCondition`

1. QR Code Entry (`/maze-game/[code]`)

2. Game Dashboard (`/maze-game`)