DEV Community: Maya Shavin 🌷☕️🏡

How To Create An Artistic And Personal Intro Video With ChatGPT And Nano Banana

Maya Shavin 🌷☕️🏡 — Thu, 11 Jun 2026 09:27:00 +0000

In this post, we will walkthrough the workflow, prompts and strategies needed to create a personalized AI intro video. We will also compare different execution approaches, and explore why a sketch-first workflow can lead to significantly better results compared to a standard, one-shot text-to-video generation.

TL;DR

The stack:

ChatGPT/Gemini Pro: For my personal identity sketch, storyboard and video sequence script.
Nano Banana: Core video generation model.

Total time: 1-2 hours

Key Takeaways:

Creating a visual reference first yields a significantly better result than relying solely on text prompts.
Always add your photo, otherwise AI tends to hallucinate your likeness.
Audio is not there yet. It's still more efficient to add music and voiceover manually during post-production.

The Challenge

I have always wanted to a short intro video that feels personal, reflects my work and artistic side, while looking professional enough to reuse across different content channels, whether for my podcast, conference talks, or YouTube videos.

While I have a background in illustration, creating a 10-second animated intro is a entirely different skill set. Storyboarding, animating transitions, and video editing are a whole different world. So, the idea stayed on my wishlist, until AI came.

But does this mean I can simply ask an AI to create an intro video and magically get exactly what I want in a single click, like many LinkedIn posts claim?

Not really. From beautiful demo videos to something that feels personal and represents you, it is a massive challenge.

Initial Approach: Why One-Shot Prompting Failed

My first instinct was to take the most obvious way possible:

Write a descriptive prompt outlining the video I wanted, with the help of LLMs.
Feed it to Nano Banana together with my profile photo.
Get the video and review it.

Straightforward, right?

Technically, the result was impressive. The animation were smooth and the rendering looked polished. The generated character was somewhat similar to my photo.

Except it didn't feel like me. The character looked like a random person rather than Maya. There was little personality, too many visual elements competing for attention, and no clear focus on what I wanted to convey.

At first, I assumed I needed a few more iterations to fine-tune the prompt. However, iteration is not free. Video generation has a daily limits, and I realized I couldn't afford this costly and time-consuming process of trial and error.

The primary issue, I started to suspect, wasn't about Nano Banana itself. It was more about the lack of context and visual reference for the model to understand the story I wanted to tell.

That's when I decided to try things differently.

Step 1: Create A Visual Version Of Yourself First

My number one rule of thumb:

If you want to explain something, sketch it out.

Instead of jumping directly to video generation, I broke the process into smaller steps, starting with a static visual sketch as the primary reference for the rest of the generation workflow.

Since I use ChatGPT frequently, it already has a sufficient understanding of my public profile, work, and interests. Rather than describing all of that from scratch, I focused my prompt on the following three key aspects:

Goal: What should the image achieve? > Create a visual sketch that introduces me to the audience.
Styles: How should the image look like? What artistic style should it follow? > Speed paint/watercolor annotations, color sketching, sketch on white paper, technical doodles.
Rules: What constraints should the image follow? > Number of points, composition between elements, how to integrate different elements in the generated layout.

With those requirements, I came up with the following prompt:

Based on what you know publicly about me and my attached profile image, generate an image as a visual layout to introduce about me to the audience.
Styles: 
* Speed paint/ watercolor annotations
* Color sketching
* Sketch on white paper
* Technical doodles 
Rules: 
* Short, concise, memorable, maximum 4 concise bullet points
* Preserve my actual likeness
* Convert the photo into hand-drawn sketch/speed paint watercolor style, integrated proportionally balanced into the artwork.
* Proper conference slide composition

The result wasn't perfect, but it was surprisingly good. While the generated image contains too much texts, inconsistent bullet icons, and a bigger head-shot than expected, the model captured the right aesthetic elements and theme very well. It accurately reflected my core focus areas, and the overall design style felt pretty close to what I had in mind.

Note: Having an maintained a public presence likely helped ChatGPT to infer the right details such as my website color palette and key themes. If you don't have a public profile, you can simple replace the line:

What you know publicly about me

with a list of your background details or exact content.

After a few iterations, I refined the sketch to a version I'm happy with. I finally had a visual anchor and a reference as the foundation for the next step in my workflow. I was no longer generating a random video, but a recognizable personal storyboard.

Step 2: Turning the Sketch Into a Story

Creating a video is very different from creating a static image. Even within a short 10-second intro, you still need to think about the motion, transitions, and the elements sequence. In many ways, the process is close to planning a movie storyboard.

I already have a visual representation of myself from step 1. The next step was figuring out how the sketch would come to life. For that, I asked ChatGPT to build out an intro sequence based on the sketch, using a below prompt:

Generate a 10-second intro sequence script with hand-drawn sketch elements appearing progressively. The output should be optimized for Nano Banana video generation.

Grounding the Storyboard Prompt

Before sending the generated storyboard to Nano Banana, I added a few more grounding rules to it, such as:

Who is this intro for (@me)
The sketch should be used as a style reference / storyboard
The final animation should preserve the existing illustration style.

Important tip: Nano Banana includes safeguards around generating content of real individuals. Explicitly referencing yourself using terms like @me, my sketch, or my profile in the prompt ensures the content is based on your own uploaded image and helps the model stay aligned with your intent.

Here is the shortened version of the final storyboard prompt I used:

Timeline:
0:00 – 0:01
Blank textured paper.
“Hi!” is written by hand in black ink.

0:01 – 0:02
The text writes itself naturally:
“I’m Maya Shavin”
Sparkles and doodles animate around the name.

0:02 – 0:04
A watercolor splash appears center-left.
A portrait of Maya is gradually sketched from pencil lines into a fully colored illustration
Hair, face, clothing, and shading appear step-by-step.

0:05 – 0:06.5
Three watercolor badges and the associated text appear one after another.
Each line appears with realistic pen-writing animation.

0:06.5 – 0:08
Technology and podcast-related doodles appear.

0:09 – 0:10
Camera slowly zooms out.
The paper airplane flies across the bottom of the page leaving a dotted sketch trail.
Hold on the complete illustration for the final second.

End frame:
A finished hand-drawn portrait of Maya Shavin surrounded by technology, accessibility, AI, speaking, podcasting, and community-building illustrations.

Bringing It To Life with Nano Banana

At this point, the workflow was finally complete. Instead of asking Nano Banana to generate a video from a single prompt, I fed it with three inputs:

The storyboard/script describing the sequence of animations and elements.
The visual reference sketch created in the first step.
My original profile photo as the source of truth for my appearance.

As it turns out, the profile photo was crucial. While Nano Banana could interpret the illustrative sketch style, it struggled to extract my face accurately from the illustration alone. Without the real photo, the model sometimes hallucinated, drifting from one version of Maya to another. Providing both the sketch and the photo helped increase the consistency for the visual identity.

But even then, the process wasn't entirely smooth. There were moments where the model rejected the generation because it interpreted the prompt as creating content about other people. Other times, the transition between frames felt awkward, or the generated character looked noticeably different from me. And working against the daily video generation quota added pressure to get it right within fewer iterations.

Fortunately, thanks to the groundwork laid in the previous steps with the sketch and the storyboard, I didn't need many iterations before reaching the version I was happy with.

The model followed a visual and narrative plan that I had defined, and that's my biggest takeaway from this experiment: the quality of your final video is set long before you ever hit **Enter* on the video generation chat session*.

What I Observed

This experiment gave me plenty of "whoopsies" and "aha" moments, such as:

Multi-Step Workflows Beats One-Shot Generation

By breaking the process into smaller steps (sketch → storyboard → video), the AI model was able to produce higher quality outputs than trying to generate the video directly from a single prompt. Additionally, this multi-step workflow approach forced me to think more clearly about the overall story I wanted to tell, while giving the model more context to work with in every stage. It’s a win-win, where I spend less time on regenerating the video, and more time on refining the parts that mattered.

Visual Reference Matters More Than Instructions

I was really surprised by how much a strong visual reference could improve the results. Just like how we often use sketches to communicate ideas to engineers or designers, AI models seem to respond significantly better when having something visual to anchor on.

"A picture is worth a thousand words" seems to apply here as well. It does require more tokens, but it was worth the investment.

Consistency Is Still A Challenge

Multi-modal AI models have gotten better in maintaining consistency, but there is a long way to go. Many times I found myself adding the same instruction repetitively:

DO NOT CHANGE anything

Without this rule, the model tend to occasionally change something already correct, like icons, my face, or the text unexpectedly in each iteration. Moreover, I noticed how the quality can degrade over time, such as broken texts, low resolution, especially towards the end of the day, or after a long session.

Different Account Types Can Produce Different Results

One unexpected observation was how the outputs can be noticeably different between my Pro Personal account and Enterprise account, despite using the same model and input. The Enterprise account often produced a more polished and accurate video, while the Personal account usually leaned into more playful and visually engaging animation.

Since this is a small experiment, I wouldn't jump to any conclusion from it. Still, it was interesting to observe the differences, and wonder what factors could contribute to it.

Unexpected Accuracy

It's surprising how accurately ChatGPT could capture the theme in my work, from engineering to speaking, mentoring, and building. The sketch felt less like a generic AI image, and more like a visual summary of my personal brand. And seeing that sketch come to life in the final animation was no doubt my sweetest moment.

What I Learnt About Creating Videos With AI

I’m not a professional video creator, nor a prompt expert. That said, these below lessons are more of a personal experience than a standard AI practice:

AI Is Not Your Mind Reader

