Forem: Maya Shavin 🌷☕️🏡

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 👇🏼 😉

Build a smart product data generator from image with GPT-4o and Langchain

Maya Shavin 🌷☕️🏡 — Tue, 25 Jun 2024 05:34:10 +0000

When listing new products to an online store, owners or marketers often find it too time-consuming to fill in the essential information such as title, description, and tags for each product from scratch. Most of the information can be retrieved from the product image itself. With the right combination of LLM and AI tools, such as Langchain and OpenAI, we can automate the process of writing product's information using an input of image, which is our focus in today's post.

Table of contents
Brief introduction about Langchain and OpenAI
- Setting up Langchain and OpenAI
The flow of generating product data
Step 1: Load an product image into base64 format
Step 2: Ask GPT to generate a product's metadata
- Setting up OpenAI API key
- Creating a model to process the image and prompt
Step 3: Extract the result from GPT in a structured Product format
- Define the Product structure
- Create a function to extract the product information
Chaining all the steps together using Langchain
Resources
Summary

Brief introduction about Langchain and OpenAI

Langchain is a powerful tool that allows you to architect and run AI-powered functions with ease. It provides a simple interface to integrate with different LLMs (Large-Language-Models) APIs and services such as OpenAI, Hugging Face, etc. It also offers an extensible architecture that allows you to create and manage custom chains (pipelines), agents, and workflows tailored to your specific needs.

OpenAI is a leading AI research lab that has developed several powerful LLMs, including GPT-3, GPT-4 and Dall-E. These models can generate human-like text and media based on the input prompt, making them ideal for a wide range of applications, from chatbots to content/image generation.

Setting up Langchain and OpenAI

In this post, we will use GPT-4o model from OpenAI for better image anayzing and text completion, along with the following Langchain Python packages:

langchain-openai - A package that provides a simple interface to interact with OpenAI API.
langchain_core - The core package of Langchain that provides the necessary tools to build your AI functions.

To install these packages, you use the following command:

python -m pip install langchain-openai langchain-core

Next, let's define the flow of how we generate product information based on a given image.

The flow of generating product data

Our tool will perform the following steps upon receiving an image URL from the user:

Load the given product image into base64 data URI text format.
Ask GPT to analyze and generate the required product's metadata based on such data.
Extract the result from GPT in a structured Product format.

The below diagram demonstrates how the our work flow looks like:

With this flow in mind, let's walk through each step's implementation in detail.

Step 1: Load an product image into base64 format

Before we can ask GPT to generate a product's metadata from a given image URL, we need to convert it into a format that GPT can understand, which is base64 data URI. To do so, we will create an image.py with the following code:

import base64

def encode_image(image_path):
  with open(image_path, "rb") as image_file:
    return base64.b64encode(image_file.read()).decode('utf-8')

The above encode_function function takes an image_path, opens and reads the image into bytes format, and then returns the encoded based64 text version.

We then write a load_image function, which performs the following:

Receives inputs as a dictionary, which contains an image_path key with the path to the image file,
Reads inputs[image_path] into base64 format using base64.b64encode() method.
Assigns the result to image property of the returned object for the function.

The code is as follows:

def load_image(inputs: dict) -> dict:
    """Load image from file and encode it as base64."""
    image_file = inputs["image_path"]
    image_base64 = encode_image(image_file)
    return {
        "image": image_base64
    }

Now we have the image processing step implemented. Next, we will create a function to communicate with GPT for the information desired based on this image data.

Step 2: Ask GPT to generate a product's metadata

In this step, since we are going to send request to GPT API, we need to set up its API's key for related Langchain OpenAI package to pick up and initialize the service.

Setting up OpenAI API key

The most straighforward way is to create an .env file with an OPENAI_API_KEY variable, whose value can be found under Settings panel, as shown below:

OPENAI_API_KEY=your-open-ai-api-key

Then, we install python-dotenv package using the below command:

python -m pip install python-dotenv

And in our generate.py file, we add the following code to load the key from the .env file into our project for usage:

import os
from dotenv import load_dotenv

load_dotenv()

And with that, we can implement the function that will invoke the GPT model for answers.

Creating a model to process the image and prompt

In generate.py, we create a function image_model that takes inputs as a dictionary containing the fields: image and prompt, where image is the base64 data URI from step 1.

def image_model(inputs: dict):
 """Invoke model with image and prompt."""

    image = inputs["image"]
    prompt = inputs["prompt"]

