mirror of
https://github.com/facebook/react.git
synced 2025-11-01 09:12:30 +00:00
Sebastian Markbåge
800c9db22e
This adds navigation support to the View Transition fixture using both `history.pushState/popstate` and the Navigation API models. Because `popstate` does scroll restoration synchronously at the end of the event, but `startViewTransition` cannot start synchronously, it would observe the "old" state as after applying scroll restoration. This leads to weird artifacts. So we intentionally do not support View Transitions in `popstate`. If it suspends anyway for some other reason, then scroll restoration is broken anyway and then it is supported. We don't have to do anything here because this is already how things worked because the sync `popstate` special case already included the sync lane which opts it out of View Transitions. For the Navigation API, scroll restoration can be blocked. The best way to do this is to resolve the Navigation API promise after React has applied its mutation. We can detect if there's currently any pending navigation and wait to resolve the `startViewTransition` until it finishes and any scroll restoration has been applied. https://github.com/user-attachments/assets/f53b3282-6315-4513-b3d6-b8981d66964e There is a subtle thing here. If we read the viewport metrics before scroll restoration has been applied, then we might assume something is or isn't going to be within the viewport incorrectly. This is evident on the "Slide In from Left" example. When we're going forward to that page we shift the scroll position such that it's going to appear in the viewport. If we did this before applying scroll restoration, it would not animate because it wasn't in the viewport then. Therefore, we need to run the after mutation phase after scroll restoration. A consequence of this is that you have to resolve Navigation in `useInsertionEffect` as otherwise it leads to a deadlock (which eventually gets broken by `startViewTransition`'s timeout of 10 seconds). Another consequence is that now `useLayoutEffect` observes the restored state. However, I think what we'll likely do is move the layout phase to before the after mutation phase which also ensures that auto-scrolling inside `useLayoutEffect` are considered in the viewport measurements as well.
48 lines
1.4 KiB
JavaScript
48 lines
1.4 KiB
JavaScript
import React from 'react';
|
|
import {renderToPipeableStream} from 'react-dom/server';
|
|
|
|
import App from '../src/components/App';
|
|
|
|
let assets;
|
|
if (process.env.NODE_ENV === 'development') {
|
|
// Use the bundle from create-react-app's server in development mode.
|
|
assets = {
|
|
'main.js': '/static/js/bundle.js',
|
|
// 'main.css': '',
|
|
};
|
|
} else {
|
|
assets = require('../build/asset-manifest.json').files;
|
|
}
|
|
|
|
export default function render(url, res) {
|
|
res.socket.on('error', error => {
|
|
// Log fatal errors
|
|
console.error('Fatal', error);
|
|
});
|
|
let didError = false;
|
|
const {pipe, abort} = renderToPipeableStream(
|
|
<App assets={assets} initialURL={url} />,
|
|
{
|
|
bootstrapScripts: [assets['main.js']],
|
|
onShellReady() {
|
|
// If something errored before we started streaming, we set the error code appropriately.
|
|
res.statusCode = didError ? 500 : 200;
|
|
res.setHeader('Content-type', 'text/html');
|
|
pipe(res);
|
|
},
|
|
onShellError(x) {
|
|
// Something errored before we could complete the shell so we emit an alternative shell.
|
|
res.statusCode = 500;
|
|
res.send('<!doctype><p>Error</p>');
|
|
},
|
|
onError(x) {
|
|
didError = true;
|
|
console.error(x);
|
|
},
|
|
}
|
|
);
|
|
// Abandon and switch to client rendering after 5 seconds.
|
|
// Try lowering this to see the client recover.
|
|
setTimeout(abort, 5000);
|
|
}
|