DEV Community: Dylan Britz

Senior vs Junior: Web Developer vs Programmer - More Than Just Coding Skills

Dylan Britz — Tue, 13 May 2025 16:44:06 +0000

Ever wondered about the real differences between web developers and programmers? Or what truly separates a junior from a senior developer? It's not just about years of experience or coding languages—it's about approach, mindset, and how they leverage tools at their disposal.

Web Developer vs Programmer: Understanding the Distinction

While these terms sometimes get used interchangeably, they actually represent different specializations in the tech world.

Web Developers Focus on the Web

Web developers specialize in creating websites and web applications. Their toolkit typically includes:

HTML, CSS, and JavaScript
Frontend frameworks like React.js or Svelte
Backend technologies like Node.js or Laravel
Web-specific protocols and standards

Their primary domain is user-facing interfaces and experiences, though modern web developers often handle complex backend services too. They're the masterminds behind the websites and web apps you use daily.

Programmers Cast a Wider Net

Programmers work across a broader spectrum of platforms and environments. They might be:

Building desktop applications
Developing embedded systems
Creating mobile apps
Writing system utilities
Crafting libraries used by other developers

Their language choices tend to be more diverse: Python, Java, C++, and many others depending on their specific focus.

Junior vs Senior: Beyond Years of Experience

The most fascinating distinction for me between junior and senior developers lies in how they approach tools and dependencies.

The Junior Dependency Approach

Junior developers often rely on packages, libraries, and frameworks because they need to. Without these tools, they might be unable to implement certain functionality.

Their typical approach includes:

Using libraries as a necessity to overcome knowledge gaps
Learning development patterns through integration of pre-built solutions
Focusing on immediate, smaller tasks rather than system architecture
Limited understanding of what's happening "under the hood"

The Senior Strategic Approach

Senior developers use the same tools but with a completely different mindset. They understand that they could build similar functionality themselves but choose not to for strategic reasons:

Time efficiency (why reinvent the wheel?)
Risk reduction (using battle-tested code)
Maintainability benefits (community-supported solutions)
Focus on business-specific challenges

The senior mindset can be summarized as: "I know how to build it myself, but I'm smart enough to know I can save time by using the most mature and applicable library, package, or framework."

When to Build vs When to Borrow

A key skill for any developer is knowing when to use existing solutions and when to create custom ones:

Best Practices for Using External Dependencies

Use established packages for non-core functionality: Authentication, data validation, UI components.
Evaluate dependency risks: Security history, update frequency, community size, long-term support.
Consider integration complexity: Will this save time or create more problems?
Assess performance impact: Does this package meet your performance requirements?

When Custom Solutions Make Sense

Even senior developers will build from scratch when:

The functionality is core to your product's unique value
Existing solutions don't meet specific requirements
Performance is critically important
Long-term maintenance control is necessary

Growing from Junior to Senior

Advice for Juniors

If you're early in your career, here's how to develop a more senior approach:

Study open-source code to understand how the libraries you use are built
Create small-scale versions of common utilities for learning purposes
Understand underlying protocols and standards rather than just their abstractions
Ask "how does this work?" even when you don't need to know for your current task

For Seniors Leading Teams

If you're guiding junior developers:

Explain the reasoning behind dependency choices
Encourage exploration of source code for key dependencies
Share your evaluation process for selecting libraries
Promote contribution to open-source projects

The journey from junior to senior developer—whether web-focused or in broader programming—involves developing a strategic approach to tools and dependencies. Juniors use packages because they must; seniors use them because they've made an informed decision.

"True seniority isn't about knowing how to code everything from scratch—it's about knowing when you should and when you shouldn't. It's this wisdom, beyond technical skills, that marks the evolution of a developer's career."

Master Pre-rendering Dynamic Routes in Nuxt 3 with Nitro

Dylan Britz — Fri, 25 Apr 2025 08:29:02 +0000

Looking to supercharge your Nuxt 3 application with lightning-fast page loads? Pre-rendering (or Static Site Generation) might be exactly what you need. In this guide, I'll dive deep into how you can leverage Nuxt 3 and its Nitro server engine to pre-render dynamic routes like a pro.

Why Pre-rendering Matters

Pre-rendering transforms your dynamic Nuxt app into static HTML files at build time, which means:

⚡ Ultra-fast page loads (CDN-ready!)
🔒 Improved security with fewer server dependencies
💰 Lower hosting costs (static hosting is cheap!)

Understanding Dynamic Routes in Nuxt 3

Before we jump into pre-rendering strategies, let's clarify what dynamic routes are. In Nuxt 3, dynamic pages are created in the /pages directory using bracket syntax:

/pages/blog/[slug].vue  // Creates dynamic routes like /blog/my-post

These routes typically depend on dynamic data (like content from a CMS or database), making them particularly challenging to pre-render.

5 Powerful Ways to Pre-render Dynamic Routes

1. Explicit Route Declaration

The most straightforward approach is manually listing your dynamic routes in the nuxt.config.ts file:

export default defineNuxtConfig({
  nitro: {
    prerender: {
      routes: ["/blog/first-post", "/blog/second-post"],
      ignore: ["/admin"]
    },
  },
})

Best for: Small sites with a limited number of known routes.

2. Dynamic Route Discovery with Lifecycle Hooks

When your routes come from an external data source, automate the process with Nuxt's lifecycle hooks:

export default defineNuxtConfig({
  hooks: {
    async 'prerender:routes'(ctx) {
      const posts = await fetch("https://my-api.com/posts").then(res => res.json());

      // Add each post's URL to the pre-rendering queue
      for (const post of posts) {
        ctx.routes.add(`/blog/${post.slug}`);
      }
    }
  }
})

Alternatively, you can use the nitro:config hook:

export default defineNuxtConfig({
  hooks: {
    async 'nitro:config'(nitroConfig) {
      if (nitroConfig.dev) return;

      const routes = await fetchDynamicRoutes();
      nitroConfig.prerender = nitroConfig.prerender || {};
      nitroConfig.prerender.routes = [
        ...(nitroConfig.prerender.routes || []), 
        ...routes
      ];
    }
  }
});

Best for: Sites with content from APIs, CMS platforms, or databases.

3. Automatic Crawling with `crawlLinks`

Let Nitro discover and pre-render your routes automatically by enabling the crawl feature:

export default defineNuxtConfig({
  nitro: {
    prerender: {
      crawlLinks: true,
      routes: ["/"],
      ignore: ["/api", "/admin"]
    },
  },
})

The crawler starts from your specified routes (like the homepage) and follows all internal links it finds in the HTML.

Best for: Sites with good internal linking and discoverable content.

Pro tip: The crawler won't find routes that are loaded lazily or via JavaScript, so combine this with methods 1 or 2 for comprehensive coverage!

4. Route Rules for Granular Control

Nuxt 3 offers powerful route rules that let you control pre-rendering at a pattern level:

export default defineNuxtConfig({
  routeRules: {
    '/blog/**': { prerender: true },
    '/products/**': { prerender: true },
    '/admin/**': { prerender: false }
  }
});

You can even specify pre-rendering directly in your page components:

<script setup>
defineRouteRules({ prerender: true });
</script>

Best for: Applications with mixed rendering needs (some static, some server-rendered).

5. Programmatic Hints with `prerenderRoutes`

Use the prerenderRoutes utility within your components or scripts to add routes during the build process:

<script setup>
// This will add the route to pre-rendering at build time
prerenderRoutes(['/sitemap.xml', '/products/special-offer']);
</script>

Best for: Adding routes that might be missed by other methods, especially from deeply nested components.

Best Practices for Pre-rendering Success

Combine strategies - Use crawling for discoverable content and explicit routes for everything else.
Verify your build output - After running nuxi generate, check your .output/public directory to ensure all expected HTML files were generated.
Handle data fetching correctly - Make sure your useFetch or useAsyncData calls work both during pre-rendering and on client navigation.
Don't forget about pagination - Explicitly pre-render paginated routes that the crawler might miss.
Monitor build times - Pre-rendering large numbers of pages can significantly increase build times. For very large sites, consider partial pre-rendering of important pages.

Common Pitfalls to Avoid

Crawler limitations: The crawler only finds links in the initial HTML. Routes loaded via AJAX or displayed conditionally might be missed.
API data staleness: Pre-rendered routes reflect data at build time. For frequently changing data, consider server-side rendering instead.
Environment variables: Make sure all required API keys are available during the build process.
Incorrect route patterns: Be careful with your glob patterns in route rules to avoid missing important pages.

Real-world Example: Blog with Categories and Tags

Here's how you might handle pre-rendering for a blog with multiple dynamic route parameters:

