Client side navigation interruptibility

[hi-ogawa]

• example https://rsc-experiment-hiroshi.vercel.app/test/transition

There was something magical possible (thought probably it wasn't really fool proof when navigation multiple layout quickly) when using sync transition and async setState.

Now, we moved to async transition (in #564) and it's not possible to interrupt and start new client side navigation while the last one is pending.

Probably having async transition is actually mandatory to have robust error handling (e.g. const res = await fetch(), then check res.status, res.headers cf. #386). But having interruptible client side navigation in case of slow flight server stream seems quite an important feature, so we'll probably need to rework something huge to get this right (but hopefully we don't have to introduce entire reducer...?)

vite-plugins/packages/react-server/src/entry/browser.tsx

Lines 162 to 172 in c5ce9a1

	startTransition(async () => {
	const response = await fetch(request);
	if (handleFlightRedirectResponse(history, response)) {
	return;
	}
	$__setFlight(
	ReactClient.createFromFetch<FlightData>(Promise.resolve(response), {
	callServer,
	}),
	);
	});

vite-plugins/packages/react-server/src/entry/browser.tsx

Lines 104 to 123 in c5ce9a1

	// very shaky trick to merge with current layout
	$__setFlight = (nextPromise) => {
	setFlight(
	memoize(async (currentPromise: Promise<FlightData>) => {
	const current = await currentPromise;
	const next = await nextPromise;
	return {
	action: next.action,
	metadata: next.metadata,
	segments: next.segments,
	url: next.url,
	nodeMap: {
	...current.nodeMap,
	...next.nodeMap,
	},
	layoutContentMap: next.layoutContentMap,
	} satisfies FlightData;
	}),
	);
	};

todo

• research Next.js and others