DEV Community: hiro@

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.

Inspect emitted JavaScript before replacing enums with literal unions

hiro@ — Sun, 25 Oct 2026 01:57:23 +0000

If a state only needs to be constrained to "ready" or "waiting" in the type system, a literal union can express that. If code must also refer to a named value such as State.Ready at runtime, it needs a value object as well.

Separate those requirements when comparing an enum, a literal union, and an as const object. A regular enum emits JavaScript; it is more than another spelling for a type.

Emit the same states in four forms

The experiment ran on September 11, 2026, with macOS arm64, Node.js 24.15.0, and TypeScript 7.0.2. The build used strict: true, target: ES2022, module: ESNext, and moduleResolution: Bundler.

export enum NumericState { Ready, Waiting }
export enum StringState { Ready = "ready", Waiting = "waiting" }
export type State = "ready" | "waiting";
export const StateValue = { Ready: "ready", Waiting: "waiting" } as const;
export const selected: State = "ready";
console.log(JSON.stringify({ numeric: NumericState, string: StringState, object: StateValue, selected }));

The log contained the following values. The emitted JavaScript was inspected as well.

Definition	What remained at runtime
Numeric enum	`Ready: 0` and `Waiting: 1`, plus reverse mappings `0: "Ready"` and `1: "Waiting"`
String enum	`Ready: "ready"` and `Waiting: "waiting"`
Literal union `State`	The type disappeared; the value `"ready"` assigned to `selected` remained
`as const` object	`Ready: "ready"` and `Waiting: "waiting"`

The numeric enum's reverse mapping, and its absence from the string enum, match the official enums reference. Reverse lookup is a runtime capability of the numeric enum. If the application does not use it, it need not be a selection requirement.

Derive the value union from an object

export const StateValue = { Ready: "ready", Waiting: "waiting" } as const;
export type State = typeof StateValue[keyof typeof StateValue];
export const value: State = "ready";
console.log(value, Object.isFrozen(StateValue));

StateValue holds the named values, and the object supplies the allowed value type. Assigning "ready" to State passed, and the log printed ready false. Object.isFrozen was false because as const does not freeze objects at runtime.

The string enum did not accept a direct assignment merely because the string matched a member's value:

enum State { Ready = "ready", Waiting = "waiting" }
const value: State = "ready";
export {};

This produced TS2322. A string received externally cannot simply be treated as an enum value. A literal union does not establish that an arbitrary, unchecked string is safe either; external input still needs runtime validation.

Whether const enum disappears also depends on configuration

The following input was compiled with only isolatedModules changed:

const enum State { Ready = "ready", Waiting = "waiting" }
export const value = State.Ready;
console.log(value);

With isolatedModules: false, the value was inlined in the emitted JavaScript:

export const value = "ready" /* State.Ready */;
console.log(value);

With isolatedModules: true, code constructing the State object and accessing State.Ready remained. Both versions printed ready. Do not expect every build pipeline to erase the object just because the declaration says const enum.

This comparison defines and uses the enum in the same source file. It does not test ambient const enums in a published library's .d.ts files or mismatched versions between a definition and its consumers.

Type stripping makes the syntax constraint visible

With erasableSyntaxOnly: true, both the regular enum and const enum produced TS1294. The literal union and as const object example passed. This option avoids syntax that needs transformation into JavaScript. The official configuration reference lists the affected constructs.

Directly running a .ts file containing the regular enum on Node.js 24.15.0, without transformation options, also produced ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX. Node.js TypeScript support distinguishes execution through type stripping from features that require syntax transformation.

A literal union is a candidate when only a type is needed. Deriving a union from an object also provides named runtime values. If existing code depends on enum reverse lookup or a public enum API, inspect those consumers before changing it. This output comparison does not establish a bundle-size or execution-speed advantage.

The T05 cases in the comparison inputs and the compiler and runtime results preserve the details. Compare alternatives under the runtime requirements and transformation settings the application will actually use.

Claim guest responses by transferring control of a record, not matching a name

hiro@ — Sat, 24 Oct 2026 02:11:29 +0000