// nuxt.config.ts
export default defineNuxtConfig({
  nitro: {
    prerender: {
      crawlLinks: true,
      routes: ["/"]
    },
  },
  hooks: {
    async 'prerender:routes'(ctx) {
      // Fetch all blog posts
      const posts = await fetch("https://my-cms.com/posts").then(res => res.json());

      // Pre-render each individual post
      for (const post of posts) {
        ctx.routes.add(`/blog/${post.slug}`);
      }

      // Pre-render category pages
      const categories = [...new Set(posts.map(post => post.category))];
      for (const category of categories) {
        ctx.routes.add(`/category/${category}`);
      }

      // Pre-render tag pages (with pagination)
      const tags = [...new Set(posts.flatMap(post => post.tags))];
      for (const tag of tags) {
        ctx.routes.add(`/tag/${tag}`);

        // Handle pagination for tags with many posts
        const tagPostCount = posts.filter(p => p.tags.includes(tag)).length;
        const pages = Math.ceil(tagPostCount / 10);

        for (let i = 2; i <= pages; i++) {
          ctx.routes.add(`/tag/${tag}/page/${i}`);
        }
      }
    }
  }
});

Pre-rendering dynamic routes in Nuxt 3 with Nitro gives you the best of both worlds: the development experience of a dynamic application with the performance benefits of static HTML.

Sources:

Explore the 5 Layers of Modern App Infrastructure

Dylan Britz — Mon, 21 Apr 2025 10:23:08 +0000

Ever wondered how modern applications actually work under the hood? Apps like Instagram, Spotify, or even the banking app on your phone aren't just single chunks of code—they're sophisticated systems with multiple layers working together.

Let's break down the five essential layers that make up today's application infrastructure in a way that's easy to understand but still technically valuable.

1. User Interface (UI) Layer: What Users See and Touch

The UI layer is like the storefront of your application—it's what users directly interact with.

User Interface are generally pixels on a screen a GUI (Graphical User Interface), however it could also be a CLI(command line), API. Voice etc.

What it does:

Displays information in a visually appealing way
Captures user inputs (clicks, swipes, form submissions)
Provides feedback to user actions

Popular technologies:

React, Angular, and Vue.js for web interfaces
Flutter and React Native for mobile apps
Tailwind CSS for styling

2. API Layer: The Communication Bridge

Think of the API layer as the waiter in a restaurant—it takes requests from the front (UI), delivers them to the kitchen (backend logic), and brings back what was requested.

Not all applications use APIs (Application Programming Interfaces). Monolithic applications, also known as monolithic architectures, are a type of software design where all components of an application are built together and run in a single executable or as one interconnected unit.

What it does:

Creates standardized ways for different parts of your app to communicate
Shields the frontend from backend complexity
Enables third-party integrations

Popular technologies:

RESTful APIs (the traditional approach)
GraphQL (more flexible, gaining popularity)
gRPC (high-performance, used in microservices)
API gateways like Kong or AWS API Gateway

Pro tips for junior devs:

Always implement proper authentication (OAuth 2.0, JWT)
Document your APIs using Swagger/OpenAPI
Design with versioning in mind—your API will change over time!

3. Logic Layer: The Brains of the Operation

This layer is where the actual "thinking" happens in your application—like calculating prices, validating data, or determining if a user can access a resource.

What it does:

Implements business rules and workflows
Processes data from the UI
Makes decisions based on user inputs and application state

Popular technologies:

Backend frameworks like Django (Python), Spring (Java), or AdonisJs (Node.js)
Serverless functions (AWS Lambda, Azure Functions)
Microservices architectures for complex applications

Pro tips for junior devs:

Start with a simpler monolithic approach until you understand your domain well
Use design patterns like Repository or Factory to keep your code organized
Write unit tests for your business logic—it's the heart of your application!

4. Database Layer: Where Data Lives

The database layer is your application's memory—storing everything from user information to application content.

What it does:

Stores and retrieves data
Ensures data integrity and consistency
Provides efficient data access patterns

Popular technologies:

Relational databases: PostgreSQL, MySQL (great for structured data with relationships)
NoSQL databases: MongoDB, DynamoDB (flexible for rapidly changing data structures)
Caching systems: Redis, Memcached (for performance optimization)

Pro tips for junior devs:

Choose your database based on your data structure needs, not just popularity
Learn about ORMs (Object-Relational Mappers) to interact with databases more easily
Don't underestimate the importance of database indexing for performance

5. Hosting Layer: Where Everything Runs

This final layer provides the actual computing resources that run your application—think of it as the building that houses your business.

What it does:

Provides computing power, storage, and networking
Ensures your application is available 24/7
Scales resources up or down based on demand

Popular technologies:

Cloud platforms: AWS, Azure, Google Cloud
Containerization: Docker, Kubernetes
Infrastructure as Code: Terraform, CloudFormation

Pro tips for junior devs:

Learn the basics of cloud services—they're not going anywhere!
Start with managed services that handle the complexity for you
Explore Infrastructure as Code early—it turns complex server setup into repeatable code

How These Layers Work Together