The biggest mistake I made was expecting AI to magically interpret my intention and get everything right in the first try. Instead, I found it much more effective to treat AI as my collaborator, and iterate with it the same way I would with a human designer or editor. The more information I provided, the better the model could align with what I wanted to achieve.

Start With A Visual Representation

Nano Banana is a powerful tool, but the final video was only as good as the inputs I provided. By investing time into the sketch, I leveled up the input for the storyboard phase, which in turn reduced ambiguity for the final video rendering phase. It's a chain reaction, where each stage builds upon the success of the one before.

Moving forward, I would never skip this initial step of creating the static visual sketch. It acts as the foundation for the entire workflow, serving as shared reference for both the storyboard and the video generation process. Without it, the final outcome would likely rely on random generation luck, and that's not a good thing.

On Build With Maya, I share lessons from software engineering, AI, content creation, and the systems behind building things that scale.
If you enjoyed this breakdown, you might enjoy the podcast too.

Final Thoughts

It's amazing to discover how much a well-structured workflow shaped the final output. Tools like ChatGPT, Gemini, or Grok help generate the assets, but the workflow determines what level of the final product can reach.

That said, my final note for those who are interested in trying AI video generation: start with your story first (both visually and narratively). It might make all the difference.

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 If you'd like to catch up with me sometimes, follow me on X | LinkedIn.

Like this post or find it helpful? Share it 👇🏼 😉

What would I do without AI?

Maya Shavin 🌷☕️🏡 — Tue, 27 Jan 2026 07:39:07 +0000

That’s probably the most common sentence my colleagues and I say at work these days.

AI didn’t arrive with a big announcement. It slowly crept into my daily engineering workflow—first as a coding assistant, then as a search tool, and eventually as something much closer to a thinking partner. Not a replacement. Not magic. And definitely not something I trust blindly.

I’m a lead engineer working in large, complex systems, where context, history, and tradeoffs matter just as much as writing code. In that environment, AI turned out to be most valuable not when it does the work for me, but when it helps me move faster through noise—finding information, understanding unfamiliar code, and turning rough ideas into something concrete.

This post isn’t about hype, fear, or “AI will replace engineers.” It’s a practical look at how I actually use AI today: where it saves me hours, where it still gets things wrong, and why I see it less as a threat and more as a rescuer.

AI as Your Trusted Slackbot

I love Slack. Not because I work for Salesforce. I used Slack long before that. I’ve worked with Teams back in my Microsoft days, but Slack is on another level.

And with recent Slackbot updates, Slack is no longer "communication" app. It’s a real assistant.

Slackbot now searches across Slack, Confluence, Google Drive, Canvas, GUS (Salesforce’s Jira-wannabe), and more. It doesn’t just return links — it consolidates information and generates a structured answer based on what I ask.

One recent example: my self-performance evaluation.

I do keep a document where I track contributions and progress, but let’s be honest, no one captures everything. But what got captured, automaticall and silently, was my Slack activity: discussions, design reviews, investigations, decisions.

So I asked Slackbot to summarize my contributions.

And boom! Out came a detailed list of work, grouped by features and discussions, with a clear impact summary, references, and footnotes. My job after that was pretty straightforward: merge it with my own notes and pass it through another LLM agent to polish it according to the evaluation template.

Is it perfect? No.

It once pulled demo slides from a “Maya” who was… not me (turned out it was a made-up Maya as a demo case 😄). It still requires my review to avoid hallucinations or incorrect context.

But saving hours of digging through old docs and Slack threads? That alone is a huge win.

Code Analyzer & Assistant

Of course, we can’t talk about AI without talking about code.

We’ve moved far beyond copilot that writes a function. With tools like Cursor, Claude Code and MCP-based agents, AI now helps me understand large codebases.

Not vibe coding.

Not replacing engineers.

But acting as a powerful assistant.

I can ask questions like:

“Who calls this function?”

“Map the flow from this UI component to the backend.”

“Which part of the code triggers this LLM orchestration?”

Within minutes, it maps relationships across modules in a massive monolith codebase and explains them in plain language—saving hours (or days) of digging through unfamiliar code. This is especially helpful when working in languages or systems that aren’t your home turf (hello, Java).

I felt this most during a recent hackathon. Within 24 hours, our team reused existing internal UI and server features from multiple teams, layered our logic on top, and aimed to get as close to production-ready as possible. We also used AI as part of the product itself, helping customers reduce onboarding time from months to hours.

The result?

New technical knowledge unlocked, a working demo with real data, and a hackathon award.

Professional Content Editor for Professional Discussions

One underrated use of AI: leveling up professional communication.

Writing technical design docs, business justifications, RCA reports, or even a Slack announcement used to be hard, especially as non-native English speakers. Engineers aren’t trained writers or marketers, and it shows.

With tools like ChatGPT or Gemini, I can now brainstorm ideas, structure my thoughts, draft proposals, get them refined, polished, and critiqued.

The key is asking for criticism. If you don’t, AI will happily agree with everything you write.

This isn’t limited to design docs. It’s just as useful for documentation, RCAs, or any message that goes beyond your immediate team.

And yes, Slack announcements too. Feed it your intent, and it’ll give you a version that sounds like you, just clearer and without grammar issues.

I even built an RCA agent that generates detailed bug reports from investigations, Slack threads, and standard templates, ready for review and publishing. It also won a hackathon.

Pair Programmer That Turns Ideas Into Tools

One of the biggest shifts for me is how AI helps turn ideas into production tools.

Call it vibe coding if you want. But I use it to draft internal tools that boost productivity: setting up dev environments, provisioning mobile simulators, automating workflows with Python and Bash. Those things that used to take weeks of trial and error, now take a day or less, with fast feedback loops. From there, I refine and improve the solution myself.

Since leaning into this, I’ve released several small tools that help my team move faster and make impact sooner. And it doesn't stop there.

A Virtual Slack On-Call Engineer

Working across large systems and multiple projects usually means monitoring countless Slack channels—supporting product managers, solution architects, customer support, and other engineers. Many questions are repetitive or already answered in documentation or past discussions, but it’s often faster for people to tag the on-call engineer than to search for them. For us as engineers, constantly switching contexts across channels is expensive and inefficient.

By integrating AI agents into Slack, I can set up a virtual on-call engineer that monitors specific channels, is grounded in documentation, known issues, and discussion history, and continuously indexes new information. It answers common questions automatically and escalates only complex cases, reducing interruptions while still ensuring timely, accurate responses.

With this Engineer Agent, my team and I can focus on high-impact work without being bogged down by repetitive queries.

Summary

Will AI replace my job one day?

Maybe. Just like my role could be replaced by a younger engineer or by the industry evolving. No one is irreplaceable, especially at work. Even spaghetti code won’t save you forever.

But should I worry? I don't know. What I do know is this: AI helps me onboard faster, cut through noise, and focus on what actually matters—building better products. When AI is wrong, it’s on me to notice. When it suggests a shortcut, it’s on me to decide if it’s the right one.

I don’t see AI as a junior engineer or a looming threat. I see it as a companion—reducing friction, speeding things up, and helping me focus on what actually matters.

As long as I stay in control of the decisions, that’s a tradeoff I’m happy to make.

👉 If you’d like to continue the conversation, you can find me on X or LinkedIn.

Found this post helpful? Give it a like or share it with someone who might need it 👇🏼

Making a custom input counter component accessible

Maya Shavin 🌷☕️🏡 — Wed, 16 Apr 2025 07:32:43 +0000

This blog post is not a tutorial on how to build an input counter component, but rather a discussion on how to structure the component for accessibility and good practice.

The problem of overlapping elements

We recently encountered an input counter component that failed the accessibility test performed by Evinced Web Flow Analyzer. The reported error was "There is an overlapping between interactive elements" involving the increment button and the input field. This issue surprised us because, at first glance, the component appeared accessible, with keyboard navigation, voiceover, and focus state working as expected during manual testing.

To investigate, we examined the component's implementation. Initially, its HTML template seemed well-structured, with the increment button, input field, and decrement button nested as sibling elements within a div container:

<div class="container">
  <button aria-label="Increment value" class="btn incr">+</button>
  <input type="number" class="input" aria-label="Counter value" class="counter" />
  <button aria-label="Decrement value" class="btn decr">-</button>
</div>

However, the component's CSS styling revealed a different story. The increment and decrement buttons were absolutely positioned, while the input field was styled with width: calc(100% - 60px) and horizontal padding (padding-inline: 30px), aligning with the button widths:

.container {
  /**... */
  width: 150px;
  position: relative;
}

.btn {
  position:absolute;
  height: 100%;
  min-width: 30px;
}

.incr {
  left: 1px;
}

.decr {
  right: 0;
}

.counter {
  border:none;
  padding: 5px;
  padding-inline: 30px;
  width: calc(100% - 60px);
  text-align: center;
}

While visually effective, this CSS introduced poor positioning practices:

Using position: absolute removes buttons from the normal document flow, forcing the browser into additional layout computations.
Button positions aren't relative to the input field, causing additional complexity in CSS rules when adjusting font sizes, widths, or container dimensions.
Absolute positioning complicates RTL/LTR language support (such as Arabic or Hebrew), requiring extra CSS adjustments.
There is no actual necessity for absolute positioning since elements are already correctly structured in HTML.

Additionally, the left: 1px rule caused a 1px overlap of the increment button on the input field, directly triggering the accessibility error.

Fixing overlapping and RTL issues using CSS Flexbox

A simple fix would be adjusting left: 1px to left: 0, removing the immediate overlap. However, this would only patch the bug without addressing the root issue (position: absolute).

A better solution is using CSS Flexbox for the container, eliminating absolute positioning entirely. The updated CSS rules remove unnecessary properties (left, right, height: 100%, padding, and calc()):

.container {
  border: 1px solid lightgray;
  padding:0;
  display: flex;
}

.btn {
  min-width: 30px;
}

input {
  border:none;
  padding: 5px;
  text-align: center;
}

However, applying Flexbox introduces an overflow issue for the input field, as form elements inherently have a default width set by browser stylesheets.

Resolving input overflow in Flexbox

To address the overflow, set min-width: 0 and flex: 1 on the input field. This ensures it dynamically shrinks or grows within the available container space:

input {
  /** ... */
  min-width: 0;
  flex: 1;
}

Alternatively, using a fieldset instead of a div container could omit the min-width: 0 property. This provides a semantically meaningful solution beneficial for accessibility.

Supporting RTL/LTR languages

With Flexbox, the component inherently supports RTL/LTR languages without additional CSS rules. To verify this, use the dir attribute on the container:

<div class="container" dir="rtl">
  <button class="increment" aria-label="Increment value" class="btn incr">+</button>
  <input type="number" class="input" aria-label="Counter value" class="counter" />
  <button class="decrement" aria-label="Decrement value" class="btn decr">-</button>
</div>

This approach automatically swaps the increment and decrement buttons appropriately, maintaining a centered input field.

Summary

In this blog post, we addressed accessibility issues caused by overlapping elements in an input counter component due to absolute positioning. By replacing this with CSS Flexbox and adjusting the CSS style of input field, we significantly improved the component's accessibility and flexibility, providing RTL/LTR language support out of the box.

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 Follow me on X | LinkedIn.

Like this post or find it helpful? Share it 👇🏼 😉

Managing Multi-Step Forms in Vue with XState

Maya Shavin 🌷☕️🏡 — Wed, 12 Feb 2025 08:48:43 +0000

State management is essential for any application, ensuring a consistent data flow and predictable behavior. Choosing the right approach impacts scalability and maintainability.

In this article, we'll explore how to refactor a multi-step sign-up form in Vue.js to use XState, a state management library based on finite state machines, making state handling more structured and efficient.

Table of Contents
The challenge of managing state a multi-step sign-up form wizard
What Are State Machines & XState?
Building a sign-up form wizard machine with XState
- Defining the State Machine
- Integrating XState in the Component
- Adding Asynchronous Submission
- Updating the UI for Submission Status
- Passing Data to submitForm
Mapping Component's Data to Context
Resources
Summary
- What's next?

The challenge of managing state a multi-step sign-up form wizard

Let's say we have a sign-up form built as a two-step wizard: one step to collect the user's name and another for their email address. We'll call this component SignupFormWizard.

<template>
  <form>
    <div class="form-main-view">
      <div v-if="isNameStep">
        <label for="name">Name</label>
        <input id="name" placeholder="Name" />
      </div>
      <div v-else-if="isEmailStep">
        <label for="email">Email</label>
        <input id="email" placeholder="Email" />
      </div>
      <div v-else-if="isSubmitStep">
        <p>Submitting...</p>
      </div>
    </div>
    <div>
      <button @click="prev" v-if="isEmailStep">Prev</button>
      <button @click="next" v-if="isNameStep">Next</button>
      <button @click="submit" v-else-if="isEmailStep">Submit</button>
    </div>
  </form>
</template>

Here's how we manage the local state in the script section:

<script setup>
import { ref, reactive, computed } from 'vue'

const formData = reactive({ name: '', email: '' })
const step = ref(1)

const isNameStep = computed(() => step.value === 1)
const isEmailStep = computed(() => step.value === 2)
const isSubmitStep = computed(() => step.value === 3)
const prev = () => { step.value > 1 && step.value-- }
const next = () => { step.value < 3 && step.value++ }
const submit = () => { step.value = 3 }
</script>

Our form behaves as follows:

In this implementation, we track the form's step using a step variable with ref(), store form data in a reactive object, and define functions to handle navigation between steps and submission.

For a simple form like this, this approach works fine. However, as the form grows in complexity, state management becomes more challenging. If we need to add more steps, handle asynchronous submission (including error and success states), or introduce additional logic, the code can quickly become difficult to maintain.

So, how can we simplify this process while making it more predictable and scalable? Let's explore a better approach.

What Are State Machines & XState?

State machines are models that define a system's behavior by breaking it down into a finite number of states. Transitions between these states occur one at a time, triggered by predefined events.

In simple terms, states act like nodes in a graph, while events function as edges connecting these nodes. Every state and transition is explicitly defined.

State machines are particularly useful for managing complex systems because they provide a structured and predictable way to handle application state. A classic example is a traffic light system, which consists of three main states: red, yellow, and green. The system follows a strict sequence—transitioning from red to yellow, then from yellow to green, and back—using a next() event that can be scheduled.

Building on this concept, XState provides a declarative and predictable approach to state management in TypeScript. It can integrate with modern front-end frameworks like React and Vue through dedicated packages such as @xstate/react and @xstate/vue.

Next, let's explore how we can refactor our SignupFormWizard component to use XState.

Building a sign-up form wizard machine with XState

To integrate XState, we install the necessary packages:

npm install xstate @xstate/vue

Defining the State Machine

We create a new file, machines/signUpMachine.js, and set up the state machine:

import { setup } from 'xstate';

const signUpMachineConfig = setup({
  id: 'signUpMachine',
});

export const signUpMachine = signUpMachineConfig.createMachine({
  initial: 'name',
  context: {},
  states: {
    name: { 
      on: { NEXT: 'email' } 
    },
    email: { 
      on: { PREV: 'name', SUBMIT: 'onsubmit' } 
    },
    onsubmit: {},
  },
});

This defines a three-state machine (name, email, and onsubmit) with transitions triggered by NEXT, PREV, and SUBMIT events.

Integrating XState in the Component

In SignupFormWizard.vue, we connect the machine using useMachine() from @xstate/vue:

<script setup>
import { useMachine } from '@xstate/vue';
import { signUpMachine } from '../machines/signUpMachine';

const { snapshot: state, send } = useMachine(signUpMachine);
</script>

We then replace the local step variable with state.matches() for checking the active state:

const isNameStep = computed(() => state.value.matches('name'))
const isEmailStep = computed(() => state.value.matches('email'))
const isSubmitStep = computed(() => state.value.matches('onsubmit'))

We also refactor navigation methods to use send():

const prev = () => { send({ type: 'PREV' }) }
const next = () => { send({ type: 'NEXT' }) }
const submit = () => { send({ type: 'SUBMIT' }) }

By doing so, we keeps the UI the same but makes state management more predictable.

Next, let's add more features to our form machine, such as asynchronous submission.

Adding Asynchronous Submission

To handle an asynchronous function and its states, we use fromPromise helper as follows:

import { fromPromise } from 'xstate';

const submitForm = fromPromise(async (data) => {
  // Handle submission logic
});

fromPromise() then creates an XState actor that triggers the onDone event when the async function is resolved, and onError event when rejected.

We then modify the onsubmit state to invoke this function:

export const signUpMachine = signUpMachineConfig.createMachine({
  //...
  states: {
    onsubmit: {
      invoke: {
        src: submitForm,
        onDone: 'success',
        onError: 'error',
      },
    },
    success: { on: { RESET: 'name' } },
    error: { on: { RETRY: 'onsubmit' } },
  },
});

In this setup, we also add RETRY and RESET events to error and success states, respectively, to handle the retry and reset functionalities.

Next, let's modify our component to reflect these changes.

Updating the UI for Submission Status

We modify the template to display success and error states:

<template>
  <form>
    <div class="form-main-view">
    <!--...-->
      <div v-else-if="isSuccess">
        <p>Form submitted successfully!</p>
        <button @click="reset">Reset</button>
      </div>
      <div v-else-if="isError">
        <p>Submission failed</p>
        <button @click="retry">Retry</button>
      </div>
    </div>
    <!--...-->
  </form>
</template>

And we update the component logic:

const isSuccess = computed(() => state.matches('success'));
const isError = computed(() => state.matches('error'));

const reset = () => send({ type: 'RESET' })
const retry = () => send({ type: 'RETRY' })

With these changes, users can now retry or reset the form after submission.

Passing Data to submitForm

To store and pass form data, update the machine’s context:

export const signUpMachine = signupMachineConfigs.createMachine({
  //...
  context: {
    formData: {},
  },
  //...
});

Then, we update the SUBMIT event to perform side actions and update the context data with assign() method:

export const signUpMachine = signUpMachineConfig.createMachine({
  //...
  states: {
    //...
    email: {
      on: {
        //...
        SUBMIT: {
          target: 'onsubmit',
          actions: assign({
            formData: (context, event) => ({ ...event.formData }),
          }),
        },
      },
    },
  },
});

In SignupFormWizard, we modify the submit() function to include the form data:

const submit = () => { send({ type: 'SUBMIT', formData: formData.value }) }

To ensure the submitForm function receives the required form data, we update the onsubmit state to include an input field:

export const signUpMachine = signUpMachineConfig.createMachine({
  //...
  states: {
    //...
    onsubmit: {
      invoke: {
        src: submitForm,
        input: ({ context }) => ({ ...context.formData }),
      },
    },
  },
});

Xstate then injects then input value into submitForm function, as follows:

const submitForm = fromPromise(async ({ input }) => {
  console.log([input.name, input.email]);
  //actual logic
});

We can also replace the local formData state in the component with the machine's context.formData instead. We do that next.

