Forem: Robert Marshall

Wispr Flow + Claude Transforms Content Creation

Robert Marshall — Fri, 29 Aug 2025 09:24:58 +0000

This article was originally posted (and is more up to date) at https://robertmarshall.dev/blog/wispr-flow-claude-transforms-content-creation/

I kept hitting the same frustration every time I wanted to write about a technical project. I’d have this complex implementation in my head – all the edge cases, the gotchas, the lessons learned – but getting it from brain to readable article felt like translating between languages.

So I’d procrastinate, jot down a few bullet points, then let the idea sit for weeks.

The process was brutally slow – building content over weeks, adding bits here and there, tweaking and tailoring incrementally. It was subconscious-led rather than stream-of-thought-led.

Then I discovered Wispr Flow + Claude, and everything changed.

The Numbers Don’t Lie

Here’s the baseline math: Average typing speed is 40 words per minute. Average speaking speed is 125-150 words per minute. That’s a 3-4x speed increase just on raw output.

But the real multiplier is even higher because of the cognitive load difference. When you’re typing, you’re constantly self-editing and hesitating. When you’re speaking, you can just flow.

But this isn’t really about typing versus talking. It’s about completely changing how we approach technical content creation.

The Breakthrough Moment

My aha moment came when I was using Wispr Flow with Claude for coding. I found myself speaking to the terminal, getting functionality specs out of my head, talking through features and edge cases (I wrote about this here, if you are interested: Turning Claude Code into a Development Powerhouse).

I could think out loud and flow with ideas. It was far quicker to get information out of my head than typing ever was.

What this meant was I could build comprehensive functionality specs for code just by talking – before I even touched the keyboard. The only keys I touched were Ctrl+Windows (to trigger Wispr).

It hit me that this was a natural fit. Since I’m already living in Markdown files and writing mostly about development work – how I solved problems, why certain tools work well – the same approach should work for article creation.

This Isn’t Actually New (But It’s Better)

Photo from National Museum of American History

Let’s be honest here – people have been recording their thoughts since the 1860s with the Phonautograph. And then the Dictaphone came along. The only difference was other humans would then write up dictations. That cognitive load, that time taken to write things down, was just passed on to another human.

We got decent speech-to-text in the 1990s/2000s. But AI allows for far more increased speed and there’s less human requirement. I don’t need to hire someone to write down my ramblings. It can go straight to screen and then can use AI to tidy it up.

What has changed the game for me is the combination: immediate voice capture + intelligent clean-up and organization.

The Writing Problem

You know this pain: you understand a concept deeply, but getting it out of your head and into a shape that another human can follow can be tricky. The blank page problem is real. You know what you want to say but organizing it feels impossible.

This is where the voice-first approach shines. You can just start talking about the problem you’re trying to solve. Go around the houses a little bit. Mention edge cases as they occur to you. The AI will help sort it out later.

My Current Workflow

Here’s exactly how I do this now:

1. Minimal mental prep : Just thinking “Is this a subject I want to cover? Can it be helpful?” I don’t fully plan out the article anymore.

2. Voice dump : I spit ball the idea to Claude (via Wispr Flow) and monologue about what I want to talk about. I go around the houses, mention tangents, explore different angles.

3. AI interview : Here’s the key – I ask Claude to interview me. “Here’s the initial thing we’re trying to discuss, can you help me dig in?” Claude returns 3-4 questions that I can see on screen and work through systematically.

4. Iterative exploration : I can direct the questions or say “I’ve had a thought, let’s talk about this angle.” We dig deep and go heavy, knowing we can pull it back once we’ve got all the context out.

5. Technical additions : Once I’ve got all the conversation down, I manually add any code examples, snippets, or links. I want to make sure the code is correct – you can’t just ask AI to generate technical examples and trust them blindly.

6. AI clean-up with oversight : I ask Claude to summarize, but then I take both the original context and the summary and run through a few iterations: “Is there anything we’ve missed? Is there anything that could enhance this direction?”

Human refinement : I come back days or weeks later with fresh eyes and tweak for flow, personality, and accuracy.

Why The Interview Format Works

Having Claude interview you breaks down content blocks that you might get, especially first thing in the morning when you need a prompt to get moving. You start with a generalized outline, then as questions come: “Oh, well what about this? Well, no that’s not what I want. What about this? Yeah, that’s the right direction.”

The ability to keep being poked along – “What are your thoughts on this? What about that?” – really maintains flow. You probably could get there solo, but it would take much more time.

In conversation, you can flip-flop back and forth, whereas when I write, it tends to be very structured, one trail of thought. Talking allows far more natural self-critique and counter-arguments in a fluid way. If there’s an additional thought tied to the last thought, you can briefly touch on it, then come back to the first thought. By getting it out of your brain and into Claude, you haven’t lost it.

The AI Clean-up Balance

Here’s the critical warning: if you use Claude too much, if you take all your context and meandering thoughts and ask Claude to just summarize everything, Claude can be very aggressive with how it reduces that information. You can end up with a very lobotomized article that could otherwise be far more human.

What I do is ask for summaries, but then cross-reference with the original context. “Is there anything we’ve missed? Is there anything that could enhance this direction?” But you need to drive it – if you let Claude drive completely, you lose your personality and style.

Everyone has their own way of telling stories, their own pauses, their own mannerisms. If you’re too Claude-ified, it will remove your personality, and readers can tell the difference between a good writer working with AI and a fully AI piece of content.

Content Type Considerations

This approach works brilliantly for technical documentation, development articles, and explanatory content. As long as you can get everything out of your head initially, it’s not necessarily limited by content type.

Where you need to hold back on AI involvement is when you start shaping that raw material into something specific. For creative writing like stories, this wouldn’t work well. But for technical documentation – especially dry documentation about processes – having an AI-driven clean-up process might actually be beneficial because you’re dealing with if-statements and cause-and-effect rather than emotions and emotional conversation.

Quality Control for Technical Content

When you’re explaining complex technical concepts, developers can’t afford inaccuracies in their documentation. Here’s my quality control process:

Human verification : You still need to read everything back and tweak it. Mistakes happen even in human writing – your first draft needs editing regardless of how you created it.
Manual code verification : Add code snippets and examples manually after the AI clean-up. If you’re explaining how to do something with code, you need to ensure what you’re sharing is 100% correct and verified by yourself.
Responsible writing balance : There’s a clear line between what AI can do (organize thoughts, improve flow) and what you should do (verify technical accuracy, maintain authenticity).

Getting Started: The Minimum Viable Experiment

If you are sceptical about adding AI to your writing workflow, here’s a small experiment you can run:

Install Wispr Flow (free plan available) – wisprflow.ai
Open Claude (free plan available) – claude.ai
Try this prompt : “I want to write a technical article about [TOPIC]. Can you interview me to help me explore all the angles and get my thoughts organized? Start with broad questions about the problem I’m solving, then dig into implementation details and lessons learned.”
Just start talking into Wispr about your topic for 5-10 minutes
Let Claude interview you based on what you said
See what happens

You could even start by just typing your article title into Claude and asking for an interview. It’s a good jump-off point that requires zero additional tools.

The Meta-Validation

This entire article was created using exactly this process. I started with a rough idea about wanting to write about Wispr Flow + Claude. I talked through my thoughts, Claude interviewed me about different angles, and we built up layers through conversation.

You can see the process working in real-time: I discovered connections as I spoke (like connecting tangential speech to better self-critique), ideas got more sophisticated with each response, and we built enough raw material for a substantial article just through conversational exploration.

We literally demonstrated the “getting more context out upfront” principle while creating content about that exact principle.

The Real Game Changer

This isn’t just about speed, though the 3-4x output increase is significant. It’s about changing how you think about technical writing from a painful, time-consuming process to something that flows naturally from your existing knowledge.

Instead of staring at a blank page wondering how to structure complex ideas, you can just start talking about the problem you solved. The structure emerges from the conversation. The AI helps with organization and clean-up, but the insights, the personality, the technical accuracy – that’s still all you.

The cognitive load of writing is distributed across the right tools: your brain for insights and technical knowledge, your voice for natural expression, AI for organization, and your editing skills for final refinement and accuracy.

It’s not about replacing human creativity or expertise. It’s about removing friction from the process of sharing that expertise with others.

Why My Gatsby to Next JS Migration Failed (And What It Taught Me About AI Workflows)

Robert Marshall — Thu, 14 Aug 2025 12:32:52 +0000

I recently tried to publish an article on this blog, and got hit with a number of Cloudflare errors. All stemming from the fact that I had forgotten that I have created the website with Gatsby many years ago.

In past freelance jobs I have migrated, fixed, cleaned up and patched numerous Gatsby websites. It was painful and unforgiving. Not about to do that again… (especially as is a dead framework – development has essentially stopped and the ecosystem is stagnant).

The plan was to migrate the project away. But I am crazy busy with paid work, so a manual migration was not on the cards.

Claude Code is a pretty solid tool in the toolbox for me, so why not see if it can handle the whole thing…

The “Obvious” Approach

My initial instinct was straightforward: write one prompt, outline the migration approach, break the work down into stages, use MD files to handle memory, and hope the sub agents could keep up.

Arguably this is a small website, so there shouldn’t be too much needed… and I am using some pretty powerful tools within Claude Code.

The Tools

Context7 – Pulls in live documentation and context for third-party libraries

Serena – Semantic code search and editing across the entire codebase

Sequential Thinking – Structured reasoning for complex decision making

I wrote a piece about this stack here, if you want more information on how it sits together.

The Prompt

The key was being explicit about the workflow and delegation:

/go
You are looking at an old Gatsby JS project. Your job is to upgrade it to a Next JS App Router project. Some of the components will be able to be left as they are, due to being react. However some will need to be migrated to the Next way of doing things.
The first task is to use 1 subagent to look over the whole project and find a list of files that need to be updated. Once done it should save the list of files into a "migrate.md" file.
Once done, one agent should look over the "migrate.md" file and work out of there is any extra work needed. i.e. util functions, or underlaying Next JS code needed that multiple pages will use. This should be added to the top of the list with brief comment on how they should be used
Once done, these files outlined in at the top of the migrate.md file should be split between 2 sub agents, and should be created.
Once done, rest of the files outlined in the "migrate.md" file should be split between 4-6 sub agents. They should then handle the needed migration. Working through each file one by one.

What Actually Happened

Claude replied with a solid plan in plan mode. It had correctly identified the WordPress headless CMS setup, mapped out the key Gatsby-specific pieces that needed replacing, and understood the dependency chain. The breakdown looked promising – it planned to tackle foundational infrastructure first, then components, then pages.

45 minutes of Claude chuntering away. Divining, and pontificating.

Watching its thinking process and the suggestions it was making (I had it set to automatically execute everything), it seemed like it had its head in the game.

Unfortunately, not so much.

Where It All Went Wrong

Here’s the problem: Gatsby’s complexity isn’t just in its components – it’s in all the custom resolvers, data transformation layers, and vendor-specific abstractions you need to make anything work. When Claude tried to “migrate” this mess, it didn’t simplify it. It recreated the complexity in Next.js.

Claude built a whole collection of systems that sort of did the job, but made everything incredibly heavy. Multiple data fetching layers, complex resolvers that weren’t needed in Next.js, and abstractions on top of abstractions.

In terms of migrating the components and styling – very very happy. This got everything off to the races. But the underlying architecture was a mess.

The Real Problem: I Asked Claude to Solve the Wrong Thing

After about 4 hours of trying to clean up the convoluted migration, I had a realization: I had asked Claude to migrate the wrong thing.

Instead of asking it to “upgrade this Gatsby project to Next.js,” I should have asked it to “help me build a clean Next.js foundation, then help me move specific pieces over.”

The Better Approach: Foundation First

Here’s what I ended up doing, and what I should have done from the start:

Step 1: Clean Slate Foundation

npx create-next-app@latest my-new-blog --typescript --tailwind --eslint --app

Then prompted Claude specifically: “Create a clean Next.js blog architecture with WordPress as a headless CMS. Focus on modern best practices, simple data fetching, and clear separation of concerns.”

Step 2: WordPress Data Layer Foundation

Before touching any components, I needed a solid data layer. I prompted Claude: “Create a lib/wordpress module that handles all WordPress API interactions. Include functions for fetching posts, categories, and individual post data. Set up proper caching with Next.js’s built-in cache, and create a revalidation webhook for when new posts are published.”

This gave me clean, focused utilities like:

getAllPosts() with ISR caching
getPostBySlug() with proper error handling
getCategories() for navigation
Webhook endpoint for WordPress to trigger revalidation

Having this foundation meant every subsequent component could use clean, Next.js-native data fetching instead of trying to recreate Gatsby’s complex GraphQL layer.

Step 3: Component Migration

With both the Next.js foundation and WordPress data layer in place, I could then ask Claude to migrate specific components one by one: “Take this Gatsby component and adapt it for Next.js App Router, using our WordPress utilities.”

Step 4: Integration & Testing

Finally: “Wire up these converted components with our WordPress data layer and test the full flow.”

What This Taught Me About AI Workflows

The failure revealed something crucial about working with AI on complex tasks:

AI excels when it has a clear mental model of the target state. When I asked Claude to migrate Gatsby to Next.js, it had to hold both architectures in its head simultaneously while trying to bridge them. When I gave it a clean Next.js project and asked it to add specific functionality, it had a single, clear target to work towards.

Prompt decomposition isn’t just about breaking tasks down – it’s about choosing the right problems to solve. My original prompt was well-structured but fundamentally asked for the wrong thing.

Foundation-first development works better with AI than migration-first. Starting with npx create-next-app gives Claude a proper mental model and established patterns to work with.

The Broader Lesson

This experience changed how I approach complex AI-assisted development tasks. Instead of asking “How do I get from A to B?” I now ask “How do I build B properly, then move the best parts of A over?”

It’s not just about AI either. How many times have we all spent weeks trying to upgrade or migrate legacy code when starting fresh would have been faster and cleaner?

The Outcome

After restarting with the foundation-first approach, the migration took about 4 hours total (including the cleanup time from my first attempt). The resulting codebase is clean, follows Next.js best practices, and actually performs better than the original Gatsby site.

And this is the website you’re reading now.

The key insight: Claude didn’t fail at the migration – I failed at defining the right problem to solve. Sometimes the best migration strategy is to not migrate at all.

Turning Claude Code into a Development Powerhouse

Robert Marshall — Tue, 05 Aug 2025 12:14:04 +0000

This article was originally posted (and is more up to date) at https://robertmarshall.dev/blog/turning-claude-code-into-a-development-powerhouse/

I've been using Claude Code for months now, and while it's solid, I kept hitting the same frustration: context switching hell.

Claude would write decent code, but it was like working with a brilliant intern who'd never seen your codebase before. Then I discovered Model Context Protocols (MCPs) and everything changed.

Not just "this is neat" - more like "ok, this is how AI coding should work". The real magic happens when you combine the right MCPs with proper prompting strategy.

The Problem: AI with Amnesia

You're deep in a project, need to add authentication, and ask Claude for help. It spits out some generic OAuth implementation that completely ignores:

The auth patterns you're already using elsewhere
The latest changes in the library you're working with
The architectural decisions your team made months ago

So you spend 20 minutes explaining context, then another 10 fixing the outdated API calls, then realize you're basically doing the work yourself anyway.

The Solution: The MCP Stack

After experimenting with different combinations, I landed on four tools that work together like a well-oiled machine:

Context7: Your Live Documentation Oracle

https://context7.com/

What it does: Pulls in real-time documentation for any third-party library

Why it matters: No more "wait, is this the old API?" moments

claude mcp add --transport sse context7 https://mcp.context7.com/sse

Context7 is basically having the maintainer of every library sitting next to you.

Serena: Your Semantic Code Archaeologist

https://github.com/oraios/serena

What it does: Semantic search and editing across your entire codebase

Why it matters: Finds patterns by intent, not just text matching

claude mcp add serena -- uvx --from git+https://github.com/oraios/serena serena start-mcp-server --context ide-assistant --project $(pwd)

This is where things get interesting. Serena doesn't just grep your code - it understands what your code does. Ask it "where do we handle user authentication?" and it'll find all the relevant pieces, even if they don't share the same variable names.

Sequential Thinking: Your AI Architect

https://www.npmjs.com/package/@modelcontextprotocol/server-sequential-thinking

What it does: Structured reasoning for complex technical decisions

Why it matters: Breaks down hairy problems into logical, debuggable steps

claude mcp add sequential-thinking -s local -- npx -y @modelcontextprotocol/server-sequential-thinking

Sequential Thinking is like having a senior architect who actually thinks before coding.

Should you refactor or rebuild? What are the dependencies? What could go wrong? It maps out the decision tree so you can see the reasoning.

Some people I spoken to say this is no longer needs as Claude does this internally. I currently don't agree (update pending), and this has helped break down problems numerous times.

WisprFlow: Your Voice-to-Code Pipeline

https://wisprflow.ai/

What it does: Real-time transcription that's better than anything else out there

Why it matters: Talk directly to Claude instead of typing out complex requirements Arguably, this is not a MCP. But it ties them all up together very nicely.

This is the game-changer for speed. Rather than typing out the scope, I can talk directly to Claude. This increase in speed means faster iterations on code, and scope out different angles in the planning phase before jumping into the code.

Far more context and useful information for the AI to work with.

And Then the Slash

The breakthrough came when I created this slash command:

Always use:

- serena for semantic code retrieval and editing tools
- context7 for up to date documentation on third party code
- sequential thinking for any decision making

Read the claude.md root file before you do anything.

#$ARGUMENTS

Before adding any prompt, now type "/go". As in: /go add a [feature spec here]

Real-World Example: Building Auth from Scratch

Let me show you how this actually works. Last week I needed to add OAuth to an existing Next.js app. Here's what happened:

The Old Way (30 minutes):

Ask Claude for OAuth implementation
Get generic code that doesn't match our patterns
Explain our auth architecture
Fix outdated API references
Adapt to our component structure
Debug integration issues

The New Way (8 minutes):

Sequential Thinking mapped out the requirements and dependencies
Serena found our existing auth patterns and user management code
Context7 pulled the latest NextAuth.js documentation
Claude synthesized a complete implementation that fit perfectly

The difference isn't just speed - it's quality. The new implementation followed our existing patterns, used current best practices, and integrated seamlessly.

The Compound Effect

Here's what I've noticed after a month of using this setup:

Time savings: 60-70% reduction on complex features
Quality improvements: Fewer bugs, better patterns, consistent architecture
Mental overhead: Way less context switching and "wait, how did we do this before?"

But the biggest win? I'm not babysitting the AI anymore. I can give it complex, multi-step tasks and trust it to figure out the details.

But Create a Scope...

The reason why I included WisprFlow in the stack, is that AI is not a point and shoot - one button press approach.

To make sure that the code you are writing is decent quality and structured correctly (not 20 new utility functions that were added for no reason, plus some weird transform) you need to give the machine a property documented plan.

By talking through what you want to achieve with Claude Code in plan mode, you can get everything out of your head. Then you can read it back. Tweak it until the scope is bang on, and then break it into sections.

Break it up yourself. Like you would if you are planning out an actual project. What gives you less of a headache also gives AI less of a headache.

Spend the time upfront. Then let the stack take it away.

How to Use Hookdeck.com to Test and Debug Webhooks

Robert Marshall — Sat, 02 Aug 2025 07:27:13 +0000

With the introduction of more easily accessible no-code tools like N8N, webhooks have become a "must-have" when deciding which service to choose. But then you have to test what they return! This piece aims to help with that.

What Is a Webhook and How Does It Work?
Real-World Webhook Examples
- FormBear
- Stripe
- GitHub
Testing Webhooks with Hookdeck: Step-by-Step
- Step 1: Set Up Your Hookdeck Project
- Step 2: Create an Event Source
- Step 3: Get Your Webhook URL
- Step 4: Send Test Webhooks
- Step 5: Monitor and Debug
Advanced Hookdeck Features
Conclusion

Webhooks are the backbone of modern web applications, enabling real-time communication between services. But testing and debugging them can be a nightmare, especially when you're dealing with third-party services, local development environments, or unreliable network connections.

What Is a Webhook and How Does It Work?

A webhook is essentially a "reverse API call" - instead of your application polling another service for updates, the external service pushes data to your application when something interesting happens. Think of it like this: instead of constantly asking "Are we there yet?" on a road trip, webhooks are like getting a text message when you arrive at your destination. Here's the typical webhook flow:

Setup: You provide a webhook URL to an external service
Event occurs: Something happens in the external service (user signs up, payment processed, form submitted)
Notification: The service sends an HTTP POST request to your webhook URL with event data
Processing: Your application receives and processes the webhook payload

This real-time communication pattern is crucial for building responsive applications that need to react immediately to external events.

Real-World Webhook Examples

Let's look at some common webhook use cases that you'll encounter as a developer:

FormBear

FormBear is a modern form management platform that sends webhooks whenever forms are submitted. This is perfect for triggering automated workflows like:

Sending welcome emails to new subscribers
Creating leads in your CRM
Triggering Slack notifications for support requests
Updating analytics dashboards in real-time

When a user submits a FormBear form, you'll receive a webhook payload like this:

{
  "id": "b8bf41bf-d634-41e1-bad2-a50754045215",
  "data": {
    "fields": {
      "name": "Sarah Johnson",
      "email": "sarah@example.com",
      "message": "I'd love to learn more about your services!"
    },
    "submission_id": "sub_1753966250344"
  },
  "form": {
    "id": "contact-form-123",
    "name": "Contact Form"
  },
  "event": "form.submitted",
  "metadata": {
    "ip_address": "192.168.1.100",
    "user_agent": "Mozilla/5.0...",
    "submitted_at": "2025-01-15T14:30:45.344Z"
  }
}

Stripe

Stripe is the gold standard for payment processing, and their webhooks are crucial for building reliable payment flows. Stripe sends webhooks for dozens of different events, but some of the most important ones include: Payment Events:

invoice.payment_succeeded - A payment was successfully processed
invoice.payment_failed - A payment attempt failed
payment_intent.succeeded - One-time payment completed successfully

Subscription Events:

customer.subscription.created - New subscription started
customer.subscription.updated - Subscription plan changed
customer.subscription.deleted - Subscription canceled

Customer Events:

customer.created - New customer account created
customer.updated - Customer information changed

Here's a real example of an invoice.payment_succeeded webhook that Stripe would send when a customer successfully pays their subscription:

{
  "object": {
    "id": "in_1Rql02frY8V0rQXKfgb",
    "object": "invoice",
    "account_name": "Your Stripe Account",
    "amount_due": 4900,
    "amount_paid": 4900,
    "amount_remaining": 0,
    "billing_reason": "subscription_create",
    "currency": "gbp",
    "customer": "cus_Sm48uvqLyN",
    "customer_email": "hello@yourdomain.dev",
    "status": "paid",
    "lines": {
      "data": [
        {
          "id": "il_1RqlrYQCM8ViOeXS",
          "amount": 4900,
          "currency": "gbp",
          "description": "1 × Pro (at £49.00 / month)",
          "period": {
            "end": 1756603816,
            "start": 1753925416
          }
        }
      ]
    },
    "hosted_invoice_url": "https://invoice.stripe.com/i/acct_1RqLqYQCM8V0/test_...",
    "invoice_pdf": "https://pay.stripe.com/invoice/acct_1RqLqXQCM8V0/test_.../pdf"
  }
}

This webhook tells you that customer hello@yourdomain.dev just successfully paid £49.00 for a Pro subscription. In your application, you might use this to:

Upgrade the user's account to Pro features immediately
Send a confirmation email with the invoice PDF link
Update your analytics to track monthly recurring revenue
Sync with your CRM to mark the customer as an active subscriber
Grant access to premium features or content

The beauty of Stripe webhooks is their reliability - even if your server is down when the payment processes, Stripe will keep retrying the webhook delivery.

GitHub

GitHub webhooks are the backbone of modern DevOps workflows, automatically triggering actions when code changes occur. The most common webhook is the push event, which fires whenever commits are pushed to a repository. The push webhook is incredibly detailed, containing information about:

What changed: Before/after commit SHAs and the full diff
Who made the change: Author and pusher information
Where it happened: Repository, branch, and organization details
Commit details: All commits in the push (up to 2048 commits)

Here's what a typical push webhook payload looks like when someone pushes new code:

{
  "ref": "refs/heads/main",
  "before": "6113728f27ae82b1a177c8d03f9e96edf246",
  "after": "0d1a26e67d8f5e1f6ba5c57fc3c71ac0fd1c",
  "created": false,
  "deleted": false,
  "forced": false,
  "base_ref": null,
  "compare": "https://github.com/octocat/Hello-World/compare/6113728f27ae...0d1a26e67d8f",
  "commits": [
    {
      "id": "0d1a26e67d8f5eaf1f6ba5c57fc3c7d91ac0fd1c",
      "tree_id": "f9d2a07e9488b91af2641b26b9407fe22a451433",
      "message": "Fix user authentication bug",
      "author": {
        "name": "Sarah Johnson",
        "email": "sarah@example.com",
        "username": "sarahj"
      },
      "url": "https://github.com/octocat/Hello-World/commit/0d1a26e67d8f5eaf1f6ba5c57fc3c7d91ac0fd1c",
      "added": ["src/auth.js"],
      "removed": [],
      "modified": ["README.md", "package.json"]
    }
  ],
  "head_commit": {
    "id": "0d1a26e67d8f5eaf1f6ba5c57fc3c7d91ac0fd1c",
    "message": "Fix user authentication bug",
    "author": {
      "name": "Sarah Johnson",
      "email": "sarah@example.com"
    }
  },
  "repository": {
    "id": 1296269,
    "name": "Hello-World",
    "full_name": "octocat/Hello-World",
    "html_url": "https://github.com/octocat/Hello-World",
    "default_branch": "main"
  },
  "pusher": {
    "name": "sarahj",
    "email": "sarah@example.com"
  }
}

This webhook tells you that Sarah Johnson just pushed a commit to the main branch that:

Fixed a user authentication bug
Added a new src/auth.js file
Modified the README and package.json files

In practice, you'd use this webhook to:

Trigger CI/CD pipelines: Automatically run tests, build the app, and deploy to staging
Update project management: Create deployment tickets or update issue status
Send notifications: Alert the team in Slack about new deployments
Run security scans: Automatically scan new code for vulnerabilities
Update documentation: Regenerate API docs or deployment guides

The beauty of GitHub's webhook system is that it gives you enough detail to make intelligent decisions about what actions to take based on the specific changes.

Testing Webhooks with Hookdeck: Step-by-Step

Let's walk through setting up Hookdeck to test webhooks from FormBear (you can apply these same steps to any webhook provider).

Step 1: Set Up Your Hookdeck Project

Navigate to hookdeck.com and create a free account. You'll land on the getting started page where you can create your first connection. The interface is clean and intuitive - you'll see options to create connections for routing events through Hookdeck's infrastructure.

Step 2: Create an Event Source

Click "Create a connection" to set up your first webhook source. You'll need to:

Choose Source Type: Select "Webhook" since we're receiving HTTP requests from FormBear
Name Your Source: Use a descriptive name like "formbear-prod" or "contact-form-webhooks"
Configure Authentication: Leave this disabled for now (you can add signature verification later)

The source represents the producer of your webhooks - in this case, FormBear's form submission events.

Step 3: Get Your Webhook URL

Once you create the source, Hookdeck generates a unique URL for receiving webhooks. It will look something like:

https://hkdk.events/x31mwm3dg0tje9

This URL is what you'll provide to FormBear (or any other service) to start receiving webhooks. Copy this URL - you'll need it in the next step.

Step 4: Send Test Webhooks

Now let's configure FormBear to send webhooks to your Hookdeck URL:

Log into FormBear: Navigate to your FormBear dashboard
Go to Webhooks: Click on the "Webhooks" section in the sidebar
Create New Webhook: Click "Create Webhook" or similar button
Configure the Webhook:
- URL: Paste your Hookdeck URL
- Events: Select "form.submitted" and any other events you want to monitor
- Name: Give it a descriptive name like "Hookdeck Test"
Test the Webhook: Use FormBear's built-in test feature to send a sample webhook

You'll need a FormBear account to follow along exactly, but you can use any webhook-enabled service or even send manual POST requests with curl to test the same concepts.

Step 5: Monitor and Debug

Return to your Hookdeck dashboard and you should see the webhook request appear in your "Requests" view. Hookdeck provides detailed information about each request:

Request Details: Method, headers, query parameters
Payload: Full JSON body with syntax highlighting
Response: Status codes and response bodies
Timing: Request duration and retry attempts
Routing: Which destinations received the webhook

You can click on any request to see complete details, making debugging much easier than parsing server logs.

Migrating from query-string to URLSearchParams

Robert Marshall — Sat, 19 Aug 2023 12:27:13 +0000

This article was originally posted (and is more up to date) at https://robertmarshall.dev/blog/migrating-from-query-string-to-urlsearchparams/

In my quest to remove as many third-party packages as possible from mine and my clients websites, I have been working through each package and checking if there is a native replacement.

query-string is a super useful package for parsing URL parameters, but it now has a native replacement, URLSearchParams. It can be used both in node and the browser.

One of the reasons to remove query-string is because of the continual error:

npm WARN deprecated querystring. The querystring API is considered Legacy. new code should use the URLSearchParams API instead.

The following functions should help with removing this package from your codebase.

Stringify URL Params with URLSearchParams

I previously used query-string to take an object of arrays, and turn into a comma separated URL. The commas within the URL were not encoded.

This turned out to be a little bit trickier with URLSearchParams.

What used to be:

queryString.stringify(params, {
    arrayFormat: 'comma',
})

Is now a bit longer:

export const stringifyParams = (params) => {
    // Set up a new URLSearchParams object.
    const searchParams = new URLSearchParams()

    // Loop through the params object and append each key/value
    // pair to the URLSearchParams object.
    for (const [key, value] of Object.entries(params)) {
        searchParams.append(key, value)

        // If a key does not have a value, delete it.
        if (!searchParams.get(key)) {
            searchParams.delete(key)
        }
    }

    // Convert the URLSearchParams object to a string.
    const searchParamsString = searchParams.toString()

    // Replace the encoded commas with commas.
    const decodedSearchParamsString = searchParamsString.replace(/%2C/g, ',')

    return decodedSearchParamsString
}

Parsing with URLStringParams

Parsing turned out to be a little easier.

What used to be:

queryString.parse(location.search, { arrayFormat: 'comma' })

Is now the following:

export const parseParams = (string) => {
    // Set up a new URLSearchParams object using the string.
    const params = new URLSearchParams(string)

    // Get an iterator for the URLSearchParams object.
    const entries = params.entries()

    const result = {}

    // Loop through the URLSearchParams object and add each key/value
    for (const [key, value] of entries) {
        // Split comma-separated values into an array.
        if (value.includes(',')) {
            result[key] = value.split(',')
        } else {
            result[key] = [value]
        }

        // If a key does not have a value, delete it.
        if (!value) {
            delete result[key]
        }
    }

    return result
}

These functions can be added to a util file within your JS project and imported when needed.

Hopefully this helped you, and if you have any questions you can reach me at: @robertmars

On-Click Lazy Load YouTube Video Iframe in React

Robert Marshall — Mon, 07 Aug 2023 14:18:21 +0000

This article was originally posted (and is more up to date) at https://robertmarshall.dev/blog/on-click-lazy-load-video-iframe-in-react/