Let's see how these layers interact in a real-world example:

A user taps "Add to Cart" in an e-commerce app (UI Layer)
The app sends an API request to add the product to the cart (API Layer)
The backend validates the product availability and calculates pricing (Logic Layer)
The updated cart information is saved to the database (Database Layer)
All of this happens on servers running in the cloud (Hosting Layer)

Getting Started

If you're just starting out, here's my advice:

Don't try to learn everything at once. Pick one technology from each layer to focus on.
Build a simple project that uses all five layers. Even a basic todo app can teach you a lot.
Understand the separation of concerns. Keep each layer focused on its responsibility.
Embrace modularity. Build small, testable components that do one thing well.
Learn about automation. CI/CD pipelines and Infrastructure as Code are game-changers.

The beauty of understanding these layers is that while technologies may change rapidly, the fundamental architecture remains fairly consistent. Master these concepts, and you'll have a solid foundation for your development career!

Sources:

How to Run Scheduled Cron Jobs in GitHub Workflows for Free

Dylan Britz — Sun, 20 Apr 2025 10:46:47 +0000

Ever wanted to automate repetitive tasks without paying for a dedicated server? GitHub Actions offers a powerful (and free!) solution for running scheduled tasks also known as cron jobs. Whether you need to sync data, generate reports, or even run a web scraper on schedule, this guide has you covered!

What Are GitHub Actions Scheduled Workflows?

GitHub Actions lets you automate tasks based on various triggers, including time-based schedules using cron syntax. The best part? It's completely free for public repositories, with generous free minute allocations for private repos too.

Setting Up Your First Scheduled Workflow

1. Create or Choose Your Repository

Remember that public repositories have unlimited free minutes, while private repos get around 2000 minutes/month on free plans.

2. Add a Workflow File

Create a new file at .github/workflows/cron-job.yml in your repository.

3. Define Your Schedule Using Cron Syntax

Here's a simple example that runs every day at midnight (UTC):

name: Daily Cron Job

on:
  schedule:
    - cron: '0 0 * * *' # Every day at midnight UTC

jobs:
  run-script:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Run script
        run: echo "Scheduled job ran at $(date -u)"

4. Understanding Cron Syntax

Cron expressions use five fields representing:

Minute (0-59)
Hour (0-23)
Day of Month (1-31)
Month (1-12)
Day of Week (0-6, where Sunday = 0)

Here are some common patterns:

Cron Expression	What It Does
`0 0 * * *`	Every day at midnight UTC
`/5 * * *`	Every five minutes
`0 13 * * 1`	Every Monday at 1:00 PM UTC

Pro tip: Use crontab.guru to test your cron expressions!

Best Practices for GitHub Actions Cron Jobs

Mind the Time Zone

All GitHub Actions schedules run in UTC. Make sure to adjust your schedule accordingly if you need tasks to run at specific local times.

Schedule Strategically

The minimum interval allowed is every 5 minutes (*/5 * * * *)
Avoid scheduling exactly on the hour (0 * * * *) to prevent delays due to high demand
You can set multiple schedules in one workflow to create complex timing patterns

Choose the Right Environment

By default, jobs run on Ubuntu, but you can specify runs-on: windows-latest or macos-latest if your tasks need a specific operating system.

Real-World Example: Scheduled Web Scraper

Want to collect data from a website daily? Here's how to set up a Python web scraper to run every morning:

name: Scheduled Web Scraper

on:
  schedule:
    - cron: '0 6 * * *' # Every day at 6am UTC

jobs:
  scrape:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.x'
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run scraper
        run: python scraper.py

This will run your scraper automatically at 6 AM UTC every day.

Why Choose GitHub Actions Over Alternatives?

Feature	GitHub Actions	Traditional Cron	Cloud Schedulers
Setup	Simple YAML in repo	Requires server access	Cloud configuration
Cost	Free for public repos	Free (but needs a server)	Usually requires payment
Maintenance	Managed by GitHub	Your responsibility	Minimal but requires account
Best for	Code projects, automation	Local tasks	Production systems

Tips

Test your workflows manually before scheduling them to catch any issues
Use GitHub Secrets for storing API keys or sensitive information
Add conditions to make your workflows smarter using the if: syntax
Monitor your usage if you're using private repositories to avoid exceeding free minutes

GitHub Actions scheduled workflows give you a free, flexible way to automate recurring tasks without managing servers or paying for third-party schedulers. Whether you're running maintenance scripts, syncing data, or creating automated reports, these cloud-based cron jobs integrate seamlessly with your existing GitHub workflow.

Have you set up any cool automated workflows with GitHub Actions? What tasks are you planning to automate?

