Fix boolean representation of aria-* and data-* properties on web components #36537
Open
MaxwellCohen wants to merge 3 commits into
Open
Fix boolean representation of aria-* and data-* properties on web components #36537MaxwellCohen wants to merge 3 commits into
MaxwellCohen wants to merge 3 commits into
Conversation
…acebook#36468) Fixes a regression from facebook#36425 where referenced `FormData` entries can be dropped by `decodeReplyFromBusboy` when files are interleaved with text fields in the payload. `decodeReplyFromBusboy` queues text fields that arrive while a file is being streamed and flushes them after the last file's `'end'`, working around busboy emitting `'end'` deferred relative to subsequent `'field'` events. With multiple files interleaved with text, this loses the relative order of the affected text entries. The reorder was a long-standing but invisible issue — entries came back in the wrong order but were all present — until facebook#36425 tightened how referenced FormData entries are collected from the backing store to rely on them being contiguous. With that assumption violated, referenced FormDatas can now come back with some entries dropped. The pattern is most easily surfaced through `useActionState` actions that return the submitted `FormData` as part of their state. This replaces the tail-flush with a linked list of pending files. Text fields that arrive while a file is in flight are queued on the tail file's `queuedFields`; fields that arrive when the list is empty resolve immediately. `flush()` walks from the head, resolving each completed file followed by its queued fields, and stops at the first file that hasn't ended yet. The backing FormData now matches the payload's order, restoring the contiguity assumption (and fixing the long-standing reorder as a side effect). The same change is applied to all five copies in `react-server-dom-{webpack,turbopack,parcel,esm,unbundled}`. Two new tests cover the multi-file interleave. fixes vercel/next.js#93822
MaxwellCohen
force-pushed
the
fix/32251/custom-elements-aria-attributes
branch
from
65834e2 to
8ac4303
Compare
MaxwellCohen
changed the title
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Summary
HTML treats
aria-*/aria-*="true"anddata-*/data-*="true"attributes differently; for example,<my-el aria-hidden />is visible to screen readers accessibility tree, whereas<my-el aria-hidden="true" />is hidden from screen readers accessibility tree. Issue #32251 reported unexpected behavior where boolean values were not being stringified, and this PR fixes it by stringifying boolean values for aria and data attributes. This leverages the solution approach and thinking from the following PRs: #24541 and #26546, by copying Preact behavior for aria and data attributes. I did not touch the behavior of other properties/attributes, because I think React's choice to use shorthand notation for booleans is a better approach than Preact's.fixes: #32251 and #34663
How did you test this change?
Other considerations
I used Composer 2.5 llm to create this PR, but reviewed every line.