Mapping Component's Data to Context

To bind form inputs to the machine's context, we can use v-model:

<input id="name" placeholder="Name" v-model="state.context.formData.name" />
<input id="email" placeholder="Email" v-model="state.context.formData.email" />

Alternatively, we can use an UPDATE event to modify context dynamically:

export const signUpMachine = signupMachineConfigs.createMachine({
  //...
  states: {
    name: {
      on: {
        NEXT: 'email',
        UPDATE: {
          actions: assign({
            formData: (context, event) => ({
              ...context.formData,
              name: event.value,
            }),
          }),
        },
      },
    },
    email: {
      on: {
        PREV: 'name',
        UPDATE: {
          actions: assign({
            formData: (context, event) => ({
              ...context.formData,
              email: event.value,
            }),
          }),
        },
      },
    },
    //...
  },
});

And we bind inputs to this event:

const update = ($event) => send({ type: 'UPDATE', value: $event.target.value });

And update the template:

<input id="name" placeholder="Name" @input="update" />
<input id="email" placeholder="Email" @input="update" />

Since @input triggers on every keystroke, consider wrapping it with a debounce function for better performance.

With this setup, our machine’s context stays in sync with the UI, eliminating the need to pass formData in the SUBMIT event:

const submit = () => { send({ type: 'SUBMIT' }) }

And removing formData from the machine definition:

export const signUpMachine = signUpMachineConfig.createMachine({
  //...
  states: {
    //...
    email: { 
      on: { 
        //...
        SUBMIT: { target: 'onsubmit' } 
      } 
    },
  },
});

That's it! We've successfully refactored our multi-step form wizard to use XState for robust state management. Our state machine's flow now looks like this, with the initial state of name:

Additionally, we can use XState’s visualizer tool to visualize our machine logic, by importing our code.

Resources

Summary

In this article, we explored how to manage a multi-step form in Vue.js using XState. We refactored our form to leverage state machines for predictable state management and introduced features like asynchronous submission and context-based data handling. This approach enhances maintainability and can be applied across different front-end frameworks.

What's next?

We can further improve our form by adding guards to prevent invalid transitions and dynamically updating the UI based on conditions. Try experimenting with XState and see how it simplifies state management in your projects!

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 If you'd like to catch up with me sometimes, follow me on X | LinkedIn.

Like this post or find it helpful? Share it 👇🏼 😉

My Top 5 VSCode Extensions to Supercharge Your Markdown Writing

Maya Shavin 🌷☕️🏡 — Wed, 29 Jan 2025 07:08:40 +0000

As a developer and tech blogger, I frequently write technical blog posts and documentation in Markdown to share knowledge with the community. VSCode has been my go-to editor for managing and crafting Markdown content efficiently, besides coding. Over time, I've discovered some VSCode extensions that have transformed my writing experience and made it faster, and more productive. In this article, I'll share my top 5 VSCode extensions for Markdown writing and explain how they can supercharge your workflow.

Table of Contents
Writing Markdown in VSCode
Markdownlint by David Anson
Markdown All in One by Yu Zhang
Word Count by Microsoft
:emojisense: by Matt Bierner
CoCover - The AI Assistant for Generating Cover Images
Summary

Writing Markdown in VSCode

Introduced in 2004, Markdown is a lightweight markup language with plain text formatting syntax. It's widely used for drafting and writing documentation, such as README files. Personally, I find writing and storing my articles as Markdown files for my website a much more convenient approach, especially in VSCode , compared to using standard WYSIWYG editors. It helps me stay focused and manage my content more efficiently.

VSCode, a free and popular IDE (or code editor), provides excellent built-in support for Markdown editing, including syntax highlighting and preview features, such as a full preview with Shift + Ctrl/Cmd + V or a side-by-side preview with Ctrl/Cmd + K + V.

Beyond these basic features, you can enhance your Markdown editing experience with extensions. Here are five VSCode extensions that have significantly improved my Markdown writing workflow:

Markdownlint by David Anson

Markdownlint is the first extension I installed when working with Markdown files. It keeps my Markdown clean and consistent by flagging common syntax issues such as missing spaces, trailing spaces, and inconsistent indentation.

Markdown All in One by Yu Zhang

Markdown All in One is a powerful extension that offers a collection of features to streamline Markdown editing. It includes shortcuts for common syntax elements like headers, lists, and tables, along with keyboard shortcuts for toggling bold, italics, and code formatting.

One of my favorite features is its Table of Contents (TOC) generator, which automatically updates the TOC based on the headings in your file. This is particularly useful in helping readers navigate lengthy documents.

It also offers list-editing features for reorganizing content quickly, as well as handy tools like toggling code spans and automatic table formatting. These features make long-form document editing much more efficient and enjoyable.

Word Count by Microsoft

Word Count is a simple yet essential extension that shows the total word count of your current document in the status bar. It's perfect for tracking article length and ensuring your posts meet the word count requirements.

Once installed, you'll find the word count displayed in the bottom status bar, updating in real-time as you type.

:emojisense: by Matt Bierner

:emojisense: is a fun and practical extension for adding emojis to your Markdown files. It provides an inline, searchable emoji picker that makes finding and inserting emojis super easy.

To use the extension, we type : followed by the emoji name or keyword. The extension will display matching emojis for quick insertion. 💡

CoCover - The AI Assistant for Generating Cover Images

Last but not least, CoCover is an AI-powered extension I developed for generating beautiful cover images directly in VSCode. It uses GitHub Copilot and OpenAI's DALL-E to create covers based on your article's title and content.

With CoCover, you can generate blog covers, upload them to Cloudinary, or save them locally—all without leaving VSCode. It's a fantastic tool for streamlining your content creation workflow while making your articles visually appealing.

Summary

These are my top five VSCode extensions for Markdown writing. They've helped me streamline my workflow, minimize context switching, and create better Markdown-based content.

What about you? What are your favorite VSCode extensions for Markdown writing? I'd love to hear your recommendations and suggestions! 😄

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 If you'd like to catch up with me sometimes, follow me on X | LinkedIn.

Like this post or find it helpful? Share it 👇🏼 😉

Mastering Flexible Layouts: CSS Flexbox VS Grid for Responsive Design

Maya Shavin 🌷☕️🏡 — Wed, 22 Jan 2025 08:21:13 +0000

In this post, we will discover different approaches to distribute a list of cards evenly, horizontally and responsively in different screen sizes using CSS Flex and Grid.

Table of Contents
The Challenge
Using CSS Flexbox to Create a Flexible List of Cards
Displaying Cards Evenly with flex-grow and flex-basis
Using CSS Grid for a Flexible List of Cards
Summary

The Challenge

In a gallery (or list) component, we often want to display items as cards, such as articles, products, or images. The number of cards per row can be flexible, depending on the container's width. Each card should expand to fill the available space and shrink to its minimum width as needed.

The layout should remain consistent across screen sizes, with the cards distributed from left to right, wrapping to the next row as necessary. The cards should maintain equal height, width, and spacing between them.

Here’s a simple starting point for the HTML structure and CSS:

<ul class="list-items">
  <li class="item"> >
    <!--item's content-->
  </li>
  <!--more items-->
</ul>
<style>
  .list-items {
    list-style: none;
    max-width: 500px;
  }

  .item {
    border: 1px solid gray;
    padding: 10px;
  }
</style>

With the above code, the browser displays the container according to the screen’s width but does not exceed 500px:

Currently, the items are not distributed horizontally. We’ll fix this next using CSS Flexbox.

Using CSS Flexbox to Create a Flexible List of Cards

CSS Flexbox provides a flexible and responsive layout structure using the display: flex property. To achieve horizontal flow, we use the flex-wrap property to wrap cards to the next row when necessary, and gap to define spacing between cards:

.list-items {
  display: flex;
  flex-wrap: wrap;
  gap: 10px;
}

Now, the cards flow horizontally:

However, not all cards have the same width (e.g., Card 9 and Card 10). To fix this, we can set a fixed width for .item:

.item {
  /* other styles */
  width: 100px;
}

This ensures all cards have the same width. But when the container's width changes, the cards cannot expand to fill the space. This leaves gaps at the end of each row, as shown below:

We can try to address this using justify-content properties like space-between, space-around, space-evenly, or center:

While these approaches work differently, none fully meet our goal of evenly distributing cards in size and spacing.

Instead, we can use flex-grow and flex-basis, which we’ll explore next.

Displaying Cards Evenly with flex-grow and flex-basis

The flex-basis property defines the initial size of a card before any extra space is distributed, while flex-grow: 1 (or simply flex: 1) allows the card to grow relative to its siblings. Combining these properties ensures that cards distribute evenly in size and spacing:

.item {
  /* other styles */
  flex: 1;
  flex-basis: 100px;
}

Here’s the result:

However, the last card still expands to fill the remaining space because it has no sibling to share it with. This breaks our consistency goal. To address this issue, let's turn to CSS Grid.

Using CSS Grid for a Flexible List of Cards

CSS Grid is a 2-dimensional layout system that organizes content into rows and columns. To create a flexible card layout, we can use the display: grid property:

.list-items {
  display: grid;
  gap: 10px;
}

While CSS Grid supports many properties similar to Flexbox, such as gap and alignment options, it requires us to define the layout structure in advance. For a flexible layout, we can use grid-template-columns with auto-fit, minmax(), and repeat() functions:

.list-items {
  /* other styles */
  grid-template-columns: repeat(auto-fit, minmax(100px, 1fr));
}

Here’s what the above code does:

repeat(<number>, <size>): Repeats columns of a specified size. Using auto-fit automatically adjusts the number of columns to fit the available space.
minmax(<min>, <max>): Defines the size range for each column, setting a minimum size of 100px and a maximum size of 1fr (1 fraction of the available space).
Combining these with grid-template-columns ensures the layout adjusts responsively.

And that's it! The result is a perfectly responsive layout:

Summary

CSS Flexbox and CSS Grid are powerful tools for creating flexible, responsive designs. While Flexbox excels at managing one-dimensional layouts, CSS Grid offers unparalleled flexibility for two-dimensional layouts. Understanding the strengths of each approach ensures you can choose the right tool for your design goals. I hope this article provides clarity and inspires you to create your next layout. If you have questions or feedback, feel free to reach out.

Happy coding! 🚀

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 If you'd like to catch up with me sometimes, follow me on X | LinkedIn.

Like this post or find it helpful? Share it 👇🏼 😉

Resolving Auto-Scroll issues for overflow container in a Nuxt app

Maya Shavin 🌷☕️🏡 — Wed, 15 Jan 2025 08:47:00 +0000

In this article, I share how I resolved the auto-scroll issue caused by an overflow container within a non-scrollable body in a Nuxt app, and improved the user experience when scrolling my website

Table of Contents
The Initial Design
The Issue
The Solution
Summary

The Initial Design

When I built my website using Nuxt.js, my initial design was to have only the main content container scrollable, while the header and footer remained fixed—without using CSS fixed or absolute positioning.

To achieve this, I used a combination of CSS flex and overflow properties, starting with the body tag:

body {
  overflow: hidden;
  height: 100%;
}

In the default.vue layout:

<div class="h-full flex flex-col bg-mayash-main-light dark-mode">
  <nav-header />
  <main class="flex-1 overflow-y-auto overflow-x-hidden">
    <slot />
  </main>
  <nav-footer />
</div>

In the above code, I ensured the body was not scrollable using overflow-hidden while keeping the height statically set to 100%. The main container was set to flex-1 to expand and fill the remaining space after the header and footer. I used overflow-y-auto to make the container scrollable vertically only. This setup allowed the page to work as intended based on the initial design.

However, problems arose when I added the table of contents to the article page. The table of contents is a list of links to section headings within an article, and clicking on a link should scroll to the corresponding section. Unfortunately, it didn’t.

Additionally, when refreshing the article page with an HTML anchor (#) in the URL, the browser didn’t scroll to the desired section. Navigating back to the article page from another page also failed to auto-scroll to the top of the page. For example, navigating to the Speaking page from the Article page left the user at the bottom instead of at the top.

Furthermore, I received complaints about the footer being fixed at the bottom of the page, which some users found distracting when reading the article.

Clearly, I needed to change my design and fix these issues. But is it that simple? Let's find out.

The Issue

Nuxt.js 3 uses Vue Router to handle application routing, which includes auto-scrolling when navigating between pages, with a smooth transition effect. So, it should work, right?

Unfortunately, it didn’t.

I tried different workarounds, including using Vue Router custom scroll behavior, using scrollBehaviorType, and even window.scrollTo. None of these approaches worked.

So, is there a way to fix this issue?

The Solution

After some research, I discovered that the issue was caused by the combination of the overflow and height CSS properties. When height is set to a fixed value (like 100%) and overflow on the body tag is set to hidden, the scrollbar displayed on the right side of the page isn’t for the body tag but for the main container instead.

When navigating between routes or sections, the browser, by default, tries to scroll the body tag. Since the body is not scrollable, the browser doesn’t know which container to scroll, leading to the issue.

There are several ways to work around this problem, such as querying the main container's DOM reference and using the scrollTo method to manually scroll the container to the desired section whenever the route changes. However, this approach is not ideal — it’s complex to implement and not a good practice.

A more straightforward solution is to remove the height: 100% and overflow: hidden properties from the body tag and use position: sticky for the header to keep it fixed at the top instead:

body {
  /* overflow: hidden; */
  /* height: 100%; */
}

header {
  position: sticky;
  top: 0;
  z-index: 100;
}

We also need to set top: 0 and z-index to ensure the header remains at the top of the page and appears above other elements.

And that’s it! The page now has the header fixed at the top, and the content automatically scrolls based on route changes or HTML anchor links, utilizing the browser’s default smooth transition effect.

Summary

In this article, I shared how I resolved the auto-scroll issue caused by an overflow container within a non-scrollable body in a Nuxt app. The issue stemmed from the combination of overflow and a fixed height CSS property and can affect any web project, not just those using Nuxt or Vue Router. Depending on your goals, the solution may involve simply removing this CSS combination or implementing a more complex workaround, such as manually triggering scrollTo on the target scrollable container. So, the next time you encounter this issue, you’ll know how to fix it 😉!

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 If you'd like to catch up with me sometimes, follow me on X | LinkedIn.

Like this post or find it helpful? Share it 👇🏼 😉

Building Social Media Automation: LinkedIn Sharing with Serverless Function

Maya Shavin 🌷☕️🏡 — Wed, 08 Jan 2025 06:32:32 +0000

After publishing a new article or blog post, the need to promote it on social media arises. Manually sharing the post can be time-consuming and inefficient. In this article, we will explore how to build a serverless function to share an article URL on LinkedIn using its JavaScript API client and Netlify serverless functions. This is part of building an automated workflow for social media promotion.

Table of Contents
Prerequisites
Getting started
- Setting up the permissions
- Configuring OAuth 2.0 settings
Sharing a post with URL using LinkedIn API Client
- Getting the user's unique id
- Sharing a post URL
Exposing as a Netlify serverless function
Testing the Functionality
Deploying with Netlify
Summary

Prerequisites

To follow along with this tutorial, you will need the following:

A LinkedIn account
Node.js and Netlify CLI installed.
A Netlify account and a site created for deploying the serverless function.
Basic knowledge of JavaScript and TypeScript.

Getting started

To start working with LinkedIn APIs, we need to perform the following steps:

Head to LinkedIn Developer Console with your LinkedIn account.
Create a new app by clicking on the Create App button.
Fill in the details such as App Name (Social Media Tester, for example) and App logo image.
You will need to a LinkedIn Company page to associate with the app you are creating (any page you have admin access to be able to verify the connection afterwards).

Once done, the portal will redirect you to the app dashboard, where we can start configuring the permissions and API products we need for the app.

Setting up the permissions

In the app dashboard, click on Products tabs and request access to the Share on LinkedIn and Sign In with LinkedIn using OpenID Connect products.

Configuring OAuth 2.0 settings

With these permissions granted, we can head to the OAuth 2.0 token generator tool to generate an access token for the app. The token should include the following scopes: w_member_social for posting on behalf of the user, and profile and openid for user authentication and profile information.

This access token is a 3-legged OAuth token, ensuring that the user has explicitly authorized the application to act on their behalf. After generating the token, we can use it to authenticate and securely make requests to the LinkedIn APIs. Additionally, we can review the permissions and scopes granted to the app in the Auth tab of the app dashboard.

Great! Now that we have the access token and the app set up, we can start building the automation to post on LinkedIn on behalf of the user (which, in this case, is us).

Sharing a post with URL using LinkedIn API Client

To start sharing posts programmatically, we can use the official LinkedIn API JavaScript Client for Node.js by installing it as a project dependency:

npm install linkedin-api-client

# or with yarn
yarn add linkedin-api-client

This library provides a straightforward and lightweight way to interact with LinkedIn API endpoints, leveraging Axios and TypeScript under the hood.

Next, let's create a new file, linkedin.ts, to encapsulate the logic for sharing posts on LinkedIn. We start by initializing a client instance to interact with the API, as shown below:

// linkedin.ts
import { RestliClient } from 'linkedin-api-client';

const client = new RestliClient();

Getting the user's unique id

To post on behalf of a user, we first need to retrieve the user's unique ID (which is different from the user's LinkedIn handle). This can be done by using the /userinfo endpoint with the access token generated earlier:

// linkedin.ts
const getUserId = async (accessToken: string) => {
  const userResponse = await client.get({
    resourcePath: "/userinfo",
    accessToken
  });

  return userResponse.data?.sub;
};

The unique ID is located in the sub field of the response's data. This value is required for the next step: sharing a post on the user's behalf.

Sharing a post URL

Within linkedin.ts, we define a function to share a post's URL as follows:

type SharePostArgs = {
  url: string;
  text: string;
};

export const sharePost = async (token: string, content: SharePostArgs) => {
  //logic
};

The sharePost function takes the access token and the content to share, which includes the URL and the text to accompany the post. We will then create a new post entity on the User Generated Contents resource using /ugcPosts endpoint, as shown below:

export const sharePost = async (token: string, content: SharePostArgs) => {
  const response = await client.create({
    resourcePath: '/ugcPosts',
    accessToken: token,
    entity: {
      //entity payload
    }
  });
};

The entity payload is configured to include the user’s unique ID, retrieved earlier, as the author. The author field follows the format urn:li:person:${userId}. Additionally, we specify:

The lifecycleState as "PUBLISHED".
The visibility as "PUBLIC" so the post is visible to the LinkedIn network.

Here’s the updated implementation:

export const sharePost = async (token: string, content: SharePostArgs) => {
  //Get user's unique id
  const userId = await getUserId(token);

  const response = await client.create({
    resourcePath: '/ugcPosts',
    accessToken: token,
    entity: {
      author: `urn:li:person:${userId}`,
      lifecycleState: "PUBLISHED",      
      visibility: {
        "com.linkedin.ugc.MemberNetworkVisibility": "PUBLIC"
      }
    }
  });
};