Source:

Mastering Vue 3 Composables Testing with Vitest

Dylan Britz — Sat, 19 Apr 2025 20:30:09 +0000

So you've built some awesome Vue 3 composables that use lifecycle hooks, and now you're scratching your head about how to test them? Don't worry—I've been there too! Testing composables that rely on Vue's lifecycle hooks isn't as straightforward as testing regular JavaScript functions, but with the right approach, it's totally doable.

Let's dive into how to properly test these special composables with Vitest!

Why Testing Lifecycle Hooks Is Tricky

If you've tried something like this:

import { useMyComposable } from './useMyComposable';

test('my composable works', () => {
  const result = useMyComposable();
  // Why aren't my onMounted effects running?! 😱
});

...you probably noticed that your lifecycle hooks never fired. That's because hooks like onMounted and onUnmounted need a Vue component context to work properly.

The Solution: The withSetup Pattern

The key to testing lifecycle-dependent composables is creating a temporary Vue component that can properly trigger those lifecycle events. Here's how to set it up:

// test-utils.js
import { createApp } from 'vue';

export function withSetup(composable) {
  let result;

  // Create a mini Vue app that uses our composable
  const app = createApp({
    setup() {
      result = composable();
      return () => {};
    },
  });

  // Mount it to trigger lifecycle hooks
  app.mount(document.createElement('div'));

  // Return both results and app (for cleanup)
  return [result, app];
}

This helper function:

Creates a tiny Vue app
Executes your composable in its setup function
Mounts the app (triggering onMounted hooks)
Returns both your composable's return values and the app instance (so you can unmount it later)

Let's Write Some Tests!

Here's how to use this pattern with Vitest:

import { withSetup } from './test-utils';
import { useMyComposable } from './useMyComposable';
import { describe, it, expect } from 'vitest';

describe('useMyComposable', () => {
  it('initializes data on mount', () => {
    // The magic happens here!
    const [result, app] = withSetup(() => useMyComposable());

    // Test mounted state
    expect(result.isReady.value).toBe(true);

    // Always clean up by unmounting (this triggers onUnmounted hooks)
    app.unmount();
  });

  it('cleans up resources when unmounted', () => {
    const [result, app] = withSetup(() => useMyComposable());

    // Unmount to trigger the onUnmounted lifecycle hook
    app.unmount();

    // Test that cleanup happened correctly
    expect(result.cleanupRan.value).toBe(true);
  });
});

Real-World Example: Testing a Window Resize Composable

Let's look at a practical example. Imagine you have a composable that tracks window width and cleans up event listeners properly:

// useWindowWidth.js
import { ref, onMounted, onUnmounted } from 'vue';

export function useWindowWidth() {
  const width = ref(window.innerWidth);

  function updateWidth() {
    width.value = window.innerWidth;
  }

  onMounted(() => window.addEventListener('resize', updateWidth));
  onUnmounted(() => window.removeEventListener('resize', updateWidth));

  return { width };
}

Here's how to test it:

import { withSetup } from './test-utils';
import { useWindowWidth } from './useWindowWidth';
import { describe, it, expect } from 'vitest';

describe('useWindowWidth', () => {
  it('tracks window width when resized', () => {
    const [result, app] = withSetup(() => useWindowWidth());

    // Simulate resize event
    window.innerWidth = 800;
    window.dispatchEvent(new Event('resize'));

    expect(result.width.value).toBe(800);

    // Clean up
    app.unmount();
  });
});

Advanced Testing Scenarios

Testing with provide/inject

If your composable uses Vue's dependency injection, you can extend the withSetup helper:

export function withSetupAndProvide(composable, provides = {}) {
  let result;
  const app = createApp({
    setup() {
      // Set up provided values
      Object.entries(provides).forEach(([key, value]) => {
        provide(key, value);
      });

      result = composable();
      return () => {};
    },
  });

  app.mount(document.createElement('div'));
  return [result, app];
}

Testing async operations

For composables with async operations in lifecycle hooks:

it('loads data asynchronously on mount', async () => {
  const [result, app] = withSetup(() => useAsyncData());

  // Wait for async operations to complete
  await flushPromises();

  expect(result.data.value).toEqual({ name: 'Test Data' });
  app.unmount();
});

Best Practices

Always clean up: Call app.unmount() in your tests to trigger onUnmounted hooks
Test the public API: Focus on testing what the composable returns, not internal details
Test side-effect cleanup: Especially important for composables that add event listeners
Keep tests focused: Each test should verify one specific behavior

When to Use Different Testing Approaches