Someone answers an event invitation without logging in and later wants to change the response. Using their name as proof of identity cannot distinguish namesakes or a different person logging in on a shared device.

SquadNote issues a token controlling one response instead of creating a placeholder user row. Later login does not automatically match names: the person reviews the target responses and explicitly claims them for the account.

A response token grants control of a record; identifying a person requires separate evidence. This investigation read the design, migration, API, and device-storage code at circle-hub commit 9aec489, then reran related tests on September 11, 2026.

Add response ownership before building an organization roster

The design document separates adding control to existing guest_attendance records from a future organization-level provisional membership feature.

The implemented stage is the former. Ownership belongs to an event response, supporting listing, editing, and account claiming without treating a matching name as proof of identity.

The migration SQL adds these columns:

Column	Purpose
`ownership_token_hash`	Hash used to verify unauthenticated control of the response
`claimed_by_user_id`	Account that claimed it
`claimed_at`	Claim time
`attending_since`	Time the response became attending
`updated_at`	Update time

Existing responses do not receive ownership tokens retroactively. Matching a name does not grant control over past responses. How preexisting rows participate in a new feature is part of the migration contract.

Separate the response ID from its operation token

The response ID locates the target. It does not authorize editing by itself; the token returned when the response was created must also be verified.

The token implementation generates 32 bytes with crypto.getRandomValues() and represents them as 43 base64url characters. Only the SHA-256 hash enters the database. The Web Crypto specification defines that method as a source of cryptographically strong random values.

This creates a string granting control. It does not prove that its holder is the person named in the response. The model permits whoever holds a valid token to operate on that record.

Keeping plaintext out of the database prevents simply replaying the stored hash as the operation key. It does not remove the need to protect the original token on the client.

Losing storage can remove control without deleting the response

The implementation stores response IDs and tokens in Web localStorage and mobile SecureStore. Tokens are kept out of URLs; the necessary references are sent to listing and mutation APIs.

Web storage parsing discards malformed rows and returns an empty array if reading fails. That prevents a crash. It does not establish that no database responses exist or recover the person's responses.

The saved-reference limit is 100. Clearing storage, opening another device, or dropping an old reference beyond that limit has no implemented name-based recovery path. Automatic cross-device synchronization is also outside this stage.

As OWASP's localStorage guidance explains, JavaScript-readable storage is exposed to XSS. Placing these values in localStorage does not make them secure by itself. This investigation did not audit the application's complete XSS defenses or storage on physical devices.

Claim after login and confirmation, then remove the old key

After login, the screen displays locally saved responses and calls the claim API only through an explicit action. Logging another account into a shared device does not automatically attach those responses to it.

After checking the authenticated account and token, the claim API updates:

.set({
  claimedByUserId: ctx.session.user.id,
  claimedAt: new Date(),
  ownershipTokenHash: null,
})

This is the update object excerpted from the implementation. Surrounding code checks the session, existing claimant, and token. The update condition also retains the response ID, an unset claimant, and the original token hash. Filtering is therefore present at the write as well as during the preceding check.

Only successful IDs are removed from device storage. Subsequent access uses the logged-in user's ID. Rejecting reassignment to another account and clearing the old token hash define the transfer of control.

The API processes multiple responses sequentially and returns claimedIds and rejectedIds. The client must not treat the whole list as successful and delete every reference. Separate results preserve which records actually transferred when some were rejected.

What the 15 rerun tests covered

All 15 tests in 3 related files passed from the fixed commit. The run used Node.js v24.15.0 and Vitest 4.1.4 in a temporary copy, without changing the original working directory.

Target	Checked behavior
Token functions	Encoding, different generated values, correct hash verification
Response API	Wrong-token rejection, valid references, ownership data omitted from public output
Visibility	Responses for an event made private are omitted from the locally saved list
Claiming	Reassignment rejection, hash clearing, and the branch that does not report an update as successful after a conflict
Web storage	Malformed data, replacement of the same response ID, removal of successful IDs only

The token functions use the actual randomness and hashing APIs. API tests invoke the actual router but mock the database and notifications. They do not reproduce SQL predicate evaluation or multiprocess races in real D1.

The runner and results preserve that scope. This run did not exercise SecureStore on physical mobile devices or operate the claiming screen.

Do not infer personal identity from control of a response

Implemented behavior consists of record-level tokens, management from the same device, and explicit transfer to an account. A provisional organization roster, automatic retrieval of past responses by name, and cross-device synchronization remain separate future features.

Before expanding guest convenience, specify what possession of each credential permits. Keeping control of one response from implicitly granting control of namesakes' responses or roster entries makes the next identity-verification requirement clearer.

Choosing type or interface by declaration merging and conflict diagnostics

hiro@ — Fri, 23 Oct 2026 02:12:35 +0000

A useful starting point for choosing type or interface is whether other declarations should be allowed to extend the same named contract. Both can describe ordinary objects, but adding declarations and combining conflicting properties produce different diagnostics.

Compiling small examples with TypeScript 7.0.2 gave these results:

Operation	Result
Add a different property through another declaration of the same `interface`	Declarations merge; the added property is also required
Redeclare the same `type` name	TS2300
Change `id: string` to `id: number` through `interface extends`	TS2430 at the extending declaration
Define `{ id: string } & { id: number }`	Definition passes; `id` becomes `never`
Assign `{ id: 1 }` to that intersection	TS2322 at the assignment

Merging an interface also affects existing consumers

export interface Ticket { title: string }
export interface Ticket { traceId: string }
export const ticket: Ticket = { title: "Fix timer", traceId: "local-1" };
console.log(ticket.traceId);

This compiles, runs, and prints local-1. The second declaration adds a member to the same Ticket; it does not create a derived type with a different name. An object that omits traceId now produces TS2741.

The official declaration merging documentation describes how interface members merge and the matching-type requirement when a non-function member is declared again. This experiment covers the case of adding a different property.

A library can use this behavior as an extension contract for consumers. Adding a required member, however, also changes type checking for existing code. This does not mean identical names in arbitrary files automatically merge across an entire project. The declarations must resolve to the same target in the relevant scope. Real library extensions may also require mechanisms such as module augmentation.

This is a composition experiment within one module, not an implemented extension for a particular library.

Preventing redeclaration is different from restricting values exactly

type Ticket = { title: string };
type Ticket = { traceId: string };
export {};

Declaring both aliases in the same module produces TS2300 on both declarations. That does not mean using type always rejects extra object properties.

type Ticket = { title: string };
const input = { title: "Fix timer", debug: true };
const ticket: Ticket = input;
console.log("debug" in ticket);

This passed and printed true. The annotation did not remove debug at runtime. Whether an alias can be reopened for declaration merging is separate from whether a value is structurally assignable. Everyday types covers the shared capabilities of aliases and interfaces and their difference in declaration merging.

Check where a composition conflict fails

interface TextId { id: string }
interface NumericId extends TextId { id: number }
export {};

This fails at the declaration of NumericId. Replacing id with a number means it no longer satisfies TextId.

An intersection instead requires both conditions at once:

type TextId = { id: string };
export type Combined = TextId & { id: number };
type IsNever<T> = [T] extends [never] ? true : false;
export const check: IsNever<Combined["id"]> = true;
console.log(check);

The definition itself passed. A small conditional type confirmed that Combined["id"] was never, and assigning true to check also passed. The property would need to satisfy both string and number.

Assigning { id: 1 } to this Combined then produced TS2322. The & operator does not overwrite a shared property with the type on its right. A combined type can be declared even when it has no usable value.

What these results justify

An interface is a candidate when declaration merging is an intentional extension point for consumers. Use type to name alternatives such as a union. For application object types that either form can express, following the existing code convention is reasonable. This experiment did not establish a reason to rewrite all such declarations into one form.

The tests ran on September 11, 2026, with macOS arm64, Node.js 24.15.0, TypeScript 7.0.2, strict: true, target: ES2022, module: ESNext, and moduleResolution: Bundler. Type declarations disappeared from the emitted JavaScript; the object and logging code remained. Compiler performance and large module-augmentation setups were not measured.

The T04 cases in the reproduction code and the diagnostics and emitted files show whether each error occurs at declaration or assignment.

Comparing satisfies, type annotations, and assertions through compiler output

hiro@ — Thu, 22 Oct 2026 02:07:14 +0000

Use satisfies when a configuration value should meet a type while its individual properties remain convenient to use. Two common shortcuts are misleading, though: that it can never affect inference, and that it always rejects extra keys.

The comparison uses the same object under a type annotation, satisfies, and as, with emitted declarations and diagnostics as evidence. For this display configuration, the differences were:

Form	Type when reading `ready`	Missing `waiting`
`: Notices`	`string	number[]`
`satisfies Notices`	`string`	Error
`as Notices`	`string	number[]`

Inspect declarations as well as editor hints

The experiment ran on September 11, 2026, with macOS arm64, Node.js 24.15.0, and TypeScript 7.0.2. The compiler used strict: true, target: ES2022, module: ESNext, and moduleResolution: Bundler, with type checking and declaration emit. The display values are synthetic test data.

type Notices = Record<"ready" | "waiting", string | number[]>;
export const annotated: Notices = { ready: "Ready", waiting: [1, 2] };
export const checked = { ready: "Ready", waiting: [1, 2] } satisfies Notices;
export const asserted = { ready: "Ready", waiting: [1, 2] } as Notices;
console.log(checked.ready.toUpperCase());

checked.ready.toUpperCase() passed and printed READY. Calling the same method on annotated.ready produced TS2339 because the property could also be an array.

The emitted declarations explain that difference:

type Notices = Record<"ready" | "waiting", string | number[]>;
export declare const annotated: Notices;
export declare const checked: {
    ready: string;
    waiting: number[];
};
export declare const asserted: Notices;
export {};

checked retains the types of individual properties. The other two variables have the annotated Notices type. This makes satisfies useful when a configuration needs a shared compatibility check without requiring extra narrowing wherever a particular value is used. The TypeScript 4.9 documentation describes this use of compatibility checks while retaining a useful expression type.

An assertion can leave a missing property undetected

type Notices = Record<"ready" | "waiting", string | number[]>;
const value = { ready: "Ready" } as Notices;
console.log(value.waiting);

This code passed type checking and printed undefined. Changing the assertion to satisfies Notices produced TS2741 for the missing waiting property. An assertion does not create that property.

This also does not mean every possible assertion is accepted. TypeScript can reject an assertion based on the relationship between the types. The finding here is narrower: it accepts this particular object despite the missing required key. As the official explanation of type assertions states, assertions do not validate or convert runtime values.

Context can affect inference

export const plain = { enabled: true, count: 1 };
export const checked = { enabled: true, count: 1 } satisfies { enabled: boolean; count: number };
export const frozenType = { enabled: true, count: 1 } as const;

In the emitted declarations, plain.enabled was boolean, while checked.enabled was true. Both count properties were number. Context from the target type means literal inference is not necessarily identical.

With as const, frozenType.enabled became a readonly true, and frozenType.count became a readonly 1. This does not freeze the object at runtime either. If a configuration will be modified later, decide whether that property should remain the literal true or accept both boolean values, including false.

Extra keys are not always rejected

Writing { ready: "Ready", waiting: [1], typo: 1 } satisfies Notices directly produced TS2353 for the extra typo property. Assigning that object to a variable first changed the outcome:

type Notices = Record<"ready" | "waiting", string | number[]>;
const input = { ready: "Ready", waiting: [1], typo: 1 };
const value = input satisfies Notices;
console.log(value.typo);

This passed and printed 1. A value can satisfy the required structure while retaining additional properties. Restricting the keys of external data requires a runtime check separate from these type constructs.

For the local configuration in this experiment, use satisfies to catch mistakes while retaining operations specific to each value. Use an annotation to specify the type the variable should expose. Reserve as for places where other evidence supports the asserted type.

The T02 cases in the reproduction code and the execution record include both accepted declarations and deliberately invalid inputs. Do not assume diagnostic numbers or inference remain identical across compiler versions; compare declaration output when upgrading.