Even though we never documented it, the `onLoad` prop used to work (in most cases) in Next.js 12.1.4 and broke in 12.1.5 once the code was refactored in PR #35889.
We still shouldn't document it because `onLoad` doesn't work in all cases so [`onLoadingComplete`](https://nextjs.org/docs/api-reference/next/image#onloadingcomplete) is preferred, however tests were added for the cases that do work.
Use cases that don't work with `onLoad` are Data URLs as well as `loading="eager"`.
The `config` was changed from a global variable to a function parameter of the `loader()` function in PR https://github.com/vercel/next.js/pull/33559 as an implementation detail, not as a public API. It was not meant to be used by the end user which is why it was [undocumented](https://nextjs.org/docs/api-reference/next/image#loader).
This config is meant for the default Image Optimization API. Since the `loader` prop bypasses the default Image Optimization API in favor of a custom function, that config is no longer be relevant because the function can implement the optimization url however it desires.
- Fixes#35115
## History
In PR #24153, `placeholder=blur` was added and it set `element.style.backgroundImage = 'none'` instead of using react state to re-render. Then in PR #25916, a delay was added to handle removing the blur placeholder. Then in PR #25994, `img.decode()` was utilized but we found this caused problems in Firefox in #26011.
## Today
This PR changes the the blur placeholder removal to use react state to re-render. This _should_ prevent Firefox from erroring although we should probably keep the catch() just in case. This was pointed out when React 18 caused subtle differences in Firefox in this comment https://github.com/vercel/next.js/issues/30128#issuecomment-1086754374
* fix(#35286): reset visible state when image src changed
* fix(#35286): reset visible state when link href changed
* test(image): image with new src should be re-lazyloaded
* test: apply code suggestions from @styfle's review
* test: incorrect condition of image load check
This fixes an issue with how the sizes prop was being applied to images with the experimental raw layout. The only effects were on the raw layout, so won't effect any non-experimental functionality.
This PR adds a new layout mode for images called `raw`, as discussed with the core team a while back. This mode has the following characteristics:
- No wrapper `span` around the `img` element
- No sizer svg
- Almost no styles automatically added to the `img` element
- `style` parameter is allowed and is passed through to the underlying `img` element
This also adds documentation changes to describe the new component.
There are a few tradeoffs and DX decisions that may warrant discussion/revision before merging. I'll add a few comments to highlight those issues.
- Related to #18637
Currently, we print warnings during `next dev` for every render of `next/image`, which can quickly fill the console making it really unfriendly to developers trying to read the logs.
This PR changes the behavior so that each unique warning prints at most once.
- Related to #33007
- Related to #31340
To collect the requests starting from page load, we need to register event listeners before page loading (`page.goto` API invocation). By default webdriver will wait for hydration, so we need to register events inside `browser.loadPage` to ensure we can collect the requests before hydration is done.
### Changes
* Add `beforePageLoad` for next webdriver
* registry page `'request'` event before loading page
* update related tests for agruments change
### Usage
```js
browser = await webdriver(appPort, '/path', {
waitHydration, // default true
retryWaitHydration, // default false
disableCache, // default false
beforePageLoad, // default undefined
})
```
Fixed lazyRoot functionality (#33290). Changed the unique id for Intersection Observers discrimination since previously they were only identified by the different rootMargins, now each being identified by the rootMargin and the root element as well
Added more Images to the test with different margins and with/without lazyRoot prop. Browser correctly initially loading two of the four Images according to the props' specifications.
Co-authored-by: Steven <steven@ceriously.com>
## Bug
- [x] Fixes#33809
- [x] Related to #33218
- [x] Integration tests added: Usage of [html-validator](https://www.npmjs.com/package/html-validator) to validate the HTML.
- [x] Errors have helpful link attached, see `contributing.md` (N/A)
In PR #26968, we added Set of loaded images that was removed in #33474 erroneously.
We still need to track loaded images since we can't rely on `img.complete`, especially if the parent uses `react-virtualized`.
Tested on https://nextjs.org/showcase
* Added 'rootEl' oprional property to next/Image component resembling 'root' option of the Intersection Observer API
* changed 'rootEl' to 'lazyBoundary' and its type as well
* added test, fixed initial root detection
* Update test/integration/image-component/default/test/index.test.js
Co-authored-by: Steven <steven@ceriously.com>
* prop names changed
* added 'lazyroot' prop to the documentation
* removed unused import
* Apply suggestions from code review
* Update docs with lazyRoot added in 12.0.9
Co-authored-by: Steven <steven@ceriously.com>
The image prop `onLoadingComplete()` was unexpectedly called multiple times because it uses a [callback ref](https://reactjs.org/docs/refs-and-the-dom.html#callback-refs).
This could lead to an infinite loop if `onLoadingComplete()` calls `setState()` as demonstrated in the updated test.
The solution is to handle refs with `useRef()` and `useEffect` so `onLoadingComplete()` is called at most once per component instance.
- Fixes#33463
This PR is a follow up to PR #32623 to fix the remaining blur styles.
These are unlikely to be overridden by the user but this PR is necessary to make `placeholder=empty` (default behavior) and `placeholder=blur` end up with the same inline styles on the loaded image.
Related to https://github.com/vercel/next.js/issues/18398#issuecomment-997114428
Some users reported false hits when using complex loaders that implement Art Direction.
We can relax the warnings so that query string params named width should not warn.
This will ensure an image hashed consistently regardless of how its imported:
- `import file from "./file.png"` -> /_next/static/media/file.12345678.png
- `url(./file.png)` -> /_next/static/media/file.12345678.png
- `new URL("./file.png", import.meta.url)` -> /_next/static/media/file.12345678.png
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
As a follow up to #30041 which changed `<div>` to `<span>`, this PR makes sure that unexpected styles are not applied to the image wrapper or sizer spans.
For example: `.content span {}` would apply to all spans and incorrectly style the image wrapper.
This PR adds [`all: initial`](https://developer.mozilla.org/en-US/docs/Web/CSS/all) to effectively reset the span styles.
* fix: Prevent image redirection when trailingSlash is set
* test: Trailing slash test for next/image
* lint-fix
Co-authored-by: Gustavo Edinger <gbe@nect.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Steven <steven@ceriously.com>
Bump `squoosh` to the latest version, currently commit [cad09160](cad09160b6).
Ideally, we would use the version published to npm but it hasn't been published in [two months](https://www.npmjs.com/package/@squoosh/lib?activeTab=versions) and we have a patch (#23565) that isn't available upstream.
This also is a precursor to getting support for AVIF.
- Fixes#27092
- Fixes#26527
- Reapplies the patch from #23565
Follow-up to https://github.com/vercel/next.js/pull/29307 this ensures the `blurDataURL` is correctly prefixed with the `basePath` in development since we use the `_next/image` endpoint to generate the placeholder in dev mode.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/issues/29289#issuecomment-927758204
This ensures we prefix the `src` for static images with the `basePath` correctly, this also copies over the static image tests to the basePath image-component suite.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/issues/29289
Adds tests to the Image component to verify that the correct data is being exposed.
Based on #27899 and #28312
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
This PR does a few things:
- Moves `<noscript>` usage below the blur image since so that the `<noscript>` image renders on top of the blur image
- Remove the `isVisible` check for `<noscript>` since we can't rely on client-side JS
- Add `loading=lazy` to the `<noscript>` image to take advantage of native lazy loading (can't rely on JS lazy loading)
Fixes#28251
This PR resurrects #23622 which has not been updated in a while. Makes the `Image` component handle `blob:` object urls.
closes#23622fixes#19291
credits: @sdn90
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
This PR introduces an improved developer experience when `next lint` is run for the first time.
### Current behavior
`eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`:
Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues:
- Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`).
- #26348
- There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`.
- #26574
- #26475
- #26438
### New behavior
Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application.
<img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" />
- The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed
- Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`)
- For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config.
<img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png">
---
In addition, this PR also:
- Fixes#26348
- Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
We've never supported the `style` prop as seen in the docs https://nextjs.org/docs/api-reference/next/image#other-props
TS users already get a build error but JS users were left in the dark.
This PR adds a warning so its clear during `next dev`.