Composable Type	Testing Approach
Pure reactivity only	Direct invocation (no helper needed)
Uses lifecycle hooks	Use withSetup pattern
Uses provide/inject	Use withSetupAndProvide pattern
Has async operations	Use withSetup + await flushPromises()

Now go forth and test those composables with confidence! Your future self (and teammates) will thank you.

Sources:

How to mock and spy on local storage in vitest

Dylan Britz — Fri, 18 Apr 2025 16:50:00 +0000

Today we're diving into a super practical topic that'll level up your testing game: how to properly test code that interacts with localStorage using Vitest.

If you've ever been frustrated trying to test components that use browser storage, this guide is for you.

Why Should You Even Care About Mocking localStorage?

Let's start with the basics. When you're testing code that uses localStorage, you don't want your tests to:

Mess with your actual browser storage (yikes!)
Depend on whatever random data might be in localStorage
Break when running in environments without localStorage (like CI pipelines)

That's where mocking and spying come in! They let you create a fake version of localStorage that you can control completely. Pretty cool, right?

Setting Up Your Test Environment

First things first, you need a browser-like environment in your Vitest setup. Here's how to do that:

// vite.config.js
import { defineConfig } from 'vite';

export default defineConfig({
  test: {
    environment: 'jsdom', // You could also use 'happy-dom'
  },
});

This gives you access to the window object and its localStorage property in your tests.

Option 1: Manual Mocking (DIY Style)

You can create your own localStorage mock from scratch. It looks similar and does the job for testing:

let originalLocalStorage;

beforeAll(() => {
  originalLocalStorage = window.localStorage;
  window.localStorage = {
    store: {},
    getItem(key) {
      return this.store[key] ?? null;
    },
    setItem(key, value) {
      this.store[key] = value;
    },
    removeItem(key) {
      delete this.store[key];
    },
    clear() {
      this.store = {};
    },
  };
});

afterAll(() => {
  window.localStorage = originalLocalStorage;
});

This approach gives you total control, but requires more setup code than some alternatives.

Option 2: Use a Package (The Easy Button)

Why reinvent the wheel? There's a package called vitest-localstorage-mock that does all the heavy lifting for you:

npm install -D vitest-localstorage-mock

Then just tell Vitest to use it:

// vite.config.js
import { defineConfig } from 'vite';

export default defineConfig({
  test: {
    setupFiles: ['vitest-localstorage-mock'],
  },
});

Boom! Now you've got a fully mocked localStorage and sessionStorage with zero effort. This is perfect if you just want things to work without fussing over implementation details.

Spying on localStorage Methods

Now for the really fun part - spying on localStorage to see what your code is doing behind the scenes!

import { vi } from 'vitest';

// Setup the spies
const getItemSpy = vi.spyOn(Storage.prototype, 'getItem');
const setItemSpy = vi.spyOn(Storage.prototype, 'setItem');

// Clean up after each test
afterEach(() => {
  getItemSpy.mockClear();
  setItemSpy.mockClear();
  localStorage.clear();
});

This lets you verify exactly how your code interacts with localStorage:

test('should save user preferences', () => {
  // Run your code that should use localStorage
  saveUserPreferences({ theme: 'dark' });

  // Check if localStorage was called correctly
  expect(setItemSpy).toHaveBeenCalledWith(
    'userPrefs',
    JSON.stringify({ theme: 'dark' })
  );
});

Controlling What localStorage Returns

Sometimes you need to test how your code handles different localStorage scenarios. You can make localStorage return whatever you want:

// Make localStorage.getItem always return this value for any key
getItemSpy.mockReturnValue('fake-user-data');

// Or get more specific with different return values for sequential calls
getItemSpy
  .mockReturnValueOnce('first call')
  .mockReturnValueOnce('second call')
  .mockReturnValue('all other calls');

Real-World Example: Testing a Dark Mode Toggle

Let's put it all together with a practical example - testing a component that saves theme preferences:

import { describe, it, expect, beforeEach, vi, afterEach } from 'vitest';
import { render, fireEvent } from '@testing-library/react';
import ThemeToggle from './ThemeToggle';

