DEV Community: hiro@

Migrating Next.js Middleware to Proxy: verify the matcher and runtime after renaming

hiro@ — Fri, 06 Nov 2026 03:52:35 +0000

After renaming Middleware to Proxy, verify which requests pass through it and which runtime it uses. Next.js 16.3.4's codemod transformed this minimal example, while a comparison version that added a runtime export to Proxy failed to build.

The example adds an observation header to a response. It is not a migration of a real service's authentication flow.

Why the name changed to Proxy

The official migration explanation describes avoiding confusion with Express.js middleware and emphasizing the network boundary before a request reaches the application. The change starts with Next.js 16.

The name alone is not a reason to collect every general-purpose operation there. This experiment keeps route handling separate from the header added before proceeding to the route.

Inspect what the codemod changed

The input middleware.js exports a function named middleware and uses /protected/:path* as its matcher. The middleware-to-proxy transform from @next/codemod 16.3.4 ran against an experimental copy.

Its resulting proxy.js was:

import { NextResponse } from 'next/server';
export function proxy(request) {
  const response = NextResponse.next();
  response.headers.set('x-article-proxy', request.nextUrl.pathname);
  return response;
}
export const config = { matcher: ['/protected/:path*'] };

The original file was removed, and the exported function became proxy. The header-setting behavior and matcher remained. No login check or redirect was added to this example.

The file sits alongside app. The record contains both versions. Application behavior still needs checking after the transformation.

Verify the matcher with HTTP requests

The transformed code was built for production and served through local next start. The route handles GET by returning the path. Header presence was recorded separately from HTTP status.

Request	Status	x-article-proxy
GET /protected	200	/protected
GET /protected/a/b	200	/protected/a/b
GET /protected?x=1	200	/protected
GET /protectedness	404	Absent
GET /	200	Absent
GET /plain.png	200	Absent
POST /protected	405	/protected

Although /protectedness starts with similar text, this matcher did not include it. With a query string, the pathname placed in the header remained /protected.

POST passed through Proxy but returned 405 because the route had no POST handler. Passing through Proxy and having a route that supports a method are separate observations.

These 7 inputs check the target route and nearby paths. They do not cover every URL, prefetch request, basePath, locale, or rewritten path. Check the matcher reference, then add requests required by the application.

What happens if Proxy retains a runtime export?

A separate fixture added export const runtime = 'edge' to this Proxy. Its build failed with exit 1. The error stated that Proxy does not allow route segment configuration and runs on the Node.js runtime.

The Proxy runtime reference also disallows a runtime option. The rename does not establish that earlier Edge assumptions remain applicable.

This error does not test authentication-library compatibility or real network operations. Code using runtime-specific APIs still needs its transformed build and request handling checked.

The tests ran on September 11, 2026. Next.js and the codemod were 16.3.4, installed React and React DOM were 19.3.0, and Node.js was 24.15.0 on macOS arm64. The fixture used a webpack production build, cacheComponents: false, no React Compiler, and a local Node server. The runner and HTTP results are available. No cloud deployment or real application migration was performed.

What JavaScript using disposes after returns and exceptions: nine checks

hiro@ — Thu, 05 Nov 2026 03:54:28 +0000

using registers an object with a disposal method in a scope and calls cleanup when that scope ends. When several resources were registered, they were disposed in reverse acquisition order. An early return followed the same rule.

Nine conditions in Node.js covered disposal order, retained exceptions, and asynchronous waiting. Before using it, check which object supplies disposal and which scope exit triggers cleanup.

Disposal finishes before the caller receives a return value

This code ran as an .mjs file in Node.js 24.15.0, without a transpiler or polyfill:

const events = [];
function open(name) {
  events.push(`open:${name}`);
  return { [Symbol.dispose]() { events.push(`close:${name}`); } };
}
function work() {
  using first = open('A');
  using second = open('B');
  events.push('body');
  return 'done';
}
const value = work();
console.log(JSON.stringify({ value, events }));

The result contained value: "done", with events open:A → open:B → body → close:B → close:A. Both disposals had finished when the caller received the return value.

open only returns a fixture object. The log records calls to Symbol.dispose; it is not a measurement of real files or connections. The ECMAScript declaration and scope specification also describes disposing resources registered through using when scope processing finishes.

The comparison included failures as well as normal completion:

Condition	Observed order or result
Acquire A and B, finish normally	Dispose B, then A
Acquire A and return	Dispose A before returning to the caller
Throw in the body	Dispose A before entering catch
Acquire A, then throw while acquiring B	Dispose registered A; no disposal call for B
Body and both A/B disposals throw	Attempt both disposals and retain errors through SuppressedError
Register A and B with await using	Finish B's asynchronous disposal before disposing A
Pass an asyncDispose-only value to using	TypeError; asynchronous disposal is not called
Pass null and undefined to using	Execute the body without disposal methods
Throw while using a temporary directory	Directory no longer exists after entering catch

When acquiring B throws, using does not dispose B afterward. If the acquisition function allocated something before failing, that function needs to clean up its partial acquisition.

Where does the body error go if cleanup fails too?

A deliberately failing disposer tested this case. The body threw body failed, B threw close failed:B, and A threw close failed:A.

The caught exception's error.message was close failed:A. The body failure was still retained:

Reference	Recorded message
error.error.message	close failed:A
error.suppressed.error.message	close failed:B
error.suppressed.suppressed.message	body failed

Both the outer and inner wrappers were SuppressedError objects. Cleanup continued after a disposal failed, with earlier errors retained in a related chain. The explicit resource management design material explains this relationship.

Logging only the outer message can miss the body failure. The experiment followed both error and suppressed and checked each message.

Use await using for asynchronous disposal

The asynchronous fixture recorded the start and end of Symbol.asyncDispose separately. Registering await using a = ... and await using b = ... produced body → close start:B → close end:B → close start:A → close end:A → after work.

The wait in this fixture was Promise.resolve(). It did not measure network or disk I/O duration. It did verify that A's disposal started after B's completed, and that the caller continued after both finished.

Passing an object with only Symbol.asyncDispose to using without await produced a TypeError. An asynchronously disposable value cannot simply be placed in an ordinary using declaration.

Check a real Node.js temporary directory

The next example uses an actual temporary directory rather than only a logging object:

import { existsSync, mkdtempDisposableSync, writeFileSync } from 'node:fs';
import { tmpdir } from 'node:os';
import { join } from 'node:path';

let path;
try {
  using temporary = mkdtempDisposableSync(join(tmpdir(), 'article-using-example-'));
  path = temporary.path;
  writeFileSync(join(path, 'sample.txt'), 'fixture');
  console.log('inside:', existsSync(path));
  throw new Error('work failed');
} catch (error) {
  console.log('caught:', error.message);
}
console.log('after:', existsSync(path));

The output was inside: true, caught: work failed, and after: false. The directory, including sample.txt, was removed when the exception left the scope.

Node.js 24.15.0's mkdtempDisposableSync returns an object with a path and a disposal method for removal. This API was added in 24.4.0. An arbitrary path string does not acquire that deletion behavior merely by being used in a using declaration.

The tests ran on September 11, 2026, with Node.js 24.15.0 on macOS arm64. The nine-condition fixture and results are available. Other Node versions, browsers, transformed code, and forced process termination were not tested. These results cover disposal when JavaScript can execute the scope-exit steps.

Does useActionState preserve input? Nine comparisons with manual form state

hiro@ — Wed, 04 Nov 2026 03:34:03 +0000

useActionState manages an Action's result and pending status. It does not automatically preserve input values. In this fixture, returning a validation-error result still cleared the uncontrolled input.

The Action version was compared with ordinary onSubmit handling and useState, then a change to retain invalid input was tested. The state holding an Action result and the input that should remain after a failure each need a design decision.

Call the same operation through an Action and onSubmit

This is the synthetic save operation. It sends no network request; browser test controls resolve its Promise. trace records call order and pending operations for the experiment.

async function save(previous, formData) {
  const name = formData.get('name');
  trace.calls.push({ previous: { ...previous }, name });
  await new Promise(resolve => trace.gates.push(resolve));
  if (name === 'crash') throw new Error('simulated failure');
  if (name === 'bad') return { ...previous, message: 'invalid' };
  return { count: previous.count + 1, message: `saved:${name}` };
}

good returns success, bad returns a validation-error result, and crash throws. The first argument is previous, and the second is FormData.

The Action version receives state, formAction, and pending from useActionState(save, initialState), then passes formAction to the form's action prop. Its input is uncontrolled with defaultValue="". The useActionState reference defines the previous-result argument and the pending return value.

The manual version calls the same save operation from onSubmit:

async function onSubmit(event) {
    event.preventDefault();
    const data = new FormData(event.currentTarget);
    setPending(true);
    try { setState(await save(state, data)); }
    catch (error) { setState(previous => ({ ...previous, message: error.message })); }
    finally { setPending(false); }
  }

It also uses an uncontrolled input and does not call form.reset on success. It sets pending and result state explicitly and catches exceptions to produce a message. This minimal implementation shows which behavior is written manually; it is not a demonstration of a general limitation of useState.

Returning an error result differed from throwing

The first comparison covered 6 conditions. Every submission showed pending as true and retained the entered text while the operation was held unresolved.

Approach and input	Result at completion	Input after completion
Action, good	count 1, saved:good	Empty
Manual, good	count 1, saved:good	good
Action, bad	count 0, invalid	Empty
Manual, bad	count 0, invalid	bad
Action, crash	Moves to Error Boundary	Form removed
Manual, crash	count 0, caught message	crash

Although the Action returned invalid for bad, its Promise resolved normally. The uncontrolled-input reset after a successful Action, described in the React form reference, also occurred here. An application interpreting a return value as a validation error is different from the Action throwing.

An Error Boundary around the Action version displayed simulated failure instead of the form when save threw. The manual version catches the exception and stores a message, so it does not make the same display transition.

Include the input that needs to survive in the result

This version was added to preserve input after a validation error:

async function saveWithInput(previous, formData) {
  const next = await save(previous, formData);
  return { ...next, input: next.message === 'invalid' ? String(formData.get('name')) : '' };
}
export function PreservingExperiment() {
  const [state, formAction, pending] = useActionState(saveWithInput, { ...initialState, input: '' });
  return <section>
    <output id="action-state">{JSON.stringify(state)}</output>
    <output id="action-pending">{String(pending)}</output>
    <form id="action-form" action={formAction}>
      <input id="action-input" name="name" defaultValue={state.input} />
      <button id="action-submit" disabled={pending}>Save</button>
    </form>
  </section>;
}

On validation failure, it returns the entered value and passes it to the input's defaultValue. On success, it returns an empty string. The additional 2 conditions retained bad after invalid input and cleared the field after good.

The input still is not controlled through value. Including the post-Action default in state preserves the required value after this reset. This is a fix verified inside the experiment, not a form already integrated into an existing application.

Multiple calls wait for the previous result

Another condition dispatched twice from a separate button rather than through form submission:

function queueTwo() {
    startTransition(() => {
      for (const name of ['first', 'second']) {
        const data = new FormData(); data.set('name', name); formAction(data);
      }
    });
  }

Until the first Promise resolved, only one save call was recorded. Resolving it started the second call, whose previous.count was 1. The final state had count 2 and message saved:second.

Observation point	Started save calls	Count on screen	pending
First call unresolved	1	0	true
First resolved, second unresolved	2	0	true
Both resolved	2	2	false

In this experiment, the previous result passed to the next Action differed from the intermediate state already visible on screen. Both call history and DOM state were recorded.

React treats calls through the form action as a Transition. The direct button-dispatch comparison instead calls inside startTransition. Calls outside a Transition and designs expecting this Hook to execute operations in parallel were not tested.

This experiment uses client functions only

The tests ran on September 11, 2026, with React and React DOM 19.3.0, Node.js 24.15.0, esbuild 0.28.2, macOS arm64, and Headless Chrome 152. A production build without Strict Mode or React Compiler covered 9 conditions. Pending operations were resolved manually; network latency was not measured.

The experiment excludes Server Functions, submissions before JavaScript loads, permalink behavior, authentication, and persistence. The official API also covers Server Function integration, but these results come from functions running in the browser. Server-side validation and authorization were neither implemented nor tested here.

The comparison code and results for the 9 conditions include whether inputs clear or remain and where thrown errors move the display, as well as pending status and return values.