Next, we define the sharing content within the specificContent field of the entity object. For this scenario, the specificContent field includes a com.linkedin.ugc.ShareContent object, which has the following properties:

shareCommentary: Accepts content.text as the main text content to display.
shareMediaCategory: Specifies the type of media shared in the post (set as "ARTICLE").
media: An array of media assets for the "ARTICLE" category, where each item includes: the URL to share and a READY status.

Below is the updated code:

//...
  entity: {
    //...
    specificContent: {
      "com.linkedin.ugc.ShareContent": {
        shareCommentary: {
          text: content.text
        },
        shareMediaCategory: "ARTICLE",
        media: [
          {
            status: "READY",
            originalUrl: content.url,
          }
        ]
      }
    }
  }

Upon successfully completing the request, the response contains a createdEntityId, representing the unique ID of the created entity. We can return this value to the caller for further reference:

export const sharePost = async (token: string, content: SharePostArgs) => {
  //...
  return response.createdEntityId;
};

And that's it! We’ve created a function that leverages the LinkedIn API to share a post URL on behalf of a user. In the next step, we’ll expose this function as a serverless endpoint using Netlify, bringing us closer to fully automating the process of sharing articles on social media.

Exposing as a Netlify serverless function

We run the CLI command netlify functions:create and follow the prompts to scaffold a new Netlify serverless function named share-on-linkedin. The Netlify CLI will generate the function in the functions directory with the following initial code:

/* functions/share-on-linkedin.mts */
import type { Context } from '@netlify/functions'

export default async (request: Request, context: Context) => {
  try {
    return new Response(JSON.stringify("Hello"), {
        headers: {
          'content-type': 'application/json',
        },
      })
  } catch (error) {
    // Return an error response
    return new Response(
      JSON.stringify({ error: error.message || 'An error occurred' }),
      {
        status: 500,
        headers: {
          'content-type': 'application/json',
        },
      }
    );
  }
};

In this above code, we use TypeScript and define the function as async to handle the asynchronous nature of LinkedIn API calls.

Next, we update the serverless function to perform the following actions:

Parse the request body to extract the content to share,
Retrieve the access token from environment variables (can be set in .env file in the project root),
Call the sharePost function (defined earlier in linkedin.ts ) with the extracted parameters, and
Return the created entity ID as the response.

import type { Context } from '@netlify/functions'
import { sharePost } from '../utils/linkedin';

//Retrieve the access token from environment variables
const TOKEN = process.env.LINKEDIN_ACCESS_TOKEN;

export default async (request: Request, context: Context) => {
  try {
    //Parse the request body
    const body = await request.json()    
    const { url, text } = body

    //Share the post
    const createdEntityId = await sharePost(TOKEN, { url, text });

    //Return the created entity ID
    return new Response(JSON.stringify({ createdEntityId }), {
        headers: {
          'content-type': 'application/json',
        },
      })
  } catch (error) {
    //...
  }
}

At this point, the serverless function is ready. We can deploy it to Netlify and test its functionality by making POST requests to the endpoint.

Testing the Functionality

To test the serverless function, start a local server using the CLI command netlify dev. Then, use a tool like Postman or Insomnia to send a POST request to the server endpoint with the following JSON payload:

{
  "url": "https://mayashavin.com/articles/share-onbehalf-linkedin",
  "text": "Check out this awesome article!"
}

Alternatively, we can create a simple form UI to interact with the serverless function API, and verify that the post is successfully shared on LinkedIn.

Once the function is working as expected, let's proceed to deploy it to Netlify to make it available for use.

Deploying with Netlify

To deploy our function to Netlify, run the following command:

netlify deploy --prod

The CLI deploys the function to your Netlify production environment. You can then find the function endpoint in the Netlify dashboard.

Important: Make sure to configure the LINKEDIN_ACCESS_TOKEN environment variable in the dashboard. This step is essential for the function to authenticate and operate correctly.

Summary

We have successfully built a serverless API to share an article URL on LinkedIn on behalf of a user, leveraging the LinkedIn API JavaScript Client and Netlify serverless functions. This marks a significant step toward automating the social media sharing process for blog posts.

From here, we can extend the automation workflow to include other social media platforms and scheduled tasks. For example, we could integrate platforms like X (formerly Twitter), Facebook, or BlueSky, and customize the timing and content of posts to maximize audience engagement and reach.

With that, stay tuned for more updates on this series!

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 Want to support me? Buy me a coffee.

Like this post or find it helpful? Share it 😉

Efficient Blog Cover Image Generation with CoCover for VS Code

Maya Shavin 🌷☕️🏡 — Mon, 04 Nov 2024 13:43:20 +0000

As a developer, I often find myself writing technical blog posts and articles in markdown format to share my knowledge with the community. Part of my content creation routine is choosing the cover image, which helps attract readers and make the content more engaging. However, this task is always time-consuming and requires additional tools and resources, leading to a significant amount of context-switching and breaking my flow.

To address this challenge, I've recently developed and lauched CoCover, a new GitHub Copilot extension for VS Code, aiming to make your content creation process experience with markdown and VS Code more efficient and seamless.

So what does CoCover offer? Let's take a look!

CoCover - The AI assistant for generating cover images and more

CoCover - Copilot for Cover image - leverages the power of GitHub CoPilot and Dalle-3 for image generation based on your content, without leaving your VS Code editor.

This extension adds a new Chat Participant as @CoCover assistant using the new VS Code's Chat extension API, and offers the following features:

Generate cover image based on given content

After selecting a section of relevant information (e.g., title and description) in your markdown file and typing @cocover /image, the extension will generate a cover image based on the selected content and any additional prompt you provide in your Copilot chat. OpenAI API key is required to use this feature, as CoCover uses OpenAI's Dalle-3 model to complete the task.

You can then preview the image in the editor and decide whether to save it locally, or upload it to Cloudinary.

Upload generated image to Cloudinary

Upon selecting the Cloudinary option, CoCover will prompt you for your Cloudinary credentials for uploading, including your Cloud name, API key, and API secret. And then, it will upload the generated image to your Cloudinary account and provide you with the secure image URL, ready for use.

Once uploaded, you can copy the image URL to your clipboard, or have CoCover insert it directly into your markdown file, as a cover_image frontmatter, completing the cover image creation process.

Another option is to save the image locally, which we'll explore next.

Save generated image to a local destination

CoCover will prompt you to select a destination folder to save the generated image, in .png or .jpg format.

Once saved, CoCover will also give you the option to insert the image URL into your markdown file, as a cover_image frontmatter, or copy the image URL to your clipboard.

With these features, CoCover aims to streamline your content creation process directly from your VS Code editor and reduce the time, effort and amount of context-switching involved in getting a professional-looking cover image for your blog posts and articles. No more searching for stock images or manually creating and uploading cover images - let CoCover do the heavy lifting for you!

What's next?

I'm excited to see how CoCover can help making your content creation experience in VS Code more delightful and to add more features such as suggesting content fixes to improve your writing quality. I'm looking forward to your feedback and suggestions for future improvements.

Feel free to install CoCover, give it a try, and let me know what you think! Or star 🌟 it on GitHub!

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 If you'd like to catch up with me sometimes, follow me on X | LinkedIn.

Like this post or find it helpful? Share it 👇🏼 😉

Effective Visual Regression Testing for Developers: Vitest vs Playwright

Maya Shavin 🌷☕️🏡 — Wed, 30 Oct 2024 06:27:15 +0000

Visual regression testing plays a crucial role in ensuring the UI and UX's consistency across different browsers, devices, and even screen sizes, especially for large applications. In this post, we will covers snapshot and pixel-to-pixel comparison with Vitest and Playwright, explore limitations, and provide insights into choosing the right visual testing approach for your project.

Table of Contents
Prequisites
What is visual regression testing?
Using snapshot for visual regression comparison in Vitest
- Limitations of snapshot visual testing
Pixel-to-pixel screenshot testing in Playwright
Screenshot visual testing with Vitest's browser mode and Playwright
Summary

Prequisites

For the demo purpose, we will use a Vue 3 project with Vitest and Playwright installed, with a SearchBox component as follows:

The implementation of the SearchBox component is available in this post.

For React developers, you can replace the Vue component with a React one, and Vue Test Utils with React Testing Library to render component. The rest of the steps below remains the same.

What is visual regression testing?

Visual regression testing (or visual testing) is a technique to verify the visual appearance and usability of an application's UI between changes, helping to identify any unintended bugs that might occur to the existing functionalities during the development process. It focuses solely on validating the visual aspects of a component that a user sees or interacts with, including layout, styling, and other visual elements.

There are several types of visual testing, including DOM-based comparison (snapshot testing), pixel-based comparison and manual comparison using screenshots. Depending on the requirements, we can implement visual testing at different levels with different tools, such as unit testing with Vitest or E2E testing with Playwright, or combining the two.

We'll start with visual unit testing using Vitest.

Using snapshot for visual regression comparison in Vitest

Vitest provides a toMatchSnapshot() method to take a snapshot of the component and compare it with an existing one, as seen in the following test for SearchBox Vue component:

import { render } from '@vitest/vue'
import SearchBox from './SearchBox.vue'

describe("SearchBox component", () => {
  it('should match snapshot', () => {
    const wrapper = mount(SearchBox, {
      /** props and other global plugins */
    });

    expect(wrapper).toMatchSnapshot();
  })
})

Upon the first run, Vitest will take a snapshot of the SearchBox component and store it in a .snap file within the __snapshots__ folder:

Below shows an example of the snapshot file, containing the component's DOM structures and HTML layout:

In the next run, Vitest will generate a new snapshot and compare it with the stored one. If they are different, for example, when we modify the input's placeholder to Search for a beer, the test will fail and Vitest will highlight the difference will in the terminal as follows:

Base on this result, we can decide whether to re-visit the changes, or update the snapshot file with the -u flag in the Vitest run command to accept them.

With that, we have enabled snapshot visual testing for our SearchBox component. However, there is a downside of using this method, which we will discuss in the next section.

Limitations of snapshot visual testing

Regular snapshot visual testing, unfortunately, does not fully provide a great developer experience, and high reliability level in visual consistency. It only compares the DOM structure and basic HTML layout of the component generated, without considering other styling aspects like colors, fonts, etc. For instance, if we change the input field #searchbox's color from black to red:

<style>
#searchbox {
  color: red;
}
</style>

The snapshot test will still pass, since it is unable to validate the style changes of the component. This limitation makes it less reliable for visual testing, especially for components with dynamic content or styles.

Another limitation is the readability of the snapshot files, which can lead to a maintenance nightmare, as developers may find it hard to identify the changes in these files for large components. After all, visual means what you see, and this snapshot testing does not provide a proper "see" representation.

A better alternative is using screenshot-based visual testing with Playwright, which we will discuss next.

Pixel-to-pixel screenshot testing in Playwright

To perform an E2E visual regression validation, Playwright provides a toHaveScreenshot() method that takes and compares screenshots of a specific component (in component testing), an element, or the whole page, as seen below for our SearchBox component:

/** e2e/searchbox.spec.js */
import { test, expect } from '@playwright/experimental-ct-vue';
import SearchBox from "../src/components/SearchBox.vue";

test("should match screenshot", async ({ mount, page }) => {
  const component = await mount(
    <SearchBox searchTerm="hello" />
  );

  await expect(page).toHaveScreenshot();
  await expect(component).toHaveScreenshot();

  /** other assertions */
})

On the first run, Playwright captures and stores the screenshots as an .png files to the __snapshots__\searchbox.spec.js-snapshots folder, with each file named based on the test case's name (should match screenshot), the testing browser (chrome) and the platform (darwin), as follows:

The generated screenshot file contains the view of the full page (1):

And of the component (2), as follows:

The runner also throws an error. From the second run onwards, Playwright will compare the new screenshots with the current stored ones, and highlight the pixel difference (with ratio) in the terminal, such as when we change the input's font color to red:

An image of the expected result, the actual result, and the difference between them is also available in the test result dashboard in the browser:

Additionally, we can adjust different the screenshot matcher's configurations like the maximum pixel difference maxPixelDifference, and threshold level by providing them as options to the toHaveScreenshot() method as follows:

await expect(page).toHaveScreenshot({
  maxPixelDifference: 100,
  threshold: 0.1,
});

With the above settings, Playwright will allow a maximum of 100 pixels difference and a threshold of 0.1 for the screenshot comparison. This way, we can fine-tune our visual testing to meet the project's requirements.

toHaveScreenshot() method is a great tool, as it provides a pixel-to-pixel visual comparison for the component. However, it only works with native Playwright tests, and isn't supported in Vitest's browser mode. For that, we need to use screenshot() method in the next section.

Screenshot visual testing with Vitest's browser mode and Playwright

We first need to install the relevant packages and enable the browser mode in Vitest, following this tutorial.

Once enabled, Vitest will then use Playwright to run all the tests in browser mode. Similar to the native Playwright, within a test, we can use screenshot() method to take a screenshot of a specific element, such as input, and save it to the path provided:

/**... */
  test('renders search input', async () => {
    /**... */
    const input = component.getByTestId('search-input')

    await input.screenshot({
      path: 'screenshots/searchbox_default_full.png',
    })
  });

The above code results in a screenshot of the input field, as shown below:

For the page's screenshot, we use the page object, from @vitest/browser/context, which is similar to the native Playwright's page object:

import { page } from '@vitest/browser/context';
/**... */
  test('renders search input', async () => {
    /**... */
    await page.screenshot({
      path: 'screenshots/searchbox_page.png',
    });
  });

Similar to toHaveScreenshot(), we can also adjust the screenshot's configuration by providing additional options to the screenshot() method, such as type, clip, omitBackground, etc., to define the file format, or capture the component's specific area.

Upon running the test, Vitest will take the screenshots and store them accordingly, ready for us to manually verify the UI, or integrate with an analyzer such as Applitools or Percy for visual comparison in an automated workflow.

But that's also the limitation of using Playwright's screenshot(), as it requires manual verification or integration with third-party tools, which can generate additional costs. At the time of writing, Vitest browser mode does not support Playwright's toHaveScreenshot() method or toMatchImageSnapshot() matcher from Jest-Image-Snapshot, which would have been a better option.

Summary

We have explored briefly different methods of visual testing with Vitest and Playwright, from manual to automated visual comparison with snapshot and screenshot, and the pros and cons of each approach. It is essential to consider your project's requirements and budget for choosing the suitable testing approach and keep the process efficient.

What's next? How about trying it out yourself and see which method works best for your project? Let me know your thoughts in the comments below!

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 Follow me on X | LinkedIn.

Like this post or find it helpful? Share it 👇🏼 or Buy me a coffee

Reliable Component Testing with Vitest's Browser Mode and Playwright

Maya Shavin 🌷☕️🏡 — Tue, 08 Oct 2024 14:10:00 +0000

Vitest is great for unit testing. But for frontend components that rely on user interactions, browser events, and other visual states, unit testing alone is not enough. We also need to ensure the component looks and behaves as expected in an actual browser. And to simulate the browser environment, Vitest requires packages like JSDOM or HappyDOM, which are not always reliable as the real ones.

An alternative is to use Playwright's Component Testing. However, this solution requires separate setup and run, which can be cumbersome in many cases.

This is where Vitest's browser mode comes in.

Table of Contents
Prequisites
The SearchBox component
Enable Vitest's browser mode with Playwright
Add the first browser test for SearchBox
Using the workspace configuration file
Run and view the results
Summary

Prequisites

You should have a Vue project set up with Vue Router and Vitest. If you haven't done so, refer to this post to set up the essentisal Vitest testing environment for your Vue project.

Once ready, let's create our testing component SearchBox.

The SearchBox component

Our SearchBox component accepts a search term and syncs it with the URL query params. Its template is as follows:

  <label for="searchbox">Search</label>
  <input v-model="search" 
    placeholder="Search for a pizza" 
    data-testid="search-input" 
    id="searchbox" />

With the script section:

import { useRouter } from "vue-router";
import { useSearch } from "../composables/useSearch";
import { watch } from "vue";

const props = defineProps({
  searchTerm: {
    type: String,
    required: false,
    default: "",
  }
});

const router = useRouter();

const { search } = useSearch({
  defaultSearch: props.searchTerm,
});

watch(search, (value, prevValue) => {
  if (value === prevValue) return;
  router.replace({ query: { search: value } });
}, {
    immediate: true
});

And in the browser, it will look like this:

Next, we will set up the browser mode for Vitest.

Enable Vitest's browser mode with Playwright

In vitest.config.js, we will setup browser mode as below:

// vitest.config.js
/*...*/
defineConfig({
  test: {
    /**... */
    browser: {
      enabled: true,
      name: 'chromium',
      provider: 'playwright',
      providerOptions: {},
    },
  }
})

In which, we configure the following:

enabled: enable the browser mode
name: the browser to run the tests in (chromium)
provider: the test provider for running the browser, such as playwright
providerOptions: additional configuration for the test provider.

We also specify which folder (tests\browser) and the file convention to use, avoiding any conflicts with any existing regular unit tests:

// vitest.config.js
/*...*/
defineConfig({
  test: {
    /**... */
    include: 'tests/browser/**/*.{spec,test}.{js,ts}',
  }
})

With that, we are ready to write our first browser test for SearchBox.

Add the first browser test for SearchBox

In the tests/browser folder, we create a new file SearchBox.spec.js with the following code:

/**SearchBox.spec.js */
import { test, expect, describe } from 'vitest';
import SearchBox from "@/components/SearchBox.vue";

describe('SearchBox', () => {
  test('renders search input', async () => {
    /** Test logic here */
  });
});

To render SearchBox, we use render() from vitest-browser-vue, and pass the initial search term as a prop:

/**SearchBox.spec.js */
/**... */
import { render } from 'vitest-browser-vue';

describe('SearchBox', () => {
  test('renders search input', async () => {
    const component = await render(SearchBox, {
      props: {
        searchTerm: "hello",
      },
    });
  });
});

Since SearchBox is using router from useRouter() from Vue Router, we need the following router setup:

Create a mock router using createRouter():

  /** SearchBox.spec.js */
  /**... */
  import { routes } from '@/router';
  import { createRouter, createWebHistory } from 'vue-router';

  const router = createRouter({
    history: createWebHistory(),
    routes: routes,
  })

Pass it as a global plugin to render():

  /** SearchBox.spec.js */
    test('renders search input', async () => {
      const component = await render(SearchBox, {
        /**... */, 
        global: {
          plugins: [router]
        }
      });
    });

Once done, we locate the input element by its data-testid, and assert its initial value using toHaveValue():

  test('renders search input', async () => {
    /**... */
    const input = await component.getByTestId('search-input')

    await expect(input.element()).toHaveValue('hello')
  });

Note here input received is just a Locator and not a valid HTML element. We need input.element() to get the HTML instance. Otherwise, Vitest will throw the below error:

To change the input's value, we use input.fill():

  test('renders search input', async () => {
    /**... */
    await input.fill('test')
  });