Videos are heavy. And the JavaScript that is used in the video player is also heavy.

Speed matters on a website (you know this, its why you are here). And with most videos the JS for the player is generally not needed as soon as the page has loaded. In fact the only time the user needs the video player to be loaded is when they want to watch the it. I.E. At the point that the video is clicked.

I wrote a short piece on loading YouTube videos in React on scroll. However it didn’t consider waiting for the click – what if the video is above the fold? Or the user never watches the video?

Why load it if they don’t need it. Web.dev wrote an article on using loading=”lazy” with iframes which slightly helps – but some JS is still loaded.

The best result would be to have nothing but a compressed poster image shown until the user wants to watch the video. No matter if it is above or below the fold.

In this piece I will walk through how to defer an iframes load (and its contents) until a user had clicked a button.

TLDR

Render an image with the same ratio as the video iframe (YouTube, Vimeo etc) inside a button. When the button is clicked inject an iframe with the video which auto plays.

Take a look at this CodeSandbox for a working example of how to load a YouTube video on click in React.

YouTube Without Improvements

YouTubes embed code with no alterations looks like this:

<iframe
    title="YouTube video player"
    src="https://www.youtube.com/embed/NY76mkzJT6o"
    width="1280"
    height="720"
    frameborder="0"
    allowfullscreen="allowfullscreen"
></iframe>

This music video by Fwar, a good friend of mine. If you like it you can find more of his music on Spotify.

This is fairly heavy. Lets work out what is needed to make this YouTube video lighter.

Requirements

The solution to this would look like:

Only a thumbnail is shown and loaded initially.
Thumbnail image should use browser lazy loading.
YouTube video iframe is deferred until user clicks thumbnail.
There is no flicker between thumbnail being removed and YouTube video showing
The video should play as soon as it had loaded.

Implementing the Solution

Firstly lets create a button and thumbnail to replace the iframe. This should be the same ratio as a YouTube video.

Also, lets use the YouTube play button icon to show the user they can interact with the button.

<button
  className={thumbnailButton}
  onClick={() => {
    startTransition(() => {
      setShowVideo(true);
    });
  }}
>
  <div className={videoInner}>
    <img
      alt="Fwar - Mushrooms video thumbnail"
      src="https://i.ytimg.com/vi/NY76mkzJT6o/maxresdefault.jpg"
      className={thumbnailImage}
      loading="lazy"
    />
    <img
      alt="Play Video"
      src="https://upload.wikimedia.org/wikipedia/commons/b/b8/YouTube_play_button_icon_%282013%E2%80%932017%29.svg"
      loading="lazy"
      className={playIcon}
    />
  </div>
</button>

Now lets add the classes needed for this section. This is where the ratio comes in. A little bit of padding magic!

For complete transparency, this is SCSS – it makes life a little easier. Take a look at the example to see how this fits together.

.container {
  max-width: 500px;
  padding: 10px;
}

.videoRatio {
  overflow: hidden;
  padding: 56.25% 0 0 0;
  position: relative;
  width: 100%;
}

.videoInner {
  bottom: 0;
  height: 100%;
  left: 0;
  position: absolute;
  right: 0;
  top: 0;
  width: 100%;
}

.thumbnailButton {
  @extend .videoInner;
  background-color: transparent;
  border: 0;
  cursor: pointer;
  display: block;
  margin: 0;
  padding: 0;
  text-decoration: none;
}

.thumbnailImage {
  width: 100%;
}

.playIcon {
  height: 42px;
  left: calc(50% - 30px);
  position: absolute;
  top: calc(50% - 21px);
  transition: all 0.3s ease-in-out;
  width: 60px;
}

Now this is set up, a new component is needed to hold the video. YouTube does have an API that can be used to handle autoplaying: https://developers.google.com/youtube/iframe_api_reference.

This is not used within this example as it seemed overkill. Instead lets use a package that wraps this API in a React component called react-youtube.

import YouTube from "react-youtube";
import { videoInner } from "./style.module.scss";

const Player = ({ setHasLoaded, videoId }) => {
  // Once the YouTube package (react-youtube) has loaded
  // tell the thumbnail it is no longer needed.
  // Play the video.
  const _onReady = (event) => {
    setHasLoaded(true);
    event.target.playVideo();
  };

  return (
    <YouTube
      videoId={videoId}
      onReady={_onReady}
      className={videoInner}
      iframeClassName={videoInner}
    />
  );
};

export default Player;

And that is it! See this CodeSandbox for the full working example! Hopefully this helped you, and if you have any questions you can reach me at: @robertmars

Lazy Loading Videos on Scroll with Vanilla JS and Intersection Observers

Robert Marshall — Fri, 04 Aug 2023 11:59:04 +0000

This article was originally posted (and is more up to date) at https://robertmarshall.dev/blog/lazy-loading-videos-on-scroll-with-vanilla-js-and-intersection-observers/

As frontend developers, we often encounter the challenge of optimizing website performance. One powerful technique to achieve this is lazy loading.

Lazy loading allows us to load assets, such as images or videos, only when they are needed, reducing initial page load times and conserving bandwidth.

I have written pieces on using React and Lazy Loading, but sometimes Vanilla JS is needed.

In this article, we’ll focus on lazy loading videos using the Intersection Observer API. By leveraging this built-in browser feature, we can efficiently detect when videos come into the user’s viewport and load them on demand.

TLDR

Take a look at this CodeSandbox for a working example of how to load a video on scroll.

_ Update _

I recently wrote a piece on deferring the video until a user clicks. This is a more effective solution than waiting until scroll. It is about YouTube but could be refactored to work with most providers.

robertmarshall.dev/blog/on-click-lazy-load-video-iframe-in-react/

Setting up the HTML Structure

Before we delve into the JavaScript code, let’s understand the HTML structure we’ll be working with.

In the example, we’ll have multiple video elements, each representing a different video to be loaded on scroll.

<div>
  <div
    data-video-url="https://player.vimeo.com/video/588259728?h=09704145bb&dnt=1&app_id=122963&autoplay=1&muted=1"
    data-video-title="This is an iframe title"
    class="video-wrap"
    style="
      overflow: hidden;
      padding-top: 56.25%;
      position: relative;
      width: 100%;
    "
  ></div>
  <div
    data-video-url="https://player.vimeo.com/video/588259728?h=09704145bb&dnt=1&app_id=122963&autoplay=1&muted=1"
    class="video-wrap"
    style="
      overflow: hidden;
      padding-top: 56.25%;
      position: relative;
      width: 100%;
    "
  ></div>
</div>

Each div element contains styling to ensure the video’s correct aspect ratio and prevent page jumps when the video finally loads. The first div includes data-video-url and data-video-title attributes, which we will later grab to inject into the iframe.

Section 2: The Intersection Observer API

Now to cover the Intersection Observer API. This is a built-in browser feature that allows us to observe changes in the intersection of elements with a viewport or a specific container.

The Intersection Observer is perfect for our lazy loading implementation because it can detect when a video element comes into view, signalling the browser to load the video.

Section 3: The JavaScript Implementation

First, we need to wait for the DOM to be fully loaded before starting our JavaScript implementation. We’ll use the DOMContentLoaded event to ensure our script runs at the right time.

if (document.readyState !== "loading") {
  initVimeo();
} else {
  document.addEventListener("DOMContentLoaded", initVimeo);
}

Next, let’s define the initVimeo() function, which will be the starting point of the lazy loading implementation. It will use the querySelectorAll method to select all video elements with the data-video-url attribute.

function initVimeo() {
  const videoWraps = document.querySelectorAll(".video-wrap[data-video-url]");
  // More code will be added here later
}

Section 4: Implementing Lazy Loading

Inside the initVimeo() function the Intersection Observer will check when each video element comes into view. If it’s the first time the element is visible (not yet loaded), it will to load the video dynamically.