Testing callback ref cleanup on the same DOM node and in TypeScript

hiro@ — Tue, 03 Nov 2026 04:15:00 +0000

A React callback ref can return a cleanup function as well as receive a DOM node. This capability, added in React 19, was tested through ResizeObserver registration and disconnection.

Unmounting is only part of the behavior. Even when the same DOM node remained, changing the callback reference ran the previous cleanup and the next registration.

Return disconnection from the callback that creates the observer

This function creates a callback ref and records its activity. With legacy: false, it returns cleanup. With true, it disconnects when called with null.

function makeTrackedRef(legacy) {
  let observer;
  function disconnect() {
    observer.disconnect();
    trace.active.delete(observer);
    trace.events.push('cleanup');
  }
  return node => {
    if (node === null) {
      trace.events.push('null');
      if (observer) disconnect();
      return;
    }
    observer = new ResizeObserver(() => {});
    observer.observe(node);
    trace.active.add(observer);
    trace.events.push('attach');
    if (!legacy) return disconnect;
  };
}

The fixture creates a real browser ResizeObserver and observes the node. trace.active tracks observers whose disconnection has not been recorded. Resize notification counts are not part of this comparison.

The test compares preserving a callback with creating a new one on every render:

export function RefExperiment({ stable, legacy }) {
  const [tick, setTick] = useState(0);
  const stableRef = useMemo(() => makeTrackedRef(legacy), [legacy]);
  const ref = stable ? stableRef : makeTrackedRef(legacy);
  return <section>
    <button id="rerender" onClick={() => setTick(previous => previous + 1)}>Render {tick}</button>
    <div id="observed" ref={ref}>Observed node</div>
  </section>;
}

Clicking the button rerenders the parent while the target div remains the same node. The root is then unmounted to verify cleanup.

A different callback triggers cleanup on the same node

Build and callback construction	Initial log	Log added by rerender	Log added by unmount
Production, same callback, returns cleanup	attach	None	cleanup
Production, new callback, returns cleanup	attach	cleanup → attach	cleanup
Production, same callback, cleans up on null	attach	None	null → cleanup
Development root Strict Mode, same callback, returns cleanup	attach → cleanup → attach	None	cleanup
Development root Strict Mode, new callback, returns cleanup	attach → cleanup → attach	cleanup → attach	cleanup
Development root Strict Mode, same callback, cleans up on null	attach → null → cleanup → attach	None	null → cleanup

All 6 conditions had one tracked observer after initial processing and after rerender, then 0 after unmount. Even the version creating new callbacks paired setup with cleanup, so observers did not accumulate in this implementation.

The callback ref reference distinguishes returned cleanup, cleanup and reattachment when callbacks change, and the extra development cycle. No null call appeared in the returned-cleanup version's logs. Do not expect a second copy of the same cleanup through a null callback.

Direct comparison of node references before and after rerender confirmed that the DOM node stayed the same. Callback activity and DOM replacement are separate observations.

An implicit value return can fail type checking

Type behavior was also checked with TypeScript 7.0.2, @types/react 19.3.0, strict checking, and react-jsx.

import React from 'react';
const nodes = new Map<string, HTMLDivElement | null>();
export const view = <div ref={node => nodes.set('preview', node)} />;

Map.set returns the Map, so this callback did not satisfy the required void-or-cleanup return type and produced TS2322. A cleanup written as () => nodes.delete('preview') also produced TS2322 because it returns a boolean.

The version using a block and returning no value from cleanup passed:

import React from 'react';
const nodes = new Map<string, HTMLDivElement>();
export const view = <div ref={node => {
  if (!node) return;
  nodes.set('preview', node);
  return () => { nodes.delete('preview'); };
}} />;

This type comparison corresponds to the change described in the React 19 upgrade guide. When the operation is storing a node in a Map, avoid forwarding the Map operation's return value as the ref callback result.

Separate cleanup behavior from state-update loops

An existing article examined a ref callback that repeatedly updated state in an image preview. This experiment leaves state updates out of the observer callback and compares callback identity with cleanup timing. It does not establish that returning cleanup fixes arbitrary state-update loops.

The tests ran on September 11, 2026, with React and React DOM 19.3.0, Node.js 24.15.0, esbuild 0.28.2, macOS arm64, and Headless Chrome 152 and no React Compiler. The production cases also had a Strict Mode wrapper, but did not run the extra development cycle. Observer counts come from fixture registration and disconnection records, not measurements of the browser's internal resource usage.

The fixture code, logs for the 6 conditions, and 3 type-checking cases separate changes to the DOM node from changes to the callback reference.

useSyncExternalStore: test snapshot identity and the initial SSR value

hiro@ — Mon, 02 Nov 2026 02:56:56 +0000

An external store can notify its subscribers without changing the screen rendered through useSyncExternalStore. After the same snapshot object was mutated in this experiment, the screen still displayed 0 following the notification.

The Hook needs a subscription notification and a snapshot that represents the change. With SSR, the initial client read must also receive the value used to generate the server HTML.

The notification arrived with the same snapshot reference

This test store includes both replacement and a deliberately incorrect mutation for comparison. The mutate method is not a recommended application pattern.

export function createCounterStore(initial) {
  let snapshot = initial;
  const listeners = new Set();
  return {
    getSnapshot: () => snapshot,
    subscribe(listener) {
      listeners.add(listener);
      return () => listeners.delete(listener);
    },
    replace(count) {
      snapshot = { count };
      for (const listener of listeners) listener();
    },
    mutate(count) {
      snapshot.count = count;
      for (const listener of listeners) listener();
    },
    listenerCount: () => listeners.size,
  };
}

replace creates a new object. mutate changes only count on the existing object. Both call the registered listeners.

The screen reads count from useSyncExternalStore(store.subscribe, store.getSnapshot).

Operation	Count in the store	Count on screen	Recorded values passed through the display component
Initial	0	0	0
Mutate the same snapshot and notify	1	0	No additional invocation
Replace with a new snapshot and notify	2	2	2 added

Checking only whether a notification was sent misses this difference. The value returned by getSnapshot must represent the change when compared with Object.is. The official reference describes the contract: return the same snapshot while data is unchanged, and a new immutable snapshot when it changes.

The test observed the mutation without an unrelated parent-state update or other rerender. It did not check what the display would show after a rerender triggered elsewhere.

Returning a new object on every read violates the contract too. The documentation describes that pattern as causing an update loop, but this experiment did not execute that loop. It checks a store that reuses a snapshot until the next change.

Include unsubscription in the store contract

subscribe returns a function that removes the listener as well as registering it. The experiment recorded one subscription after mount and 0 after unmount.

The same store-provided subscribe function is reused. This does not measure resubscription caused by creating a new function on every render or performance with many subscribers.

SSR needs a matching initial snapshot as well as a current value

The server generated this HTML with renderToString:

<output id="store-count">0</output>

The client store intentionally starts with a newer current value of 1. The server's initial { count: 0 } is passed through window.__BOOTSTRAP__ and read during hydration.

import React from 'react';
import { hydrateRoot } from 'react-dom/client';
import { createCounterStore, StoreCounter } from './external-store.mjs';
const bootstrap = window.__BOOTSTRAP__;
const store = createCounterStore({ count: 1 });
const record = { serverSnapshots: [], renders: [], errors: [] };
function getServerSnapshot() {
  record.serverSnapshots.push(bootstrap.count);
  return bootstrap;
}
const root = hydrateRoot(document.getElementById('root'),
  <StoreCounter store={store} getServerSnapshot={getServerSnapshot} rendered={value => record.renders.push(value)} />,
  { onRecoverableError(error) { record.errors.push(error.message); } });
window.readHydration = () => ({ ...record, count: document.getElementById('store-count')?.textContent, subscribers: store.listenerCount() });
window.unmountHydration = () => root.unmount();

record and rendered are instrumentation. They record snapshot reads and component invocations, while onRecoverableError captures mismatches. The HTML and bootstrap data contain fixed numbers only; this is not an example of embedding user data.

Initial value passed to the client	Sequence of count values read by the component	Hydration mismatch
0, matching the server	0 → 1	None
2, differing from the server	2 → 1	Present

With the matching bootstrap, the component first read the server's value and then moved to the client store's current value. Both cases eventually displayed 1, so inspecting only the final display would miss the mismatch. These records capture component invocations, not the number of frames for which 0 was visible.

Omitting getServerSnapshot and rendering the same component through renderToString threw an error requiring the initial snapshot. The SSR documentation requires the same data during server rendering and hydration.

The Hook does not replace the storage implementation

In this example, createCounterStore stores the value. The Hook connects its subscription and snapshot to React. The experiment does not move all application-local state into an external store.

The tests ran on September 11, 2026, with React and React DOM 19.3.0, Node.js 24.15.0, esbuild 0.28.2, macOS arm64, and Headless Chrome 152. Notification behavior used a production build; hydration used a development build. Neither used Strict Mode or React Compiler. Server rendering used Node.js renderToString. Tearing during concurrent rendering and streaming SSR were outside the test scope.

The store and display component, SSR input, and browser results let you inspect notifications, snapshot references, and server initial values separately.

Controlled input work depends on state placement: compare 10, 100, and 500 fields

hiro@ — Sun, 01 Nov 2026 02:49:41 +0000

Field count alone does not determine whether a form should use controlled or uncontrolled inputs. Even with controlled inputs, placing state in each field meant editing one field invoked only one input component.

The experiment compared parent-owned values, field-local state, and DOM-owned values across forms with 10, 100, and 500 fields. Reducing repeated component work requires looking at state placement as well as whether inputs are controlled.

Count component calls for the same input operation

These are the three field components. trace is an experiment counter, not application state.

function ControlledField({ index, value, onChange }) {
  trace.fieldRenders++;
  return <input name={`field-${index}`} value={value} onChange={onChange} />;
}
function LocalField({ index }) {
  trace.fieldRenders++;
  const [value, setValue] = useState(initialValue(index));
  return <input name={`field-${index}`} value={value} onChange={event => {
    trace.fieldChanges++;
    setValue(event.target.value);
  }} />;
}
function UncontrolledField({ index }) {
  trace.fieldRenders++;
  return <input name={`field-${index}`} defaultValue={initialValue(index)} />;
}

The parent-owned version keeps a values array in state, replaces the changed position, and passes values to every input. The local version updates state inside LocalField. The uncontrolled version supplies an initial defaultValue and reads values through FormData on submission.

Field count and order stay fixed within each condition. The fixture uses position keys and does not delete, insert, or reorder fields.

Each input has a distinct name. A browser fill operation replaced the first field's field-0 value with edited. This was not a character-by-character typing test. Both controlled versions recorded one onChange call for that operation.

The measurement is the additional component-function calls caused by the edit, excluding initial rendering.

State placement	Fields	Additional parent-form calls	Additional input-component calls
Parent-owned	10	1	10
Parent-owned	100	1	100
Parent-owned	500	1	500
Field-local state	10	0	1
Field-local state	100	0	1
Field-local state	500	0	1
DOM-owned	10	0	0
DOM-owned	100	0	0
DOM-owned	500	0	0

The production build used no React Compiler, memo, or Strict Mode. The table therefore compares the same unoptimized structure. Zero input-component calls does not mean the browser performs no input or painting work. Execution time, FPS, and memory use were not measured.

The React input reference describes updating a controlled value in onChange and moving state to the part of the tree that needs it. The observed results also show that controlled inputs do not inherently require the entire parent to rerun.

Verify collected values too

All 9 conditions produced as many FormData entries as there were fields, with edited as the first value after editing. This did not aggregate all field-local values into parent React state simultaneously. It collected values already reflected in the DOM using the submission method chosen for this experiment.

Immediate previews of all fields or validation across fields require an additional decision about where values are read. This fixture contains independent text inputs only. It excludes form libraries, IME composition, and asynchronous validation.

The same reset button produced different outcomes

After editing, pressing a type="reset" button left edited in both controlled versions. The uncontrolled version returned to field-0.

Approach	After HTML reset	Explicit reset method used in the experiment
Parent state	edited	Set state to an array of initial values
Field-local state	edited	Change the form key to remount it
Uncontrolled	field-0	Call form.reset()

Changing the key in the field-local version tests whether remounting restores initial values. Remounting also recreates component state below that point. It should not be applied unchanged when a reset must preserve focus or other state.

After an explicit reset, all three approaches showed field-0 in the first field. Treat native reset and React state initialization as separate operations, then verify reset behavior for the chosen value ownership. The form reference also covers event-based submission and reading values with FormData.

The tests ran on September 11, 2026, with React and React DOM 19.3.0, Node.js 24.15.0, esbuild 0.28.2, macOS arm64, and Headless Chrome 152. The complete form fixture and results for the 9 conditions are available. These results do not establish that 500 fields always require uncontrolled inputs. Choose with both the values React needs during editing and the submission/reset behavior in view.

Carrying unfinished work between Plane cycles without closing the release

hiro@ — Sat, 31 Oct 2026 02:56:25 +0000

The implementation is ready at the end of the week, but mobile verification remains. Marking the work item Done just to close the weekly cycle would make that unfinished verification look complete.

At the weekly boundary, preserve the work item's actual state and decide what to carry forward. A release module should retain the conditions for delivering its output. The end of a week and readiness to distribute a feature need separate states.

The example is SquadNote's trial-participant feature. A read-only Plane inspection on September 11, 2026 found zero non-archived cycles and zero modules. The following is a proposed workflow built from real acceptance criteria and verification records, not a report of an established weekly process. No Plane settings or work states were changed.

The remaining work was mobile verification

SQN-30 covers trial-participant permissions, invitation URL compatibility, promotion to full membership, and ending a trial. Its acceptance conditions require consistent behavior on web, iOS, and Android. The ticket covers the development environment and automated tests; production rollout is explicitly outside its scope.

The verification document at fixed commit d116e8a contains completed web checks and unfinished mobile checks. Some mobile checks are marked complete, but the final item confirming completion of mobile verification remains unchecked.

The next plan does not need to repeat the entire implementation. It needs to preserve the verified version and results, then identify what remains unchecked on which device. This article did not rerun those application checks.

Keep one work item for the work itself

According to Plane's cycle documentation, unfinished work items retain their state when a cycle ends and can be transferred to another cycle. A work item can belong to only one cycle at a time. The module documentation allows a work item to belong to multiple modules, such as a feature module and a release module.

Keep one work item and relate it to the relevant period and deliverable. There is no need to create two identically named tickets solely for weekly and release tracking.

However, putting only SQN-30 in a release module would leave a gap. Done on that ticket does not include production distribution. Tracking the release requires separate work for distribution and verification afterward.

Proposed arrangement

Work item: SQN-30
  Scope: Trial-participant implementation and acceptance in development
  Weekly membership: This cycle → next cycle if needed

Proposed additional work: Distribution and post-distribution verification
  Scope: Define targets and procedure, then record results for the target version

Release module
  Related work: SQN-30 and the distribution/verification task
  Acceptance: Distribution to the agreed targets and completion of required checks

The additional task has no Plane ID because it has not been created. It remains a proposal.

Carry the reason for unfinished work into the next plan

Applying the current verification record to a hypothetical weekly review produces the following decisions. This is a walkthrough, not the result of operating the process for two weeks.

Decision point	SQN-30	Weekly handling	Release handling
End of week 1, with mobile checks remaining	Keep unfinished	Close the week and select checks that can be performed next week	Incomplete
End of week 2, if development acceptance is satisfied	Can be Done	Record completion in that week	Incomplete while distribution work remains
After distribution and target-version checks	Keep Done	Record distribution results in the relevant week	Compare against module acceptance before completing it

Repeatedly extending the first week would obscure what was accomplished within the original period. Closing that period and selecting remaining work again gives the plan and outcome a stable boundary for comparison.

Carryover should also include a reason. Here, it could say that mobile permission displays and access restrictions remain to be checked, with the web results linked at a fixed commit. Confirm that the required devices will be available in the next week. Transferring everything, including work that cannot be performed then, turns the next plan into storage.

Preserve the agreed scope when deciding completion

Removing acceptance conditions merely because verification missed a date changes the intended deliverable. Adding store distribution to a development-only ticket creates the opposite problem: work satisfying the original scope can no longer close.

If scope must change, record what moves to another release and how the current acceptance conditions change. Preserve a reason for work removed from a module too. Simply unlinking it makes the original plan indistinguishable from a plan that never included it.

In this example, development acceptance and production rollout were separate from the beginning. Keeping that distinction allows SQN-30 to close when appropriate while leaving release preparation visible.

Do not change the facts to tidy the first weekly report

The evidence here consists of existing ticket scope, a fixed verification document, and official behavior. It does not include a live cycle transfer experiment or measurements of module progress displays.

An initial adoption could use one feature to check whether unfinished work remains identifiable as it moves into the next plan. Then check whether development completion and distribution completion can be read separately. For this case, record why the work remains and which device or behavior needs checking next.

When Strict Mode reruns Effects: inspect subscription setup and cleanup

hiro@ — Fri, 30 Oct 2026 03:10:31 +0000

When Strict Mode logs an Effect setup twice, check whether cleanup ran between the setups and how many subscriptions remain. Reducing the setup count to one does not establish that cleanup works.

A small subscription was compared in React 19.3.0 development and production builds. Initial behavior also differed between wrapping the root in Strict Mode and wrapping only part of the tree.

Count registration and removal without external communication

The test subscription target is a Set. Setup registers a handler, and a local button invokes all registered handlers. There are no network connections or notification services.

function Subscription({ room, cleanup }) {
  useEffect(() => {
    const handler = () => trace.events.push(`message:${room}`);
    trace.active.add(handler);
    trace.events.push(`setup:${room}`);
    if (cleanup) {
      return () => {
        trace.active.delete(handler);
        trace.events.push(`cleanup:${room}`);
      };
    }
  }, [room, cleanup]);
  return <output id="room">{room}</output>;
}

trace.active contains registered handlers, and trace.events records their order. The normal version uses cleanup: true; the deliberately incomplete comparison uses false. The room can change from A to B, and the root is unmounted at the end.

Separate bundles were built with development and production values for process.env.NODE_ENV. In the root-wide condition, <StrictMode> wraps the element rendered by createRoot. In the partial condition, it wraps only Subscription beneath a parent outside Strict Mode.

Placement changed initial setup and cleanup

Build and placement	Initial setups	Initial cleanups	Handlers remaining after initial processing
Development, root Strict Mode, with cleanup	2	1	1
Development, no Strict Mode, with cleanup	1	0	1
Development, child-only Strict Mode, with cleanup	1	0	1
Production, root Strict Mode, with cleanup	1	0	1
Development, root Strict Mode, without cleanup	2	0	2

The normal development root logged setup:A → cleanup:A → setup:A during initial processing. It removed the earlier subscription before setting it up again.

The official Strict Mode documentation distinguishes the extra development setup/cleanup cycle from the condition where initial Effects are not rerun because Strict Mode does not wrap the root. Check where Strict Mode is placed before interpreting repeated Effect logs.

The table counts Effect work. It does not establish component-function invocation counts or DOM painting counts.

Omitting cleanup accumulated handlers

Pressing the local notification button once after initial setup logged one message:A with cleanup and 2 without it. The next step changed the room to B.

Development root condition	After initial registration	After changing room	After unmount
With cleanup	1	1	0
Without cleanup	2	3	3

The normal version logged cleanup:A → setup:B on the room change and cleanup:B on unmount. Without cleanup, the A handlers remained while a B handler was added. They stayed in the Set after unmount too.

The comparison shows what remains when the implementation omits its removal step. Each case discards its Set; the incomplete version was not integrated into an application.

Check the matching teardown before limiting calls

For this example, the fix is to remove the same handler that setup registered. A room change removes the old room's subscription before registering the new one. The useEffect reference describes cleanup with previous values followed by setup with the new values when dependencies change.

This experiment does not apply the extra-execution scenario to API writes, payments, or email delivery. Its scope is a subscription with matching registration and removal. If real logs differ, investigate actual unmounts and remounts or development-tool updates as well as Strict Mode placement.

The tests ran on September 11, 2026, with React and React DOM 19.3.0, Node.js 24.15.0, esbuild 0.28.2, macOS arm64, and Headless Chrome 152 and no React Compiler. The fixture code and results for the 5 conditions include room changes and unmounts as well as initial processing.

How index keys affect inputs: compare DOM, row state, and parent state

hiro@ — Thu, 29 Oct 2026 03:06:24 +0000

When the first row is removed from a React list, do input values stay with the remaining rows? With index keys, the result depended on who owned the value.

An uncontrolled input, whose value lived in the DOM, and an input backed by row-local state displayed another row's value. Inputs receiving values from parent state displayed the correct values, but their DOM nodes were still reassigned to different rows.

Narrow the reproduction from existing code

The personal project's schedule creation screen passes the idx from rows.map as each Card key. It removes rows with array filtering and inserts duplicates by combining array slices.

However, its title input is controlled through value={row.title}. The code alone does not show whether input values ever became mixed up in production. The inspected commit was 770de5f. Related history and design material were also checked before extracting row deletion and value ownership into a separate experiment. The application was neither modified nor used to submit data.

Removing the first row shifts index-based identities

The fixture starts with 3 rows: A, B, and C. B is edited to edited-B, then A is removed. Simply reversing the order after editing B would leave B in the middle of a 3-row list, so deletion makes the identity change visible here.

import React, { useState } from 'react';

const initialRows = [
  { id: 'A', title: 'Alpha' },
  { id: 'B', title: 'Beta' },
  { id: 'C', title: 'Gamma' },
];
function Row({ row, mode, update }) {
  const [localTitle, setLocalTitle] = useState(row.title);
  const props = mode === 'uncontrolled'
    ? { defaultValue: row.title }
    : mode === 'local'
      ? { value: localTitle, onChange: event => setLocalTitle(event.target.value) }
      : { value: row.title, onChange: event => update(row.id, event.target.value) };
  return <label data-row={row.id}>{row.id}<input {...props} /></label>;
}
export function KeyExperiment({ keyMode, mode }) {
  const [rows, setRows] = useState(initialRows);
  function update(id, title) {
    setRows(previous => previous.map(row => row.id === id ? { ...row, title } : row));
  }
  return <section>
    <button id="remove-first" onClick={() => setRows(previous => previous.slice(1))}>Remove first</button>
    {rows.map((row, index) => (
      <Row key={keyMode === 'index' ? index : row.id} row={row} mode={mode} update={update} />
    ))}
  </section>;
}

mode is uncontrolled, local, or parent; keyMode is index or id. The local version initializes each row with useState(row.title). The parent version updates the array by row ID.

Before deletion, a WeakMap records each input's DOM node and row ID. After deletion, the test compares values and node origins. This is fixture instrumentation, not access to React's internal keys.

Value owner	Key	Values displayed for B / C after deletion	Original rows of the nodes used for B / C
DOM	index	Alpha / edited-B	A / B
DOM	id	edited-B / Gamma	B / C
Row state	index	Alpha / edited-B	A / B
Row state	id	edited-B / Gamma	B / C
Parent state	index	edited-B / Gamma	A / B
Parent state	id	edited-B / Gamma	B / C

With index keys, B gets key 0 and C gets key 1 after deletion. Those keys previously corresponded to A and B. defaultValue and a row's initial state are not reapplied from scratch for every new row occupying that position.

With ID keys, B remains key B even after moving. Its edited value and DOM node stayed with that row. React's explanation of list keys describes their role in matching items through deletion, insertion, and reordering.

Controlled values do not settle the identity question

In the parent-state version, React passed the new row.title to each input, so the displayed values were correct. The 6 cases therefore do not support a claim that index keys always produce incorrect displayed values.

The WeakMap still identified the reused nodes as coming from A / B. Correct values alone do not prove that row, component, and DOM identities were preserved. The experiment did not measure focus, IME composition, or DatePicker internal state. It therefore does not establish failures in those parts of the real application either.

For a design that adds and removes rows, storing a row ID in the data and keeping it as the key for the row's lifetime expresses the intended identity. Unsaved rows can receive an ID when created, and a duplicate treated as a separate row can receive a new ID. Generating IDs during every render would not provide stable matching. This is a proposed change for the existing screen, not an applied fix.

The tests ran on September 11, 2026, with React and React DOM 19.3.0, Node.js 24.15.0, esbuild 0.28.2, macOS arm64, and Headless Chrome 152. They used a production build without Strict Mode or React Compiler. The minimal code and results for the 6 conditions track displayed values and DOM nodes separately.

Cancelling timers with AbortController: seven cases including cleanup

hiro@ — Wed, 28 Oct 2026 02:45:42 +0000

AbortController is not limited to fetch. Calling abort() does not stop an arbitrary Promise, though. The operation must accept the signal and implement both stopping its wait and rejecting its Promise.

A small timer function was tested with cancellation before it started, while it was waiting, and after completion. The check covered not only rejection, but also whether abort listeners remained after the operation ended.

Implement a delay that handles cancellation

Save this function as cancellable-delay.mjs. It is an implementation for this experiment, not code already integrated into an existing application.

export function delay(ms, signal) {
  return new Promise((resolve, reject) => {
    if (signal.aborted) {
      reject(signal.reason);
      return;
    }
    const cleanup = () => signal.removeEventListener('abort', onAbort);
    const onAbort = () => {
      clearTimeout(timer);
      cleanup();
      reject(signal.reason);
    };
    const timer = setTimeout(() => {
      cleanup();
      resolve('finished');
    }, ms);
    signal.addEventListener('abort', onAbort, { once: true });
  });
}

If the signal is already aborted, the function immediately rejects with its reason. Otherwise it registers a timer and an abort listener. On cancellation, it clears the timer, removes the listener, and rejects.

Normal completion also removes the listener. { once: true } removes a listener after an abort event occurs; it does not replace cleanup for an operation that finishes normally.

The DOM requirements for abortable APIs describe checking whether the signal is already aborted when starting and rejecting an unfinished operation with the abort reason. This function follows that flow.

Stop multiple timers with the same signal

Place this executable example in the same directory:

import { delay } from './cancellable-delay.mjs';

const controller = new AbortController();
const group = Promise.allSettled([
  delay(10000, controller.signal),
  delay(10000, controller.signal),
]);
const reason = new Error('screen closed');
controller.abort(reason);
const results = await group;
console.log(results.map(result => result.status));
console.log(results.every(result => result.reason === reason));

It printed [ 'rejected', 'rejected' ] followed by true. Both timers received the same signal and rejected with the same Error object. Promise.allSettled collected their outcomes; the abort handling inside delay stopped the timers.

The example creates the aggregate Promise before cancelling. This establishes a path to receive rejection outcomes before calling abort.

Verify cleanup under 7 conditions

The tests ran on September 11, 2026, with macOS arm64 and Node.js 24.15.0. Node.js getEventListeners was used to inspect abort listener counts for the custom function.

Condition	Observation
Abort before calling the function	Rejected with the same reason; 0 remaining abort listeners
Abort 2 timers sharing a signal	Both rejected; registered listeners went from 2 to 0
Abort after normal completion	Still fulfilled; listener count was already 0 at completion
Include an operation without a signal	Only the cooperative operation rejected; the other completed
Abort a Node.js Promise-based timer	Rejected with AbortError; its `cause` was the supplied reason
Combine a manual signal and timeout with `AbortSignal.any`	Custom delay rejected with the manual abort reason
Let only the timeout fire	Custom delay rejected with TimeoutError

The waiting cases registered 10000-millisecond timers before cancellation. Normal completion used 0 milliseconds; the firing timeout used 1 millisecond. These values drive state transitions. They are not measurements of execution time or cancellation latency.

The custom delay cleared its timer after rejection, and the Node.js process exited. Together with the listener checks, this confirmed that the implementation did not merely reject its Promise while leaving a long-running timer behind.

APIs can expose cancellation reasons differently

The custom delay passes signal.reason directly to reject. In contrast, the node:timers/promises case supplied an Error as the reason but received a separate AbortError whose cause was the original reason.

Node.js Promise-based timers already support AbortSignal cancellation. They are an option for waits specific to Node. The custom implementation here makes the operation's cleanup responsibilities visible.

AbortSignal.any combines signals and takes the reason from the first signal that aborts. Check support in the target runtime for it and AbortSignal.timeout. Both are covered in the Node.js AbortSignal reference.

An operation without the signal continues

One of the 7 conditions paired a cancellation-aware delay with a Promise-based timer that received no signal. After abort, the first rejected, but the second's completion flag became true. Having a controller available in a shared variable does not enroll an operation in cancellation.

This experiment also did not test forcibly stopping a synchronous loop that occupies the CPU. Nor does it establish that cancelling a network request rolls back a remote server's work or previously stored data. It verifies cooperative signal handling for waits in the same process.

The custom function, test code, and results for the 7 conditions are available. When adding cancellation, check the initial aborted state, resource release on cancellation, and listener removal on normal completion as parts of the same operation.

Comparing structuredClone and JSON copies through values and reference identity

hiro@ — Tue, 27 Oct 2026 02:36:56 +0000

Copying an object with JSON.parse(JSON.stringify(value)) can succeed while changing what the data means. In this experiment, the changes went beyond turning a Date into a string: Map contents and relationships between references changed too.

The two approaches were compared on Node.js 24.15.0. Specify which values need copying and which reference relationships the copy must retain.

Check values and references together

This example uses synthetic data resembling an article draft, not real user records. The experiment ran on September 11, 2026. The JSON roundtrip used no replacer, reviver, or custom toJSON method.

const row = { id: 'draft-1', status: 'ready' };
const source = {
  createdAt: new Date('2026-09-11T00:00:00.000Z'),
  counts: new Map([['ready', 2]]),
  memo: undefined,
  slots: [undefined],
  left: row,
  right: row,
};
const cloned = structuredClone(source);
const jsonCopy = JSON.parse(JSON.stringify(source));
console.log(cloned.createdAt instanceof Date, typeof jsonCopy.createdAt);
console.log(cloned.counts.get('ready'), jsonCopy.counts);
console.log(Object.hasOwn(cloned, 'memo'), Object.hasOwn(jsonCopy, 'memo'));
console.log(cloned.slots[0], jsonCopy.slots[0]);
console.log(cloned.left === cloned.right, jsonCopy.left === jsonCopy.right);

It printed:

true string
2 {}
true false
undefined null
true false

The structured clone's Date and Map remained usable as those types. The JSON copy contained a string for the Date and an empty object for the Map. Its memo: undefined property disappeared, while undefined inside the array became null.