describe('ThemeToggle component', () => {
  // Set up our spies
  const getItemSpy = vi.spyOn(Storage.prototype, 'getItem');
  const setItemSpy = vi.spyOn(Storage.prototype, 'setItem');

  beforeEach(() => {
    // Start each test with a clean slate
    localStorage.clear();
    getItemSpy.mockClear();
    setItemSpy.mockClear();
  });

  it('loads saved theme from localStorage on mount', () => {
    // Pretend we have a saved theme
    getItemSpy.mockReturnValue('dark');

    const { getByTestId } = render(<ThemeToggle />);

    // Verify localStorage was checked
    expect(getItemSpy).toHaveBeenCalledWith('theme');

    // Verify the UI shows dark mode is active
    expect(getByTestId('theme-toggle')).toHaveTextContent(
      'Switch to Light Mode'
    );
  });

  it('saves theme to localStorage when toggled', () => {
    const { getByTestId } = render(<ThemeToggle />);

    // Click the toggle button
    fireEvent.click(getByTestId('theme-toggle'));

    // Verify localStorage was updated
    expect(setItemSpy).toHaveBeenCalledWith('theme', 'dark');
  });
});

Pro Tips for Better Tests

Always clean up after each test using afterEach. This prevents test bleeding where one test affects another.
Reset your spies before or after each test with mockClear() to start fresh.
Be specific in your assertions - don't just check if a method was called, check it was called with the right arguments.
When possible, assert both the method calls AND the actual effects of those calls (like checking DOM updates).

Choosing the Right Approach

Here's a quick decision guide:

Need something quick and reliable? Use the vitest-localstorage-mock package.
Want more control or have unusual requirements? Create a manual mock.
Need to verify how your code uses localStorage? Add spies with vi.spyOn.
Testing edge cases? Control return values with mockReturnValue or mockReturnValueOnce.

Wrapping Up

Testing localStorage doesn't have to be a headache! With these techniques, you can write tests that are:

Isolated from the real browser environment
Predictable and consistent
Able to verify exactly how your code interacts with storage

So go forth and test that localStorage code like a pro! 💪

Sources:

Mastering API Testing with Mocking in TypeScript: An Intro to Mock Service Worker

Dylan Britz — Sat, 12 Apr 2025 23:49:38 +0000

Hey fellow developers! 👋 If you’re diving into the front-end world and struggling with API testing, you’re about to discover your new best friend: Mock Service Worker (MSW). Trust me, this library is a game-changer for TypeScript projects!

What’s the Deal with API Mocking ?

When building front-end applications, we’re constantly hitting APIs — but what happens when those APIs aren’t ready? Or when you need to test error states? That’s where mocking comes in!

Mock Service Worker stands out from traditional mocking solutions by intercepting actual network requests right at the browser or Node.js level. No more complicated setup or maintaining separate mock servers!

Why MSW Will Make Your Life Easier

Here’s why you should be excited about MSW:

Works seamlessly in any environment - browser, Node.js, or testing frameworks
Intercepts actual network requests giving you realistic testing scenarios
Plays perfectly with TypeScript
Reuse the same mocks everywhere

Getting Started with MSW

Let’s set up MSW in your project with these simple steps:

Install the package

npm install msw --save-dev

Create your mock handlers First, make a directory for your mocks:

mkdir src/mocks
touch src/mocks/handlers.ts

Then define your API mocks in the handlers file:

import { rest } from 'msw';

export const handlers = [
  rest.get('/api/user', (req, res, ctx) => {
    return res(
      ctx.status(200),
      ctx.json({
        id: 1,
        username: 'john_doe',
        email: 'john@example.com',
      })
    );
  }),
];

Set up the service worker Create a browser setup file:

// src/mocks/browser.ts
import { setupWorker } from 'msw';
import { handlers } from './handlers';

export const worker = setupWorker(...handlers);
Then activate it in your app’s entry point:

// src/index.tsx
if (process.env.NODE_ENV === 'development') {
  const { worker } = require('./mocks/browser');
  worker.start();
}

For testing environments If you’re using Jest or another testing framework:

// src/mocks/server.ts
import { setupServer } from 'msw/node';
import { handlers } from './handlers';

export const server = setupServer(...handlers);

In your test setup:

// setupTests.ts
import { server } from './mocks/server';

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

Level Up Your Mocking Game with TypeScript

One of the coolest things about MSW is how it leverages TypeScript’s power. Check this out:

import { rest } from 'msw';
import { User } from './types'; // Your User interface

export const handlers = [
  rest.get<{}, {}, User>('/api/user', (req, res, ctx) => {
    return res(
      ctx.json({
        id: 2,
        username: 'jane_doe',
        email: 'jane@example.com',
      })
    );
  }),
];

Now your mocks are type-checked against your actual interfaces! No more mismatched data structures causing bugs at runtime.

Pro Tips for MSW Success

Here are some tips I’ve learned from using MSW in production:

Mock different response states — Success, errors, loading states — test them all!

// Error state mock 
rest.get('/api/users', (req, res, ctx) => {
  return res(
    ctx.status(500),
    ctx.json({ message: 'Internal server error' })
  );
})