From the given inputs, we compute a user's message to pass to the model. To do so, we use HumanMessage class from langchain_core.messages package:

message = HumanMessage(
    content=[
        {"type": "text", "text": prompt},
        {
            "type": "image_url", 
            "image_url": {
                "url": f"data:image/jpeg;base64,{ image }"
            }
        },
    ]
)

In the above code, we pass to HumanMessage an array of content containing:

A text object with the prompt text
An image_url object with the base64-encoded image data as the URL

Once we have the message ready, we then initialize a model instance of ChatOpenAI using gpt-4o, an 0.5 temperature and a maximum number of 1024 tokens:

from langchain_openai import ChatOpenAI

def image_model(inputs: dict):
 """Invoke model with image and prompt."""

    #... previous code
    model = ChatOpenAI(temperature=0.5, model="gpt-4o", max_tokens=1024)

And invoke the model with the message and return the content of the response, as follows:

def image_model(inputs: dict):
 #... previous code
 result = model.invoke(message)
 return result.content

At this stage, we have the content of the response from GPT. In the next step, we will extract that content in a structured Product format.

Step 3: Extract the result from GPT in a structured Product format

The response from GPT is always in a text format, which requires us to parse and extract the relevant information in a structured Product format. This is not a straightforward step. Fortunately, Langchain provides us several tools to help us with this task, starting with defining the output structure format.

Define the Product structure

We will define a Product class as a Pydantic model using BaseModel and Field from the langchain.pydantic_v1 package, as shown below:

# Product.py
from langchain_core.pydantic_v1 import BaseModel, Field

class Product(BaseModel):
    '''Product description'''
    title: str = Field(..., title="Product Title", description="Title of the product")
    description: str = Field(..., title="Product Description", description="Description of the product")
    tags: list = Field([], title="Product Tags", description="Tags for SEO")

The above class defines a Product model with the following fields:

title - The title of the product
description - The description of the product
tags - The tags for SEO

Next, we declare a parser function that will extract the GPT response into the Product structure.

Create a function to extract the product information

We can use JsonOutputParser class to create a custom parser by passing our Product structure as its pydantic_object, as follows:

from langchain_core.output_parsers import JsonOutputParser

#... previous code
parser = JsonOutputParser(pydantic_object=Product)

Great. All left is to modify our content array in Step 2 to include the parser's format instructions, by adding the following element to the array:

content = [
    #... previous code
    {"type": "text", "text": parser.get_format_instructions()},
    {
        "type": "image_url", 
       # ... code
    },
]

And with that, all the components for the flow is ready. It's time to chain them together.

Chaining all the steps together using Langchain

Chaining is similar to a train of action carriage, where each carriage can be a step of LLM call, data transformation, or any tool connected together, supporting streaming, async and batch processing out of the box. In our case, we will use TransformChain for transforming our image_path input into a proper base64 data input as a pre-processing step of the main flow.

from langchain.chains import TransformChain

load_image_chain = TransformChain(
    input_variables=['image_path'],
    output_variables=["image"],
    transform=load_image
)

From there, we create another generate_product_chain that chains all the flow components together using | operator, starting with loading and transforming the image path into a base64 data URI text, then passing its output as the input to our image model for generating the desired data, and finally parsing the result into our target Product format:

generate_product_chain = load_image_chain | image_model | parser

Finally, we define get_product_info function to invoke the chain with the initial input image_path and prompt as follows:

def get_product_info(image_path: str) -> dict:
generate_product_chain = load_image_chain | image_model | parser

prompt = f"""
   Given the image of a product, provide the following information:
   - Product Title
   - Product Description
   - At least 13 Product Tags for SEO purposes
"""

return generate_product_chain.invoke({
    'image_path': image_path, 
    'prompt': prompt
})

And that's it! We have successfully built a smart product information generator. You can now use the get_product_info function to generate product information by giving it a valid image path:

product_info = get_product_info("path/to/image.jpg")
print(product_info)

Resources

Summary

In this post, we have explored how to generate essential product data such as title, description and tags based on a given image using Langchain, Open AI GPT-4o. We have walked through the flow, including loading an image into base64 text format, asking GPT to generate a product's metadata, and extracting the result from GPT in a structured Product format. We have also seen how to chain all the steps together using Langchain to create a working product information generator.

In the next post, we will explore how to deploy this tool as a web service API using Flask. Until then, 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 👇🏼 😉