Alternatively, we can use userEvent() from @vitest/browser/context as follows:

import { userEvent } from "@vitest/browser/context"

/**... */
  test('renders search input', async () => {
    /**... */    
    await userEvent.fill(input, 'test')
  });

Both approaches perform the same. We can then assert the new value as usual:

await expect(input.element()).toHaveValue('test')

That's it! We have successfully written our first browser test.

At this point, we have one test configuration set for our Vitest runner. This setup will be problematic when Vitest need to run both unit and browser tests together in an automation workflow. For such cases, we use workspace and separate the settings per test type, which we explore next.

Using the workspace configuration file

We create a new file vitest.workspace.js to store the workspace configurations as follows:

import { defineWorkspace } from 'vitest/config'

export default defineWorkspace([
  {
    extends: 'vitest.config.js',
    test: {
      environment: 'jsdom',
      name: 'unit',
      include: ['**/*/unit/*.{spec,test}.{js,ts}'],
    },
  },
])

In which, we define the first configuration for unit tests using jsdom, based on the existing vitest.config.js settings. We also specify the folder and file convention for the unit tests.

Similarly, we define the second configuration for browser tests using playwright:

export default defineWorkspace([
  /** ... */,
  {
    extends: 'vitest.config.js',
    test: {
      include: ['**/*/browser/*.{spec,test}.{js,ts}'],
      browser: {
        enabled: true,
        name: 'chromium',
        provider: 'playwright',
      },
      name: 'browser'
    },
  },
])

And with that, we can run all our tests in a single command, which we will see next.

Run and view the results

We add the following command to our package.json:

{
  "scripts": {
    "test": "vitest --workspace=vitest.workspace.js"
  }
}

Upon executing yarn test, Vitest runs the tests based on vitest.workspace.js and displays the results in a GUI dashboard as follows:

Vitest labels each test by unit or browser status. We can then filter the tests by their statuses, or perform further debugging with the given browser UI per test suite.

Summary

We have learned how to set up browser mode for Vitest using Playwright, and write the first browser test. We have also explored how to take screenshots for visual testing, and use the workspace configuration to separate the settings per testing mode. One big limitation of Vitest's browser mode in comparison to Playwright's Component Testing is the lack of browser's address bar, limiting us from testing the component's state synchronization with URL query params in the browser. But it's a good start to build a scalable testing strategy for our Vue projects.

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 Follow me on X | LinkedIn.

Like this post or find it helpful? Share it 👇🏼 or Buy me a coffee

Seamless Contact Form experience with Netlify Form in Nuxt 3

Maya Shavin 🌷☕️🏡 — Wed, 07 Aug 2024 09:04:08 +0000

Contact form is an essential part of any portfolio site, where people can reach you for further queries and questions. In this article, we will explore how to use Netlify Form service to create a contact form and handle its submission from end to end in a Nuxt static site.

Prerequisites

You need to have an active Netlify account, and create a Nuxt 3 application using the following command:

npx nuxi@latest init your-nuxt-app

Once done, we are ready to build our contact form, starting with enabling the Netlify Form service.

Enabling Netlify Form service

Netlify Serverless Form is an out-of-the-box service from Netlify that allows us to manage forms in our static applications at ease, without extra API calls or server setup.

In the Netlify dashboard, we navigate to our target site project, select the Form section on the left sidebar, and scroll down to the Form Detection section. Here, we can enable the form detection by clicking the Enable Form detection button.

Once enabled, Netlify is ready to detect and manage our target HTML form during the deployment process. But to fullly use this feature, we need to create the form with the necessary Netlify attributes, which we will do next.

Creating a contact form

In our Nuxt application, let's create a contact.vue page, located in pages/ directory. This page contains an HTML form with the following attributes:

netlify or data-netlify="true" - Netlify detects the target form using this attribute.
data-netlify-honeypot - Netlify uses this attribute to locate a hidden "honeypot" field for spam protection.
name - unique name of the form to appear in the Netlify Form panel.
method - HTTP method to use when submitting the form.
id - The unique identifier for the form.

<form 
  name="contact-form" 
  method="POST"
  netlify
  data-netlify="true" 
  data-netlify-honeypot="bot-field" 
  id="contact-form"
>
  <!-- form fields -->
</form>

For the spam protection, we add a hidden input as the "honeybot" field, which is visible to bots but not for real users. If the field is filled, Netlify will reject the submission. Its name should be identical with the value of data-netlify-honeypot, as shown below:

<div class="hidden">
  <label>
    Don’t fill this out if you’re human: <input name="bot-field" />
  </label>
</div>

And since we are working with static Nuxt site (SSR pre-rendering mode), we need to add an additional hidden input field with the name form-name and the value of the form's name, as follows:

<input type="hidden" name="form-name" value="contact-form" />

Next, we add the actual form fields for the user to fill in:

<div>
  <label for="name" class="label">
    Your Name
  </label>
  <input type="text" name="name" id="name" 
    placeholder="What is your name?" class="field" required />
</div>
<div>
  <label for="email" class="label">
    Your Email
  </label>
  <input type="email" name="email" id="email" 
    placeholder="What is your email?" class="field" required />
</div>
<div>
  <label for="message" class="label">
    Your Message
  </label>
  <textarea rows="4" name="message" id="message" 
    placeholder="What do you want to talk about?" class="field" />
</div>

And some button for submitting and reseting the form when needed:

<div>
  <button type="submit">Send message</button>
  <button type="reset">Clear</button>
</div>

At this point, we have created a simple contact form with the necessary attributes for Netlify Form to detect. Upon a successful form submission, Netlify will redirect the user to a default form's success page. We can override this behavior by giving a custom success page URL with the action attribute in the form element.

Or, we can stop the redirecting mechanism and handle the form submission programatically, which we will do next.

Handling form submission with JavaScript

In our page's script section, we define a handleSubmit method to handle the form submission. We use the fetch API to send the form data as a URL-encoded string using the FormData API, with the content type of "application/x-www-form-urlencoded":

const handleSubmit = async (e) => {
  const form = e.target;
  const formData = new FormData(form);
  try {
    const result = await fetch("/", {
      method: "POST",
      headers: {
        "Content-Type": "application/x-www-form-urlencoded",
      },
      body: new URLSearchParams(formData).toString(),
    });
  } catch (error) {
    console.error(error);
  }
};

To manage the form submission's status, we define the FormState enum and formState variable as follows:

const FormState = {
  IDLE: "IDLE",
  PENDING: "PENDING",
  SUCCESS: "SUCCESS",
  ERROR: "ERROR",
} as const;

const contactFormState = ref<keyof typeof FormState>(FormState.IDLE);

And in the handleSubmit method, we update the state accordingly:

const handleSubmit = async (e: any) => {
  contactFormState.value = FormState.PENDING;
  /**... */
  try {
    /**... */
    if (result.ok) {
      contactFormState.value = FormState.SUCCESS;
    } else {
      contactFormState.value = FormState.ERROR;
    }
  } catch (error) {
    /**... */
    contactFormState.value = FormState.ERROR;
  }
};

We can also reset the form's data once the form is submitted successfully, as shown below:

try {
  /** ... */
  if (result.ok) {
    contactFormState.value = FormState.SUCCESS;
    form.reset();
  }
}

And we reset the form state back to IDLE after a few seconds for re-submission:

try {
  /**... */
} catch (error) {
  /**... */
} finally {
  setTimeout(() => {
    contactFormState.value = FormState.IDLE;
  }, 5000);
}

We then bind the form submission event submit to handleSubmit, with the modifier .prevent for preventDefault(), as follows:

<form
  name="contact-form"
  @submit.prevent="handleSubmit"
>

Finally, we display a custom message to the user based on the form's state as below:

<!--contact.vue-->
<p v-if="formState === FormState.SUCCESS" class="text-green-400 text-center">
  Form has been submitted successfully!
</p>
<p v-else-if="formState === FormState.ERROR" class="text-red-500 text-center">
  Form submission failed. Please try again.
</p>

At this point, our contact page will look similar to the following upon a successful submission:

With that, our app is ready for deployment. However, when we use Nuxt 3 in SSR pre-rendering mode (or static site generating mode), Netlify is sometimes unable to detect and parse the form properly during the build process. We need an additional workaround to make sure that Netlify detects the form.

Let's do it in the next section.

Making sure Netlify detects the form on deployment

To do so, in the public directory, we create an HTML file - contact-duplicate.html - with the form's main HTML code, including all the form fields, and the required attributes for Netlify to use:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Contact Form</title>
</head>
<body>
  <form 
    name="contact-form" 
    method="POST"
    netlify
    data-netlify="true" 
    data-netlify-honeypot="bot-field" 
    id="contact-form"
    class="hidden"
  >
    <!--form fields & buttons-->
  </form>
</body>
</html>

That's it! Nuxt will automatically include this file in the build process, allowing Netlify to detect the form and perform the necessary actions during deployment. Now, when we deploy our site to Netlify for the first time, it will detect the form and add it to the system automatically.

Summary

In this post, we learned how to create and manage a contact form submission using Netlify Form in Nuxt SSR pre-rendering mode. We also learned how to add basic spam protection to the form, handle the form submission programmatically using JavaScript, and display a custom message to the user based on the form's state without redirecting the user.

What's next? How about adding more validations or integrate a third-party service like VeeValidate for better user experience?

👉 Learn about Vue 3 and TypeScript with my new book Learning Vue!

👉 If you'd like to catch up with me sometimes, follow me on X | LinkedIn.

Like this post or find it helpful? Share it 👇🏼 😉