Organize your mocks by feature and Keep related endpoints together for better maintainability
Combine MSW with Storybook to create component stories with realistic data flows
Empty arrays, weird data formats, network timeouts — simulate it all!
Keep your mocks close to your real API. The more realistic your mocks, the more valuable your tests

MSW vs. Traditional Mocking: Why MSW Wins

I’ve tried many mocking solutions, and here’s why MSW stands out:

Traditional Mocking	Mock Service Worker
Complex setup with local servers	Simple configuration
Limited to specific environments	Works everywhere
Mocks often feel disconnected from reality	Simulates actual network behavior
Requires different approaches for different contexts	Reuse mocks across all environments
Often lacks TypeScript integration	Fully type-safe

No more flaky API calls!

Implementing MSW in your TypeScript projects will change how you approach development and testing. You’ll build more robust applications, catch bugs earlier, and spend less time wrestling with backend dependencies.

Start small mock just one endpoint and see the difference it makes in your workflow. Then gradually expand your mocks as you get comfortable with the approach.

Have you tried MSW or other mocking solutions? What challenges are you facing with API testing? Drop your thoughts in the comments, and let’s discuss.

Happy coding! 🚀

DEV Community: Dylan Britz

Senior vs Junior: Web Developer vs Programmer - More Than Just Coding Skills

Web Developer vs Programmer: Understanding the Distinction

Web Developers Focus on the Web

Programmers Cast a Wider Net

Junior vs Senior: Beyond Years of Experience

The Junior Dependency Approach

The Senior Strategic Approach

When to Build vs When to Borrow

Best Practices for Using External Dependencies

When Custom Solutions Make Sense

Growing from Junior to Senior

Advice for Juniors

For Seniors Leading Teams

Master Pre-rendering Dynamic Routes in Nuxt 3 with Nitro

Why Pre-rendering Matters

Understanding Dynamic Routes in Nuxt 3

5 Powerful Ways to Pre-render Dynamic Routes

1. Explicit Route Declaration

2. Dynamic Route Discovery with Lifecycle Hooks

3. Automatic Crawling with crawlLinks

4. Route Rules for Granular Control

5. Programmatic Hints with prerenderRoutes

Best Practices for Pre-rendering Success

Common Pitfalls to Avoid

Real-world Example: Blog with Categories and Tags

Explore the 5 Layers of Modern App Infrastructure

1. User Interface (UI) Layer: What Users See and Touch

2. API Layer: The Communication Bridge

3. Logic Layer: The Brains of the Operation

4. Database Layer: Where Data Lives

5. Hosting Layer: Where Everything Runs

How These Layers Work Together

Getting Started

How to Run Scheduled Cron Jobs in GitHub Workflows for Free

What Are GitHub Actions Scheduled Workflows?

Setting Up Your First Scheduled Workflow

1. Create or Choose Your Repository

2. Add a Workflow File

3. Define Your Schedule Using Cron Syntax

4. Understanding Cron Syntax

Best Practices for GitHub Actions Cron Jobs

Mind the Time Zone

Schedule Strategically

Choose the Right Environment

Real-World Example: Scheduled Web Scraper

Why Choose GitHub Actions Over Alternatives?

Tips

Have you set up any cool automated workflows with GitHub Actions? What tasks are you planning to automate?

Mastering Vue 3 Composables Testing with Vitest

Why Testing Lifecycle Hooks Is Tricky

The Solution: The withSetup Pattern

Let's Write Some Tests!

Real-World Example: Testing a Window Resize Composable

Advanced Testing Scenarios

Testing with provide/inject

Testing async operations

Best Practices

When to Use Different Testing Approaches

Now go forth and test those composables with confidence! Your future self (and teammates) will thank you.

How to mock and spy on local storage in vitest

Why Should You Even Care About Mocking localStorage?

Setting Up Your Test Environment

Option 1: Manual Mocking (DIY Style)

Option 2: Use a Package (The Easy Button)

Spying on localStorage Methods

Controlling What localStorage Returns

Real-World Example: Testing a Dark Mode Toggle

Pro Tips for Better Tests

Choosing the Right Approach

Wrapping Up

Mastering API Testing with Mocking in TypeScript: An Intro to Mock Service Worker

What’s the Deal with API Mocking ?

Why MSW Will Make Your Life Easier

Getting Started with MSW

Level Up Your Mocking Game with TypeScript

Pro Tips for MSW Success

MSW vs. Traditional Mocking: Why MSW Wins

No more flaky API calls!

3. Automatic Crawling with `crawlLinks`

5. Programmatic Hints with `prerenderRoutes`