function initVimeo() {
  const videoWraps = document.querySelectorAll(".video-wrap[data-video-url]");
  const videoStateMap = new Map();

  const observer = new IntersectionObserver((entries) => {
    entries.forEach(({ target, isIntersecting }) => {
      if (isIntersecting && !videoStateMap.get(target)) {
        const videoUrl = target.getAttribute("data-video-url");
        const videoTitle = target.getAttribute("data-video-title");

        const iframe = document.createElement("iframe");
        iframe.src = videoUrl;
        iframe.frameBorder = "0";
        iframe.allow = "autoplay; fullscreen; picture-in-picture";
        iframe.allowfullscreen = "";

        if (videoTitle) {
          iframe.title = videoTitle;
        }

        iframe.style = "position: absolute; inset: 0; width: 100%; height: 100%";

        target.appendChild(iframe);

        videoStateMap.set(target, true);
      }
    });
  });

  videoWraps.forEach((videoWrap) => {
    videoStateMap.set(videoWrap, false);
    observer.observe(videoWrap);
  });
}

By leveraging the Intersection Observer API, we’ve successfully implemented lazy loading for videos, ensuring they load only when they are about to be displayed on the user’s screen. This optimization results in faster page load times and a smoother user experience.

To see a working version of this code, take a look at the Code Sandbox.

You can find me on Twitter if you have any questions.

Using Gravity Forms with Headless WordPress and Next JS

Robert Marshall — Thu, 03 Aug 2023 10:02:50 +0000

This article was originally posted (and is more up to date) at https://robertmarshall.dev/blog/using-gravity-forms-with-headless-wordpress-and-next-js/

This article covers Next JS 13 with the app directory. That said, it could easily be ported to the pages structure.

It is possible to set up Gravity Forms yourself. Either creating the queries and mutations needed using WpGraphql. Passing data back to Gravity Forms using either native fetch or Apollo. If you aren’t a fan of GraphQL, you might want to use the built in GF Rest API.

However, why reinvent the wheel.

This article aims to introduce a far cleaner, simpler way of using Gravity Forms with Next JS. It will provide a step by step walkthrough of what is needed, as well as provide an example git repository so you can copy/paste.

TLDR

Get WordPress ready
- Install Gravity Forms
- Install wp-graphql
- Install wp-graphql-gravity-forms
Add next-gravity-forms to your Next JS project.
Example repo with solution: https://github.com/robmarshall/next-gravity-forms-example

What Packages Do I Need?
- WordPress
- Next JS
Step 1 – Setup WordPress
Step 2 – Add Form Packages to Next JS
- Add Package
- Environment Variables
Step 3 – Using the Package Within Your Project
- Getting Gravity Form Data from WordPress to Next JS
Add Google reCaptcha to the Form
Styling the Next Gravity Forms Package

What Packages Do I Need?

We will use the following packages:

WordPress

Next JS

next-gravity-forms

Step 1 – Setup WordPress

The first step is to get the WordPress site set up. This is pretty painless (much like the whole process TBH).

The below exposes your Gravity Forms forms using GraphQL, so the frontend (Next) can get the form shape, and pass back user submissions.

Install and Activate Gravity Forms (get a license here if you need one)
Install & activate WPGraphQL on your WordPress site – This can be installed from the plugin directory on your WordPress backend.
Download zip from the wp-graphql-gravity-forms repository (download latest release as a zip from here) and upload it to your WordPress install. Then activate the plugin.

Step 2 – Add Form Packages to Next JS

Add Package

Now add Next Gravity Forms to your project.

# Use Yarn
yarn add next-gravity-forms

# Or NPM
npm i next-gravity-forms

Environment Variable

Now add the environment variable needed. Next-gravity-forms grabs this and uses it to send back user submissions.

NEXT_PUBLIC_WORDPRESS_API_URL=YOUR_ENDPOINT

Note

If your WordPress GraphQL data is passed through a cache like Stellate (if its not, I recommend them!), set NEXT_PUBLIC_WORDPRESS_API_URL with the cache URL, and add a secondary environment variable – NEXT_PUBLIC_WORDPRESS_FORM_SUBMIT_URL – to handle submissions.

This means you can still take advantage of any caching you may have set up, and bypass this when wanting to submit data. E.G.

NEXT_PUBLIC_WORDPRESS_API_URL=YOUR_CACHED_ENDPOINT
NEXT_PUBLIC_WORDPRESS_FORM_SUBMIT_URL=YOUR_DIRECT_ENDPOINT

Step 3 – Using the Package Within Your Project

Create Frontend Form Component

Next create a component for the client side code to live in.

This is because the form component itself contains React Hook Forms, a client side library. It needs wrapping in:

use client

The component will look something like this:

"use client";

import GravityFormForm from "next-gravity-forms";

const GravityForm = ({ form }) => <GravityFormForm data={form} />;

export default GravityForm;

Example in repository: https://github.com/robmarshall/next-gravity-forms-example/blob/main/components/GravityForm.js

Get Gravity Forms Data from WordPress into Next JS

Getting a Single Form

If you know the ID of the specific form you want to render, the setup is fairly simple.

import { getGravityForm } from "next-gravity-forms/server";
import GravityForm from "components/GravityForm";

export default async function Page() {
  const form = await getGravityForm(1);

  return <GravityForm form={form} />;
}

Note

getGravityForm is a server side function, it does not run on the client side. Make sure to only use it within a Server Component or within an API route.

Rendering Forms Dynamically

This is a little more complicated (but not massively). The complexity is introduced by the fact that we want to dynamically pick a form to render on the client side. But can only retrieve the specific form data on the server side.

This is solved by getting all forms (or a subset of them, if you only want to pick from X number of forms) and passing this collecting of data to the frontend.

Once the frontend has the form data, the specific forms data can be passed to the GravityFormForm component when needed.

Take a look at the dynamic example within the repository to see how this works.

Add Google reCaptcha to the Form

The next-gravity-forms package is built so that reCaptcha “just works”.

The only thing to check is that the reCaptcha details have been added to the Gravity Forms settings on the WordPress side.

Take a look at the Gravity Forms help article for more info: https://www.gravityforms.com/blog/add-recaptcha-to-your-forms/

Styling the Next Gravity Forms Package

There is no default styling currently packaged in with the next-gravity-forms package. This means that you will need to handle all the styling yourself.

The GravityFormForm component uses exactly the same CSS classes as the PHP Gravity Forms HTML. This means you can move your styling from a pre-existing WordPress site to Gatsby very easily. It doesn’t include support for CSS-in-JS/styled components yet.

There is baseline styling CSS file included in the example repo. This should get you to a point where you can see the form working.

Example form styling

Example repo with solution if you missed it in the article: https://github.com/robmarshall/next-gravity-forms-example

Hopefully this article has helped, and if you have any questions you can reach me at: @robertmars

How To Permanently Redirect (301, 308) with Next JS

Robert Marshall — Wed, 02 Aug 2023 10:24:04 +0000

This article was originally posted (and is more up to date) at https://robertmarshall.dev/blog/how-to-permanently-redirect-301-308-with-next-js/

I recently worked on migrating a large content heavy site from pure WordPress to a headless WordPress and Next JS set up. During this change it was decided that a base URL for a blog section needed changing.

The URL structure was to change from:

“domain.com/ articles /content-piece”

“domain.com/ blog /content-piece”.

For 500+ pieces of content.

To make sure that all the old link juice was not lost, each one of these old links needed to be 301 redirected to the new URL structure.

On previous sites I have used .htaccess (oh, PHP) or handled redirects on the host level (Cloudflare pages make this super easy). But this time I wanted to keep everything internal, as Next JS has the tools to handle it.

What is a 301 Redirect? Why is it Important?

A 301 redirect is a code sent by the web server to the browser, telling it that the URL in question has been permanently moved to another URL. Google will also use this to re-write all of their indexing to the new pages, and pass the ranking power (or link juice) across to the new page.

A 301 redirect should be used when a page (or pages) has been moved or removed from a website.

An easy way to think about a 301 redirect is to think about when you move house. If you do not tell the postal service what your new address is and set up a re-direct, you will not get post that is set to your old address. Telling the postal service about your new address is the same as a 301.

Hang on, Next JS Uses a 308 not 301

This initially concerned me a little. Why would Next JS use a different status code?

Well this is due to how browsers moved the goal posts. As the Next JS docs say:

Traditionally a 302 was used for a temporary redirect, and a 301 for a permanent redirect, but many browsers changed the request method of the redirect to GET, regardless of the original method. For example, if the browser made a request to POST /v1/users which returned status code 302 with location /v2/users, the subsequent request might be GET /v2/users instead of the expected POST /v2/users. Next.js uses the 307 temporary redirect, and 308 permanent redirect status codes to explicitly preserve the request method used.

In essence, a 308 is more reliable.

So does Google treat a 308 the same as a 301? Is this going to cause issues for search indexing? No, this will not cause any issues. Google’s Search Advocate John Mueller, has said that 308 redirects are treated in the same way as 301 by Google crawlers. Here is his tweet about it.

How to Set up a Permanent Redirect in Next JS

Next JS is essential a React App bundled up with a number of other third party packages, and other really helpful internal functions. Some of these packages and functions help with the speediness of the site. Others handle how a user is able to navigate around the site with different URLs.

A lot of Next.js magic comes from the next.config.js file. Here you can set up any number of options, but the one we care about it the redirects function.

module.exports = {
    // All the other config options you may have...
    async redirects() {
        return [
            {
                // What the user typed in the browser
                source: '/articles/:path*',
                // Where the user will be redirected to
                destination: '/blog/:path*',
                // If the destination is a permanent redirect (308)
                permanent: true
            }
        ];
    }
};

The above object shows setting the source value to “article” with a catch all of any URL after the initial string. It then sets the destination using the same logic.

Using the :path* is known within Next JS as Wildcard Path Matching. For example /blog/:slug* will match /blog/a/b/c/d/content-piece.

Finally permanent is set to true. This tells Next JS that the redirection should be sent with a status code of 308. If this is set to false then it sends a 307 (traditionally this would have been 302, but Next JS changed this due to the reasoning outlined above).

Hopefully this helped you, and if you have any questions you can reach me at: @robertmars

How to Fix Issues With CSS Position Sticky Not Working

Robert Marshall — Sat, 26 Nov 2022 11:54:03 +0000

This article was originally posted (and is more up to date) at https://robertmarshall.dev/blog/solution-to-why-css-position-sticky-is-not-working/

An issue that took far longer than it should have to solve.

I was using the CSS position: sticky on my header so it moved down as the user scrolled. However when I added the mobile menu which transitioned in from the right, the sticky header broke. Could not understand why!

Turns out sticky does not play nicely with most overflow values.

If you are trying to use position: sticky and it is not working, it is because one of the elements wrapping it is using overflow with a value of hidden, auto or scroll.

How to solve the sticky problem?

There is a new (ish) value that can be used with overflow. It is clip.

As Mozilla puts it in their documentation:

Similar to hidden, the content is clipped to the element’s padding box. The difference between clip and hidden is that the clip keyword also forbids all scrolling, including programmatic scrolling. The box is not a scroll container, and does not start a new formatting context. If you wish to start a new formatting context, you can use display: flow-root to do so.

Is Clip Supported on all modern browsers.

At time of writing (23/11/2022) all current versions of modern browsers support this functionality. Take a look atCan I Use if you want to check for yourself.

Use Yoast Sitemap with Next JS and Headless WordPress

Robert Marshall — Mon, 07 Nov 2022 13:17:12 +0000

This article was originally posted (and is more up to date) at https://robertmarshall.dev/blog/use-yoast-sitemap-with-next-js-and-headless-wordpress/

There are many perfectly valid ways of creating sitemaps for Next JS. Especially when using WordPress as a headless CMS.

You could generate the XML yourself by grabbing all the URLs yourself with custom code. You could use a plugin like next-sitemap to do the hard work for you.

These are both good options. But only if you are not wanting to use ISR, and are happy to rebuild the whole site on each content change.

TLDR

Create a lightweight proxy that grabs the Yoast sitemap data, point them to your Next JS domain, and rewrite any internal URLS to that same domain. Solution here.

The Problem (brief)
- Rebuild the whole site with SSG
- Run a pre-build script
The Solution
- How to use Yoast Sitemap with Next JS
- Creating a Proxy

The Problem (brief)

Myself and the clients I work with tend to build sites that are very content heavy, and with lots of images. As well as this, content gets published regularly. We also need the sitemap to be updated after each publish, edit or deletion of content.

This can be managed in a number of ways. We could:

Rebuild the whole site with SSG

Rebuild the whole site using SSG every time content changes. This would generate a clean and up-to-date site map.

Unfortunately this isn’t a great solution. The build times will get longer as the content grows. We would see builds failing as Vercel/Netlify (your build tool of choice) timed out. It is also overkill to re-build a whole site for one piece of content. And not at all efficient.

Run a pre-build script

This idea initially appealed to me. It shouldn’t be too much of a nightmare. Should be as simple as:

Run a query before the whole ISR build kicks off.
Grab all the site data with a GraphlQl query.
Build out a new XML file.
Push to the host.

My concern with this is that when hosting Next JS with Vercel/Netlify etc. we may not have created a directory yet. Especially if this is the first time the site has been built. We need to know where the file is to be sent. Their may be permissions issues. A rabbit hole I CBA with.

The Solution

Use the Yoast sitemap files.

Every headless WordPress site I build generally has Yoast installed. It makes handling a pages SEO far simpler, and content teams have usually worked with it before.

Yoast also generates its own sitemap XML. This is created as ‘sitemap_index.xml’ and then WordPress redirects it to ‘sitemap.xml’. So why not use this?

This solution was inspired by how the Patronage bubs-next starter handles their sitemaps.

Create a Sitemap XML Template

The first step is to create an XML template that our Yoast sitemap content can be injected into.

Download the XML file from this GitHub gist and add it to your /public folder.

XML Template: https://gist.github.com/robmarshall/caafd8a4328db0e58cf721a307af64e1

Creating a Proxy

The next step in using the Yoast sitemap from a headless WordPress install inside of Next JS is to create a proxy.

The purpose of this is to get the sitemap file contents from WordPress and serve it on your domain.

Create the API file

Create a file named sitemap-proxy.js within /pages/api/. This creates a server side function that we can use via ‘/api/sitemap-proxy’.

Install a Package

For the proxy to work, you will need to install a package.

isomorphic-unfetch

This is a helpful wrapper for fetch that works on both client/server side.

To install: npm i isomorphic-unfetch

Add the proxy code

Add the below code to your sitemap-proxy.js file.

import fetch from 'isomorphic-unfetch';

const WORDPRESS_URL = process.env.NEXT_PUBLIC_WORDPRESS_DOMAIN; // e.g. 'https://my-wordpressdomain.com'
const FRONTEND_URL = process.env.NEXT_PUBLIC_FRONTEND_DOMAIN; // e.g. 'https://localhost:3000'

// Global regex search allows replacing all URLs
const HOSTNAME_REGEX = new RegExp(WORDPRESS_URL, 'g');

function replace(...args) {
    const string = `${args[0]}`;
    return args.length < 3 ? string : string.replace(args[1], args[2]);
}

export default async function proxy(req, res) {
    let content;
    let contentType;

    // Get the page that was requested. The manual option allows us to process redirects
    // manually (if we get a redirect). So the next step of this function can work.
    const upstreamRes = await fetch(`${WORDPRESS_URL}${req.url}`, {
        redirect: 'manual'
    });

    // Check for redirects.
    // This allows for any internal WordPress redirect. For example the /sitemap_index.xml to /sitemap.xml.
    if (upstreamRes.status > 300 && upstreamRes.status < 310) {
        const location = upstreamRes.headers.get('location');
        const locationURL = new URL(location, upstreamRes.url);

        // Follow once only if on a wordpress domain.
        if (locationURL.href.includes(WORDPRESS_URL)) {
            const locationURL = new URL(location, upstreamRes.url);
            const response2 = await fetch(locationURL, {
                redirect: 'manual'
            });
            content = await response2.text();
            contentType = response2.headers.get('content-type');
        } else {
            // If there were more than two redirects, throw an error.
            throw new Error(
                `abort proxy to non wordpress target ${locationURL.href} to avoid redirect loops`
            );
        }
    } else {
        // There are no redirects, get original response text.
        content = await upstreamRes.text();
        contentType = upstreamRes.headers.get('content-type');
    }

    // If the current URL includes 'sitemap'.
    if (req.url.includes('sitemap')) {
        // Find any URLS inside the XML content that include "sitemap",
        // and replace the WordPress URL with the current site URL.
        content = replace(content, HOSTNAME_REGEX, FRONTEND_URL);

        // Change sitemap xsl file path to local
        let sitemapFind = '//(.*)sitemap-template.xsl';
        let sitemapReplace = '/sitemap-template.xsl';
        const SITEMAP_XSL_REGEX = new RegExp(sitemapFind, 'g');
        content = replace(content, SITEMAP_XSL_REGEX, sitemapReplace);
    }

    res.setHeader('Content-Type', contentType);
    res.setHeader('Cache-Control', 'max-age=60');

    res.send(content);
}

Add the Rewrites

The final step is to make sure that Next JS knows which URLs to pass through the proxy. For this it needs a rewrites function adding to the next.config.js.

This will look like:

async rewrites() {
        return [
            {
                source: '/(.*)sitemap.xml',
                destination: '/api/sitemap-proxy'
            },
            {
                source: '/sitemap(.*).xml',
                destination: '/api/sitemap-proxy'
            }
        ];
    }

This function should be added within module.exports.

What this does is target any URL with sitemap in the name, and passes it through the proxy.

Now if you spin your site up and navigate to ‘/sitemap.xml’ you should be shown the new, proxied sitemap from Yoast.

Hopefully this helped you, and if you have any questions you can reach me at: @robertmars

How to Loop over Jest Unit Tests

Robert Marshall — Mon, 26 Sep 2022 21:33:43 +0000

This article was originally posted (and is more up to date) at https://robertmarshall.dev/blog/how-to-loop-in-jest-unit-tests/

Sometimes when writing Jest unit tests you are going to want to be able to loop over items to quickly test different cases. Whether this be looping over an array of items, or counting between numbers in your Jest Test. This will massively simplify your Jest test suite.

There are a number of ways to do this. This post aims to outline the ways that I have looped through Jest tests in the past.

Looping over tests with Jest.Each

For very basic repetitive Jest tests I would use jest.each. It allows you to keep duplicating the same test with different data. You can write the test once and let the data do the work.

Using Basic Arrays and printf

An example of this is:

test.each([
  [1, 1, 2],
  [1, 2, 3],
  [2, 1, 3],
])('.add(%i, %i)', (a, b, expected) => {
  expect(a + b).toBe(expected);
});

The above code is taking in a set of data within an array, The name of the test using printf to inject parameters into the text, and the arguments to be passed into the test itself.

For more information about jest.each take a look at the Jest documentation.

Using Array of Objects

Rather than using printf, you can pass in an array of objects and reference them using string literals. Like so:

test.each([
  {a: 1, b: 1, expected: 2},
  {a: 1, b: 2, expected: 3},
  {a: 2, b: 1, expected: 3},
])('.add($a, $b)', ({a, b, expected}) => {
  expect(a + b).toBe(expected);
});

I personally prefer this. It is more explicit in what each item is, and allows you to build a more complex test data set.

Using Jest.Each with a Table

The jest.each API also lets you pass data into it in a more ‘visual’ way. Using one large string literal you can shape the data in a table.

This looks like:

test.each`
  a | b | expected
  ${1} | ${1} | ${2}
  ${1} | ${2} | ${3}
  ${2} | ${1} | ${3}
`('returns $expected when $a is added $b', ({a, b, expected}) => {
  expect(a + b).toBe(expected);
});

The first row sets up the table headings, and the rest of the rows using template literals to add the values. Then the test title itself using template literals to inject the data into the string.

Not my top choice, but some people like this way of handling the tests.

Using a For Loop in Jest Tests

The for loop is my go to when wanting to dynamically loop through Jest tests. In this way of writing loops in jest there is no need for the printf variable injection. Call me old fashioned (or wrong), but I also like the flexibility of being able to fully control the tests, and how they are created.

For example, the for loop approach allows me to loop describe jest test blocks, as well as the unit tests inside. However with this freedom comes the need to restrict yourself. Otherwise the tests could become to over-engineered and end up being too confusing.

Simple tests are better.

const testData = [
    { a: 1, b: 1, expected: 2 },
    { a: 1, b: 2, expected: 3 },
    { a: 2, b: 1, expected: 3 }
];

for (let i = 0; i < testData.length; i += 1) { it(`.add(${testData[i].a}, ${testData[i].b})`, () => {
        expect(testData[i].a + testData[i].b).toBe(testData[i].expected);
    });
}

The above shows how the for loop would be used to create dynamically generated Jest tests. However it should be used sparingly, and the jest.each will be able to handle most situations. The for loop is really more for complex situations.

For more Jest hints and tips take a look at the Jest Testing Category!

Hopefully this helped you, and if you have any questions you can reach me at: @robertmars

Forem: Robert Marshall

Wispr Flow + Claude Transforms Content Creation

The Numbers Don’t Lie

The Breakthrough Moment

This Isn’t Actually New (But It’s Better)

The Writing Problem

My Current Workflow

Why The Interview Format Works

The AI Clean-up Balance

Content Type Considerations

Quality Control for Technical Content

Getting Started: The Minimum Viable Experiment

The Meta-Validation

The Real Game Changer

Why My Gatsby to Next JS Migration Failed (And What It Taught Me About AI Workflows)

The “Obvious” Approach

The Tools

The Prompt

What Actually Happened

Where It All Went Wrong

The Real Problem: I Asked Claude to Solve the Wrong Thing

The Better Approach: Foundation First

Step 1: Clean Slate Foundation

Step 2: WordPress Data Layer Foundation

Step 3: Component Migration

Step 4: Integration & Testing

What This Taught Me About AI Workflows

The Broader Lesson

The Outcome

Turning Claude Code into a Development Powerhouse

The Problem: AI with Amnesia

The Solution: The MCP Stack

Context7: Your Live Documentation Oracle

Serena: Your Semantic Code Archaeologist

Sequential Thinking: Your AI Architect

WisprFlow: Your Voice-to-Code Pipeline

And Then the Slash

Real-World Example: Building Auth from Scratch

The Compound Effect

But Create a Scope...

How to Use Hookdeck.com to Test and Debug Webhooks

Contents

What Is a Webhook and How Does It Work?

Real-World Webhook Examples

FormBear

Stripe

GitHub

Testing Webhooks with Hookdeck: Step-by-Step

Step 1: Set Up Your Hookdeck Project

Step 2: Create an Event Source

Step 3: Get Your Webhook URL

Step 4: Send Test Webhooks

Step 5: Monitor and Debug

Migrating from query-string to URLSearchParams

Stringify URL Params with URLSearchParams

Parsing with URLStringParams

On-Click Lazy Load YouTube Video Iframe in React

YouTube Without Improvements

Requirements

Implementing the Solution

Lazy Loading Videos on Scroll with Vanilla JS and Intersection Observers

Setting up the HTML Structure

Section 2: The Intersection Observer API

Section 3: The JavaScript Implementation

Section 4: Implementing Lazy Loading

Using Gravity Forms with Headless WordPress and Next JS

Contents

What Packages Do I Need?

WordPress

Next JS

Step 1 – Setup WordPress

Step 2 – Add Form Packages to Next JS

Add Package

Environment Variable

Step 3 – Using the Package Within Your Project

Create Frontend Form Component

Get Gravity Forms Data from WordPress into Next JS

Getting a Single Form

Rendering Forms Dynamically

Add Google reCaptcha to the Form