[pull] canary from vercel:canary - #1320
Merged
Merged
Conversation
## Summary This PR improves the accessibility of the Ant Design example by adding an accessible label to the icon-only `Link`. ### Changes - Added `aria-label="Home"` to the icon-only link. ### Why The link currently renders only an icon, so it does not provide an accessible name for assistive technologies. Adding an `aria-label` makes its purpose clear to screen reader users without changing the visual appearance. ### Before Screen readers announce the element as an unlabeled link. ### After Screen readers announce the link as **"Home"**. Co-authored-by: Marcos Hernanz <96699542+marcoshernanz@users.noreply.github.com>
The router code did not respect the isPartial byte for runtime app shells for some reason, potentially leading to unnecessary speculative prefetch requests even if the shell was in fact complete. The comments say that the byte on those can't be trusted: https://github.com/vercel/next.js/blob/d00eb6b6c471c9c51ef997f643b049210d9940a5/packages/next/src/client/components/segment-cache/cache.ts#L2694-L2696 which is not true -- the byte is definitely set to partial when a shell contains holes (due to URL data or link data). Updates some tests that now no longer trigger a speculative prefetch because the shell is complete. (note that our tests use `prefetch = 'partial'` a lot, so some of them were triggering speculative prefetches even when they shouldn't have. see #97469 for more)
The implementation of `unstable_eager` is currently incomplete, causes bugs in the main Partial Prefetching flow (see #97469), and is generally not worth the complexity it adds, so we're removing it. We may add something like this back later if we think it's useful. Importantly, removing it fixes a bug that caused apps that use incremental opt-in (i.e. no global `partialPrefetching` config and `export const prefetch = 'partial'`) to issue speculative prefetches for all links without `prefetch={true}`, because any segment without an explicit `prefetch = "partial"` was marked as needing eager prefetching, which was then propagated to the whole route. See #97469 for a full explanation. This fix causes a lot of changes in tests, which were previously incorrectly asserting that we should be seeing two requests. Now that the unnecesary speculative prefetch is gone, most of them only see one.
## What? Serialize `FrozenMap` as a map and `FrozenSet` as a sequence instead of exposing their internal fields. Add JSON shape and round-trip coverage for both collection types. ## Why? Keep serialized formats tied to collection semantics rather than their current storage representation. This matches Serde's implementations for `HashMap` and `HashSet`, which serialize through `collect_map` and `collect_seq` respectively. --------- Co-authored-by: Benjamin Woodruff <github@benjam.info>
Stacked on #96686. ## What? Keep HMR update instructions as typed Rust values until they cross the client protocol serialization boundary. The JSON wire format remains unchanged. ## Why? HMR aggregation currently operates on `serde_json::Value`, so it has to inspect serialized `type` fields and clone values out of JSON objects. This loses type information before aggregation and makes unsupported instruction variants easy to overlook. Keeping instructions typed lets aggregation use concrete equality and hashing, preserves stable ordering while deduplicating updates, and falls back to a total update when it encounters an instruction type it cannot aggregate. ## How? - Add `UpdateInstructionValue`, a type-erased serializable value with typed downcasting and equality. - Represent chunk-list and merged ECMAScript updates with owned, hashable values backed by frozen collections. - Aggregate typed instructions with first-seen ordering for merged updates and last-writer-wins values for chunk updates. - Serialize instructions only when producing the HMR protocol message. - Add unit coverage for downcasting, equality, hashing, aggregation behavior, and the existing JSON protocol shape. ## Verification - Unit tests cover the new typed values and aggregation behavior. - Serialization tests confirm the client-facing HMR messages are unchanged. - CI <!-- NEXT_JS_LLM -->
With #94948 we intended to move the client over to the firehose feed of HMR events with the intent of unifying the code paths for maintenance. However, now that Server HMR is moving to a pull-based model (which client HMR will not be able to implement), let's keep the split. There's no need to encode the HmrTarget into each surface, and we can just use the function name to indicate which mode of HMR it's for.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )