DEV Community: Leon

Testing React Page Titles Before JavaScript Runs and After Navigation

Leon — Mon, 02 Nov 2026 03:08:02 +0000

Disclosure: I build MyAIRap.video. This development case study was written with AI assistance and checked against the project's release records and a production test.

The MyAIRap.video homepage looked complete in Chrome. It had examples, pricing, and a link to the video creator. A raw HTTP request returned a heading, two paragraphs, and a link to the creator. The pricing link I could see in Chrome was missing from the initial HTML.

We already had a Python prerender step. It wrote a short summary for each public route, while React rendered the full page in the browser. That meant we maintained two versions of the content for the same URL. We also found a separate problem on /pricing. The initial HTML had a pricing title, but the browser could show the homepage title after React took over.

Replace the hand-written summaries with rendered React components

Here is the complete <main> from the old homepage build artifact, reformatted for readability:

<main>
  <h1>AI RAP VIDEO Generator</h1>
  <p>Make your photo rap.</p>
  <p>Create AI rap videos from your photos with MyAIRap.video. Go solo, rap with a friend, or let your pet take the mic. Pick a style and make it yours.</p>
  <a href="/create">Create original Rap</a>
</main>

We changed the build to render the existing React components for the homepage, pricing, tutorial, and articles. Python still assembled the page document around that output. The rendering happened at build time. Account balances and orders stayed behind authentication.

These are two excerpts from the new homepage artifact, with the surrounding markup omitted:

<a href="/pricing" class="">Pricing</a>

<h1 class="hero-display">AI RAP VIDEO Generator</h1>
<p class="hero-description">Your face. Your words. A whole new energy. Turn a photo into an original Rap video.</p>

Route	Previous build artifact	November 1 build artifact
/	1,175 bytes	29,099 bytes
`/pricing`	1,065 bytes	13,077 bytes

The new artifacts matched the SHA-256 hashes of the production responses captured during release verification. The byte counts helped spot unexpectedly small responses. The checks that mattered were more specific: the homepage contained a real link to /pricing, and the pricing HTML contained amounts from the product catalog.

A correct `<title>` in the response can still become stale in the browser

The old pricing artifact already had a route-specific title:

<title>Pricing &amp; credits | MyAIRap.video</title>

A test that only fetched /pricing could therefore pass while the browser still showed the wrong title. We put the metadata for each public route in a shared definition used by the build and by client-side navigation. The November 1 pricing artifact contained:

<title>AI Rap Video Pricing: One-Time Credits, No Subscription</title>
<link rel="canonical" href="https://myairap.video/pricing">

The title copy changed in a later release. On November 3, 2026, I ran the following check against production using playwright-core and headless Edge. The code below uses a normal package import in place of the machine-specific path used to load playwright-core in the test environment. The expected title came from the current route configuration.

const assert = require('node:assert/strict');
const { chromium } = require('playwright-core');

(async () => {
  const origin = 'https://myairap.video';
  const url = new URL('/pricing', origin).href;
  const expected = 'AI Rap Video Generator Pricing 2026 | MyAIRap.video';

  const response = await fetch(url);
  assert.equal(response.status, 200);

  const raw = (await response.text()).match(/<title>([^<]*)<\/title>/i)?.[1];
  assert.equal(raw, expected);

  const browser = await chromium.launch({ channel: 'msedge', headless: true });
  try {
    const page = await browser.newPage();
    await page.goto(origin);

    const home = await page.title();
    assert.notEqual(home, expected);

    await page.evaluate(() => { window.__titleCheck = true; });
    await page.locator('a[href="/pricing"]').first().click();
    await page.waitForURL(url);
    await page.waitForFunction(title => document.title === title, expected);

    const title = await page.title();
    assert.equal(title, expected);

    const sameDocument = await page.evaluate(() => window.__titleCheck === true);
    assert.equal(sameDocument, true);

    console.log(JSON.stringify({
      status: response.status,
      raw,
      home,
      title,
      url: page.url(),
      sameDocument
    }));
  } finally {
    await browser.close();
  }
})().catch(error => {
  console.error(error);
  process.exitCode = 1;
});

The run returned:

{
  "status": 200,
  "raw": "AI Rap Video Generator Pricing 2026 | MyAIRap.video",
  "home": "AI Rap Video Generator 2026 from Photos | MyAIRap.video",
  "title": "AI Rap Video Generator Pricing 2026 | MyAIRap.video",
  "url": "https://myairap.video/pricing",
  "sameDocument": true
}

The window marker was there to make the test discriminate between a client-side route change and a full page load. Without it, the title assertion could pass after a full load simply because the server had already sent the correct title. The marker survived the click, and the title changed from the homepage value to the pricing value in the same document.

This is the pair of checks I would keep on another React site. Fetch an important route and assert something specific about its raw response. Then reach it through an in-app link and check the browser state. These checks establish what the server sent and what the app did with it. Search indexing needs its own evidence.

Building a Browser-Local Moving Checklist Without User Accounts

Leon — Thu, 10 Sep 2026 03:27:47 +0000

Many planning tools begin with sign-up, cloud storage, and collaboration features. For a moving checklist, I wanted to test a narrower idea: can a useful planning tool work without requiring an account?

MovePlaybook is a browser-based moving checklist. A user starts with a move date, reviews a generated task plan, adjusts tasks when circumstances change, and can print or save the plan as a PDF.

The technical constraint was privacy: the product should remain useful even when the plan is stored locally in the browser. That shaped several decisions.

First, task identity needs to be stable. A user may complete, reschedule, hide, restore, or annotate a task, so those changes must attach to a durable task ID rather than a display position.

Second, temporary hiding must not mean deletion. A hidden task is excluded from the active checklist and PDF, but it remains recoverable through a dedicated Hidden view.

Third, schedule changes need explanations. When a user adjusts a date, the interface should distinguish between a recommended date, a tight timing window, a conflict, or something the user must confirm locally.

The product is available at https://moveplaybook.app/

I built it as a practical experiment in local-first planning. I would be interested in how other developers approach versioned browser storage, printable application state, and explainable scheduling rules.

How to convert a folder of PNGs to one PDF without uploading the files

Leon — Sat, 05 Sep 2026 12:48:21 +0000

A simple browser-local PNG-to-PDF workflow

For this kind of job, the useful workflow is straightforward:

Select the PNG, JPG, or JPEG files.
Put the pages in the order they should appear.
Choose a page size and margins if the document needs them.
Export one PDF.

The important detail is where the conversion happens. A browser-local PNG-to-PDF tool processes the images in the browser instead of uploading them to a conversion server. That makes it easier to keep control of source files while still producing one shareable PDF.

When this is useful

This workflow is handy for:

combining screenshots into a bug report or handoff document;
turning scanned pages into one file for email or printing;
arranging portfolio images or design exports in a deliberate order; and
collecting receipts or reference images without making a separate document first.

Before exporting, check the page order and decide whether each page should match the image, A4, or US Letter. A preview is useful here: it catches a stray portrait page, an oversized margin, or a screenshot in the wrong position before the PDF is created.

The tool I use for this

I maintain PNG Binder, a free PNG-to-PDF converter for this specific workflow. It accepts up to 50 PNG, JPG, or JPEG images, lets you arrange them, and creates one PDF locally in the browser. It does not require an account, and the images are not sent to a conversion server.

It creates an image-based PDF, so it does not perform OCR or rebuild text and tables. If that is the kind of result you need, try it and let me know whether page ordering, page settings, or browser compatibility could be improved.

Disclosure: I am the maker and operator of PNG Binder.

A small privacy decision that changed my web calculator

Leon — Thu, 03 Sep 2026 10:00:20 +0000

I built Calculator Toolkit for a narrow moment: someone has a restaurant bill, wants to check the tip and tax math, then needs to split the total with a few people.

At first I treated the no-account requirement as a small feature. It turned out to be the decision that shaped most of the interface.

A saved-history feature would be convenient. It would also mean sign-in, account recovery, data retention, and an extra decision for someone who only wants to settle a dinner bill. I decided that the calculator should run locally in the browser instead. There is no account and no bill-data upload.

That creates constraints. A person cannot return tomorrow and recover an earlier calculation. There is no dashboard where an unclear result can be explained later. The current screen has to do the work. It needs to make the bill amount, tax, tip basis, total, and each person's share understandable before the group pays.

I found that this was less about adding a privacy notice and more about removing places where the product could hide complexity. If the calculation is temporary, the result needs to be legible now. If somebody changes the tip basis, the change needs to be obvious. If one diner pays a different share, the total still has to add up.

I do not think local-only is a universal rule. It is a poor fit for products where history, collaboration, or handoffs are the reason people use the product. For a one-off restaurant calculation, it felt like the more honest default.

I am Leon, the maker of Calculator Toolkit. I would like feedback from other developers: when you remove accounts or saved state from a small tool, which parts of the interface become harder to get right?

Disclosure: This article was drafted with AI and reviewed by Leon.