The final line matters for some copying requirements. Originally, left and right referenced the same row. The structured clone kept them pointing at the same copied object. The JSON roundtrip made separate objects. Neither approach retained a reference to the original row. The HTML structured serialization specification defines bookkeeping that avoids processing an object twice and preserves cycles and reference identity.

Success alone does not establish the intended copy semantics

The experiment tested 12 separate inputs. These are representative results:

Input	structuredClone	JSON roundtrip
Date	Date	ISO-formatted string
Map	Map containing entries	Empty object
undefined in an object	Key and value retained	Key removed
undefined in an array	undefined element	null element
NaN, Infinity, -0	Properties of each value retained	null, null, 0
Two properties referencing the same child	Copied properties share a child	Copied properties have separate children
Circular reference	Cycle retained in the copy	TypeError
Object containing BigInt	bigint value retained	TypeError
Object with a function property	DataCloneError	Function key removed

The JSON cases that removed a function or undefined property did not throw. A test that checks only for exceptions misses those changes. The ECMAScript JSON specification also distinguishes serialization by value type and by its position in an object or array.

The comparison used instanceof, Object.hasOwn, Object.is, and reference === checks. Comparing only JSON strings cannot test properties that serialization itself removes.

structuredClone does not fully duplicate class instances

The remaining 3 cases examined a class, frozen state, and a getter.

Copying a custom Draft instance retained its ordinary title data property. However, instanceof Draft was false, and the prototype's label() method was absent. The JSON roundtrip produced the same observations.

Copies made from Object.freeze({ count: 1 }) were not frozen under either method, and count was writable. For an object with a getter, both methods invoked it while reading the value. The copy contained an ordinary property with the value 2. Copying once with each method invoked the getter a total of 2 times.

These results support using class-specific construction when the goal includes reproducing a domain object's behavior. Copying this class did not produce another instance with the same callable methods.

Transfer does not leave the original buffer available

const bytes = new Uint8Array([1, 2, 3]);
const moved = structuredClone(bytes, { transfer: [bytes.buffer] });
console.log(bytes.byteLength, [...moved]);

This printed 0 [ 1, 2, 3 ]. The destination retained the values, while the original ArrayBuffer was detached. If another operation still needs the source buffer, this cannot be treated as an ordinary copy. Node.js structuredClone provides the WHATWG API with this transfer option.

The experiment measured differences in values, references, and exceptions. It did not compare speed, memory use for large inputs, or browser-specific objects such as DOM elements. A protocol that exchanges JSON still needs conversion to that format. This experiment helps identify which changes are acceptable when reusing a JSON roundtrip for an in-memory copy.

The execution script and results for the 12 cases and transfer record the shape of each copy as well as whether copying succeeded.

What remains without import type? Comparing tsc, esbuild, and side effects

hiro@ — Mon, 26 Oct 2026 01:58:59 +0000

Some configurations automatically erase an import used only as a type, even without import type. With verbatimModuleSyntax: true, however, the spelling also changed whether a module's side effect ran. Check type-checking success separately from runtime module evaluation.

In particular, these forms do not always emit the same JavaScript:

import type { Ticket } from "./registry.js"
import { type Ticket } from "./registry.js"

Put a visible marker in the imported module

The experiment ran on September 11, 2026, with macOS arm64, Node.js 24.15.0, TypeScript 7.0.2, and esbuild 0.28.2. Compiler options were strict: true, target: ES2022, module: ESNext, and moduleResolution: Bundler. esbuild targeted Node ESM with bundling and tree shaking enabled. The test package did not declare sideEffects: false.

registry.ts contains only a type and a log showing that the module was evaluated. It performs no external requests or real application initialization.

export interface Ticket { title: string }
console.log("registry evaluated");

The caller starts with this code:

import { Ticket } from "./registry.js";
const ticket: Ticket = { title: "Fix timer" };
console.log(ticket.title);

Only the import was changed when comparing emitted JavaScript and runtime logs. In the personal repository, the type-sharing package exposes API types through export type. The Ticket and log here are a minimal example designed to separate type references from runtime loading.

Both spelling and configuration affected the result

In this table, "evaluation" means the log printed registry evaluated. Every successful example also printed the caller's Fix timer message.

Import form	verbatim	tsc	Registry evaluation in tsc output	Registry evaluation in esbuild bundle
`import { Ticket }`	false	Pass	No	No
`import type { Ticket }`	false	Pass	No	No
`import { type Ticket }`	false	Pass	No	No
Side-effect import + `import type`	false	Pass	Yes	Yes
`import { Ticket }`	true	TS1484	Emit stopped	Yes
`import type { Ticket }`	true	Pass	No	No
`import { type Ticket }`	true	Pass	Yes	Yes
Side-effect import + `import type`	true	Pass	Yes	Yes

The test used noEmitOnError: true, so no tsc-generated JavaScript was executed for the TS1484 row. esbuild bundled that input successfully, but that does not mean it passed type checking.

An inline type modifier left an empty import

This is the tsc output for import { type Ticket } with verbatimModuleSyntax: true:

import {} from "./registry.js";
const ticket = { title: "Fix timer" };
console.log(ticket.title);

The name Ticket disappeared, but import {} from "./registry.js" remained. That dependency still evaluates the module, so the marker was printed. Making the entire statement type-only with import type { Ticket } removed the statement and the log. The official verbatimModuleSyntax documentation also distinguishes these outputs.

When only a type is needed, use a whole-statement import type. When initialization is also required, make that a separate import:

import "./registry.js";
import type { Ticket } from "./registry.js";
const ticket: Ticket = { title: "Fix timer" };
console.log(ticket.title);

This printed the marker under both settings and both tools tested here. That does not establish the same outcome for dependencies marked as free of side effects or for other bundler configurations. This experiment observes two local files.

Successful bundling does not establish type correctness

export const count: number = "wrong";
console.log(typeof count);

tsc reported TS2322, while esbuild succeeded and the bundle printed string. The esbuild TypeScript caveats explain that TypeScript's type checker is responsible for checking the annotations.

Marking dependencies as type-only and running type checking in the build process address different concerns. In this reproduction, an input could run after import removal while still containing a mistake tsc detected. Bundle success alone did not catch that mistake.

Run the T06 cases in the comparison inputs with the execution script to inspect the combined diagnostics, emitted JavaScript, and logs. When introducing the setting into an application, inspect type-only references and imports intended for initialization separately.