fixes NEXT-164
## Context
This PR fixes an issue happening when using `next/image` or `next/link` where rendering them caused sync re-renders with React. This breaks [selective hydration](https://github.com/reactwg/react-18/discussions/130) in React.
## The fix
The cause of this behaviour is that we're calling `setState` in a ref mount, which basically "forces" React to disable concurrent rendering. It finishes the render, runs synchronously the passive effects and re-renders again to make sure that everything is in sync, all of that in without yielding to the browser to paint.
Here in this case, the `setState` call is because of the `useIntersectionObserver` hook. It's implemented in a way that requires the user to call a setter that will store the ref value in a component state variable to re-trigger a render and re-run the effect to create the intersection observer.
This is not necessary as the ref init phase always runs before the passive effect runs, so we can just copy the ref to another ref inside `useIntersectionObserver` without triggering a re-render.
## Before/After
1st screenshot: before
2nd screenshot: after
Basically on the first screenshot, you can see that React is doing a synchronous re-render (see `flushPassiveEffects`). This is not good.
If you look at screenshot 2, you can see it does not happen anymore and that the passive effects are flushed in another block in the flamegraph.
<img width="1110" alt="CleanShot 2023-01-23 at 14 30 11@2x" src="https://user-images.githubusercontent.com/11064311/214051860-c42d2849-cd10-4922-a3e0-9b715fc87b23.png">
<img width="520" alt="CleanShot 2023-01-23 at 14 29 01@2x" src="https://user-images.githubusercontent.com/11064311/214051555-04adf516-9c0b-4056-ac65-1ef33614c767.png">
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
- Add support for scrolling to the sides and down when navigating
- Add tests for vertical scrolling
- Add tests for horizontal scrolling
- Add tests for `router.refresh()`
- should not scroll by itself
- should not block router.push from scrolling
- should not scroll when page refreshed using fash refresh
- Scroll to the top of document if that gets page into viewport
- I didn't want to implement some heuristics on if we can scroll to the top of the page so I just scroll there and check.
- This implementation may not play well with some nested scrollable containers (but that never worked, just FYI)
- Improved typings on `BrowserInterface` a little - backward compatible change.
Co-authored-by: Shu Ding <3676859+shuding@users.noreply.github.com>
The version spec for [convex](https://www.npmjs.com/package/convex) in the convex example was `latest`, which meant developers who created a project with this example during the period of time between a new convex release with non-back compatible changes and an update to the demo in this repo would have broken projects. For less stress all around, let's pin the version here!
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm build && pnpm lint`
- [x] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
## Bug
Previously the `React.lazy` and Loadable preloading are creating different module loading promises with loader. Now we change to wait the loader in `React.lazy` to make sure for SSR case they're preloaded. The case to trigger this bug is: When adding `Document.getInitialProps` (aka. gIP), rendering goes to process the gIP first which would make the lazy elements executed before gIP, then preloading will happen after lazy which leads to Suspense resolves too fast without content.
Fixes#45151
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
We couldn't swithc before because `pnpm` was not bundling files in `native` but that was caused by differences between `yarn` and `pnpm` implementation.
Since we now call `loadConfig()` in various processes our `execOnce`
handling isn't tracking when we have already shown warnings/logs in
another process so this adds a `silent` flag that we can leverage when
calling `loadConfig()`.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
Fixes: [slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1674351677627259)
