Merge master into v11 #3943

… do ESM (#3544)

Co-authored-by: Jason Miller <[email protected]>

implement state settling in X

…3562) * ensure both onchange and oninput callbacks are attached to the event listener * remove custom hook and combiner callbacks in one * update implementation and unit test * remove only on tests and improve error handling * cover scenario changing order * allow uncaught error in unit test * use event hook to trigger oncompatchange handler * use oninputCapture rather than oninput when both callbacks are defined Co-authored-by: Jovi De Croock <[email protected]>

* add export maps to the subpackages * format * run pretteir on package json files

…-input restrict "oninputCapture" conversion to just "oninput" vs "oninput*"

…nent that isn't in the commitQueue

Fix incorrect `useMemo` return value after skipped render

* prevent _suspended and _force from colliding * Update mangle.json

React 18 hooks

This fixes a lot of issues with events as outlined in #3607

mirror change for `setTimeout` debounce

Co-authored-by: Jovi De Croock <[email protected]>

…cation of sCU

defer bailing out of updates to the render phase

fix nextValue setting

* Update esbuild to 0.14.50 * Remove newline from mangle.json (terser does this)

Multiple state hooks in a component

avoid crashing due to __hooks being null

fix `useSyncExternalStore` relying on changed render values

* fix sync-external-store * golf * golf

* Fix hooks calling shouldComponentUpdate without context This was breaking code that relies on `this` within shouldComponentUpdate. * Fix `this` usage

* ensure we iterate over all hooks * golf * add comment

* allow function component with children * test for 3611 * better element type * remove namespace

undo jsx-element removal

* allow for null * add test

Pass `errorInfo` to `useErrorBoundary` calbback

* improve types for bare createElement and h calls * component test * fix onInput events * accept refless classattributes * correct generics

* fix case where we would omit the ref from reused vnodes * add test for call ordering * correct tests * skip test for now

fix: mac arm build

* alternative use id * reliable tagging * skip fragments * remove mask var * reduce diff * types * use hash func" * less bytes * fix inheritance bug * optimize * tweak logic * fix copy pate * less bytes * add compat * types * add consideration * add useId test highlighting subsequent render dangers * fix client side renders * revert to prior implementation * optim

* cleanup _parent, __hooks and _dom when unmounting * set listeners * try out perf impact * Update index.js * fix test * add _component removal * Update index.js * Update suspense.js

* assert rts and csr output match * add hydrate test

add mangle value for stable mask on v node

support falsy data attributes

Add missing "types" field for preact/debug

* align ts definitions from react to refs and forward refs * type ref to also allow null as per react type definition * add PropsWithChildren also to preact/compat Co-authored-by: Jovi De Croock <[email protected]>

The behavior to resolve these types seems different from the standard behavior from TypeScript. The more elegant way of using generics or clever intersection types doesn't work. The only thing TS seems to pick up is enhancing every property by hand.

Support signal values for html + svg attributes

* create test case for #3742 * solve issue * types * golf * add mangle

…ng (#3738)

Upgrade workflow actions

Upgrade bench dependencies

…inition (#3782) - Simplify the definition of benchmarks by creating a new workflow, `run-bench.yml`, that can be reused for all benchmarks - Reuse the `ci.yml` workflow to build the repo - Add `trace` option to `run-bench` workflow

This should fix preactjs/preact-render-to-string#254 without incurring the performance overhead of converting primitives in JSX text positions to VNodes.

Fixes #556

Debug: limit "object as children" error to elements

I'm not aware of any bugs caused by this, but currently we drop the return value of event handlers rather than returning it to the DOM. This corrects that. Co-authored-by: Andre Wiggins <[email protected]>

docs: Removes recommendation for `preact-cli`

There are small typos in: - compat/src/index.js - debug/src/debug.js - test/polyfills.js Fixes: - Should read `representation` rather than `represantation`. - Should read `nonetheless` rather than `nontheless`. - Should read `argument` rather than `arugment`. Signed-off-by: Tim Gates <[email protected]>

docs: Fix a few typos

* Clear css properties when passed undefined

@developit

* Narrows type of `parent` in render functions. https://gist.github.com/developit/f4c67a2ede71dc2fab7f357f39cff28c is the recommended way to partial root rendering in Preact 10+, but it isn't API compliant code given the current API definition as expressed by the TS types. This PR changes the type of `parent` to align with what is *actually* required by the preact render functions according to @developit. Assuming the linked code actually works, then it means preact doesn't actually need a NodeList, but rather just needs an `ArrayLike<Node>`. Along with limiting the property set of `Parent`, I have also narrowed `Parent['childNodes']` to be an `ArrayLike<Node>` so someone can assign a `Node[]` to it. I suspect my stylistic choice of a single long line is not acceptable for this repository, but I'm not clear what the proper way to break this into multiple lines is for this repository. If someone can provide me with feedback on how to correctly split the lines, please let me know! Note: I recognize that this is a pretty substantial type change, but without it the official recommendation (and only option in Preact 11) for doing partial root rendering is incorrect. Either the recommendation for how to do partial root rendering should be corrected to not lead people to an incorrect solution, or this PR (or one like it) should be merged to correctly express the type that preact expects for its `render` functions. * Update index.d.ts * Update src/index.d.ts Co-authored-by: Andre Wiggins <[email protected]> * Update preact.tsx --------- Co-authored-by: Andre Wiggins <[email protected]>

* Changes `EventHandler<...>` to have a `this` of type `void`. Originally, `this` was set to `E['currentTarget']` which, based on the MDN doc linked in #2166, certainly sounds like the correct thing to do. A couple years later it was changed to `never` in #3147 with no commentary on the PR or commit indicating why. My guess is that this was changed so arrow functions would work, which I believe are permanently bound and cannot be rebound by the caller. I believe that `never` is wrong because this code doesn't compile: ```ts type TargetedEvent<Target extends EventTarget = EventTarget, TypedEvent extends Event = Event> = Omit<TypedEvent, 'currentTarget'> & { readonly currentTarget: Target } interface EventHandler<E extends TargetedEvent> { (this: never, event: E): void } declare const apple: EventHandler<TargetedEvent<HTMLElement, Event>> declare const event: TargetedEvent<HTMLElement, Event> apple(event) // error TS2684: The 'this' context of type 'void' is not assignable to method's 'this' of type 'never'. ``` Changing to `void` resolves this error and should work everywhere I believe. I removed the comment since it no longer applies with this being `never` or `void`. It appears that it was just forgotten when the switch from `E['currentTarget']` to `never` was made. * Removes incorrectly passing test. The type signature's intent is to make it clear to users that they cannot rely on `this` being the element in callbacks, and they should use `event.currentTarget` instead. This test was testing that the user could unwisely ignore that. --------- Co-authored-by: Jovi De Croock <[email protected]>

…#3875) ## Why does #3814 fail on master? When transitioning from the tree ```jsx <div> <Fragment> <span>0</span> <span>1</span> </Fragment> <input /> </div> ``` to the tree (note `<span>1</span>` was unmounted) ```jsx <div> <Fragment> <span>0</span> </Fragment> <input /> </div> ``` the `master` branch has a bug where it will re-append all the children after the `Fragment`. This re-appending of the `<input>` causes it to lose focus. The reason for this re-appending is that when exiting `diffChildren` for the Fragment, it's `_nextDom` pointer is set to `<span>1</span>`. Since `<span>1</span>` is unmounted it's `parentNode` is `null`. When diffing the `input` element, we hit the `oldDom.parentNode !== parentDom` condition in `placeChild` which re-appends the `<input>` tag and sets oldDom to `null` causing all siblings of `<input>` to re-append. When diffing components/Fragments, the `_nextDom` pointer should point to where in the DOM tree the diff should continue. So when unmounting `<span>1</span>`, the Fragment's `_nextDom` should point to the `<input>` tag. The previous code in `diffChildren` removed in #3738 was intended to fix this by detecting when `_nextDom` pointed to a node that we were unmounting and reset it to it's sibling. However, that code (copied below) had a correctness bug prompting its removal (#3737). Let's look at this bug. ```js // Remove remaining oldChildren if there are any. for (i = oldChildrenLength; i--; ) { if (oldChildren[i] != null) { if ( typeof newParentVNode.type == 'function' && oldChildren[i]._dom != null && oldChildren[i]._dom == newParentVNode._nextDom ) { // If the newParentVNode.__nextDom points to a dom node that is about to // be unmounted, then get the next sibling of that vnode and set // _nextDom to it newParentVNode._nextDom = getDomSibling(oldParentVNode, i + 1); } unmount(oldChildren[i], oldChildren[i]); } } ``` ## What caused #3737? Here is a simplified repro of the issue from #3737: ```jsx function App() { const [condition] = useState(true); return this.state.condition ? ( // Initial render <> <div>1</div> <Fragment> <div>A</div> <div>B</div> </Fragment> <div>2</div> </> ) : ( // Second render: unmount <div>B and move Fragment up <> <Fragment> <div>A</div> </Fragment> <div>1</div> <div>2</div> </> ); } ``` The first render creates the DOM `1 A B 2` (each wrapped in divs) and when changing the `condition` state, it should rerender to produce `A 1 2` but instead we get `1 A 2`. Why? When rerendering `App` we unmount `<div>B</div>`, which is a child of a Fragment. This unmounting triggers the call to `getDomSibling` in the code above. `getDomSibling` has a line of code in it that looks like `vnode._parent._children.indexOf(vnode)`. This line of code doesn't work in this situation because when rerendering a component, we only make a shallow copy of the old VNode tree. So when a child of `oldParentVNode` (the `App` component in this case) tries to access it's parent through the `_parent` pointer (e.g. the `Fragment` parent of `<div>A</div>`), it's `_parent` pointer points to the new VNode tree which we are in progress of diffing and modifying. Ultimately, this tree mismatch (trying to access the old VNode tree but getting the in-progress new tree) causes us to get the wrong DOM pointer and leads to incorrect DOM ordering. In summary, when unmounting `<div>B</div>`, we need `getDomSibling` to return `<div>2</div>` since that is the next DOM sibling in the old VNode tree. Instead, because our VNode pointers are mixed at this stage of diffing, `getDomSibling` doesn't work correctly and we get back the wrong DOM element. ## Why didn't other tests catch this? Other tests only do top-level render calls (e.g. `render(<App condition={true} />)` then `render(<App condition={false} />)`) which generate brand-new VNode trees with no shared pointers. They did not test renders originating from `setState` calls which go through a different code path and reuse VNode trees which share pointers across the old and new trees. ## The fix The initial fix for this is to replace `getDomSibling` with a call to `dom.nextSibling` to get the actual next DOM sibling. (I found a situation in which this doesn't work optimally. I'll open a separate PR for that.) ## Final thoughts One additional thought I have here is that walking through this has given me more confidence in our approach for v11. First, we do unmounts before insertions so we don't have to do this additional DOM pointer checking. Also, by diffing backwards, we ensure that our `_next` pointers are correct when we go to search what DOM element to insert an element before. Fixes #3814, #3737

* There was a parameter missing (`isStaticChildren: boolean`), which is not useful\*, but is still being passed * Fix order of `source` and `self` again (incorrectly introduced in GH-3459) * Fix some (internal JSDoc) types for these parameters My guess is that the previous PR “fixed” the earlier problem because `self` isn’t used, so by calling `isStaticChildren` “`self`”, a bug went away. The source for where this `jsxDEV` call is generated in Babel is here: <https://github.com/babel/babel/blob/3952486/packages/babel-plugin-transform-react-jsx/src/create-plugin.ts#L506-L508>. The React RFC for the transform that mentions the dev runtime is here: <https://github.com/reactjs/rfcs/blob/createlement-rfc/text/0000-create-element-changes.md#dev-only-transforms> \* `isStaticChildren` is the same as whether `jsxs` would be used, instead of `jsx`. Which is also whether there are 2 or more children passed: * `<a />` -> `jsx('a', {})` * `<a>b</a>` -> `jsx('a', {children: 'b'})` * `<a>{1}{2}</a>` -> `jsxs('a', {children: [1, 2]})` Related-to: GH-3459.

Found a difference between how React and Preact propagate context. It shows up when using react-router and a component triggers a location update (e.g. `history.push`) and at the same time triggers a local state update. ## The setup First, how React Router works. The `Router` component watches the pages current location and provides it on a context. Let's call this context `RouterContext`. The `Route` component consumes this `RouterContext`, but also modifies it and re-provides the new value on a new instance of `RouterContext.Provider`. So if we have a `Page` component that lives under a `Router` and `Route` components, the virtual DOM tree looks something the following. Let's say the initial value of the provided location in `RouterContext` is `/page/1` ```jsx <App> <Router> <RouterContext.Provider> {/* location: /page/1 */} <Route> <RouterContext.Consumer> <RouterContext.Provider> {/* location: /page/1 */} <Page> <button> ``` Let's say the `button` under `Page` has a click handler that triggers a location update on `Router` as well as updates some local state: ```jsx function Page() { const history = useHistory(); // Magical hook that triggers a state update in the Router with a new location entry const [value, setValue] = useState(1); // let's pretend to read the current location and value for some purpose const { location } = useContext(RouterContext); console.log({ location, value }); return ( <button onClick={() => { history.push('/page/2'); // Triggers an state update in the Router component setValue(2); // Triggers a state update in Page }} > Update </button> ); } ``` Some things to note about this virtual tree: 1. The `RouteContext.Consumer` under `Route` is subscribed to its parent `RouteContext.Provider` (the one owned by `Router`) 2. The `Page` component is subscribed to it's nearest parent `RouteContext.Provider`, which in this case is the one owned by `Route`, not `Router`. On initial render, `Page` would log `{ location: /page/1, value: 1 }`. ## The bug So what happens in Preact when we click this button? Two state updates are triggered: one on `Router` and one `Page`. So our rerender queue looks like [`Router`, `Page`]. Upon rerendering Router, we update the location value we pass to the first `RouterContext.Provider` to `/page/2` and trigger updates to all of the `RouterContext` consumers. Let's re-examine our render queue and virtual DOM tree: ```jsx // renderQueue: [Page, RouterContext.Consumer] <App> <Router> <RouterContext.Provider> {/* location: /page/2 */} <Route> <RouterContext.Consumer> <RouterContext.Provider> {/* location: /page/1 */} <Page> <button> ``` A couple things to note. Our rerendering stops after the first `RouterContext.Provider` runs. Context providers just return `props.children` so our `vnodeID` optimization will kick in, see the children of the `Provider` didn't get no VNodes and stop rerendering there. Because of this, the `RouterContext.Consumer` under `Route` has NOT rerendered yet, so the `RouterContext.Provider` that it owns has not received the updated context. And since the `Page` component is subscribed to the `RouterContext.Provider` that `Route` owns, it still would see the old context. So, since rerendering stopped after the first `RouterContext.Provider`, the next component that rerenders is `Page` (remember, it triggered it's own local state update). At this point `Page` will log `{ location: /page/1, value: 2 }`. This log represents the developer-observable bug. The `onClick` handler of the button contains both the `history.push()` and `setValue()` calls and so the developer expects that the next time `Page` renders will be both a new location and a new state value. And logic that assumes this will fail. ## Completing the flow If we continue with Preact's rendering (for completeness), once the `RouterContext.Consumer` rerenders, it'll rerender the second `RouterContext.Provider` which trigger rerenders to its subscribers, namely `Page`. A this point `Page` will rerender again but with the both the updated location context and the new state and so will log `{ location: /page/2, value: 2 }`. ## React's behavior In this case, React handles the state propagation and local state update in one pass down the render tree. Presumably, changes to context synchronously mark consumers as needing updates (I haven't personally validated this yet). So as React walks down the tree, it rerenders the `Router`, the first `RouterContext.Provider`, sees the `RouterContext.Consumer` as needing a rerender, which causes a render of the second `RouterContext.Provider`, and ultimately rerenders the `Page` component with both it's local state update and the location update from its parent `RouterContext.Provider`. In this case, `Page` only rerenders once with both updates.

…l the rerenderQueue is empty and length == 0

Re-sort rerender queue if modified while we are processing rerenders

This PR is a follow up to #3875. I realized that we can't do oldChildren[i]._dom.nextSibling cuz oldChildren[i] itself could be Fragment representing a bunch of DOM nodes. We want the last dom node of oldChildren[i] and to get it's last sibling.

Fixes #3775 Fixes #3724 When we are in events we need setTimeout to deal with how events bubble, we want the events to complete before we start our rendering process. This however isn't needed when we are dealing with internal updates coming from effects/... Co-authored-by: andrewiggins <[email protected]>

* add exactOptionalPropertyTypes support to attributes * add exactOptionalPropertyTypes support to jsx and key attributes

* set dimensional attributes through `setAttribute` * add tests * try regex * Update props.js * undo

Fix createContext update being blocked by sCU

* Fix hydrating textarea with value prop * Golf setting value

types: Add `indeterminate` property

…3908)

* fix case where strict equality leads to a deadlock with c._force * add failing test

Add missing SVG Elements to types

…nent fix: Add `MemoExoticComponent` type to compat

* Add React-like aria typings * Add signal type support to aria attributes * Put JSDoc tags on their own lines * Consistently use Booleanish * Make role typing more strict and add 'none presentation'

Function children that are passed as props to a component are still allowed but if that Component doesn't invoke the function and passes it a child, we'll skip over it.

Commits on Jun 1, 2022

10.7.3 (#3551 )

JoviDeCroock committed Jun 1, 2022

Configuration menu

View commit details

Copy full SHA for 8fb48b8

Browse repository at this point

Copy the full SHA

8fb48b8 View commit details

Browse the repository at this point in the history

Commits on Jun 3, 2022

implement state settling in X

JoviDeCroock committed Jun 3, 2022

Configuration menu

View commit details

Copy full SHA for 3bd3c46

Browse repository at this point

Copy the full SHA

3bd3c46 View commit details

Browse the repository at this point in the history

Commits on Jun 6, 2022

test

JoviDeCroock committed Jun 6, 2022

Configuration menu

View commit details

Copy full SHA for d59a4c6

Browse repository at this point

Copy the full SHA

d59a4c6 View commit details

Browse the repository at this point in the history

Commits on Jun 13, 2022

fix ci (#3563 )

JoviDeCroock committed Jun 13, 2022

Configuration menu

View commit details

Copy full SHA for 0b9a927

Browse repository at this point

Copy the full SHA

0b9a927 View commit details

Browse the repository at this point in the history

Commits on Jun 22, 2022

10.8.2 (#3581 )

JoviDeCroock committed Jun 22, 2022

Configuration menu

View commit details

Copy full SHA for a0f7742

Browse repository at this point

Copy the full SHA

a0f7742 View commit details

Browse the repository at this point in the history

Commits on Jul 6, 2022

10.9.0 (#3601 )

JoviDeCroock committed Jul 6, 2022

Configuration menu

View commit details

Copy full SHA for 80600ea

Browse repository at this point

Copy the full SHA

80600ea View commit details

Browse the repository at this point in the history

Commits on Jul 13, 2022

10.10.0 (#3613 )

JoviDeCroock committed Jul 13, 2022

Configuration menu

View commit details

Copy full SHA for dbe0fa8

Browse repository at this point

Copy the full SHA

dbe0fa8 View commit details

Browse the repository at this point in the history

Commits on Aug 10, 2022

10.10.2 (#3653 )

JoviDeCroock committed Aug 10, 2022

Configuration menu

View commit details

Copy full SHA for 6b92b1f

Browse repository at this point

Copy the full SHA

6b92b1f View commit details

Browse the repository at this point in the history

Commits on Oct 14, 2022

fix setstate order (#3763 )

JoviDeCroock committed Oct 14, 2022

Configuration menu

View commit details

Copy full SHA for 43204de

Browse repository at this point

Copy the full SHA

43204de View commit details

Browse the repository at this point in the history

Commits on Jan 10, 2023

Improve suspense test spies (#3856 )

andrewiggins committed Jan 10, 2023

Configuration menu

View commit details

Copy full SHA for 2ce7b0a

Browse repository at this point

Copy the full SHA

2ce7b0a View commit details

Browse the repository at this point in the history

Commits on Feb 19, 2023

Add aria role attribute values (#3904 )

shoonia committed Feb 19, 2023

Configuration menu

View commit details

Copy full SHA for 17ce063

Browse repository at this point

Copy the full SHA

17ce063 View commit details

Browse the repository at this point in the history

Merge master into v11 #3943

Are you sure you want to change the base?

Merge master into v11 #3943

Commits on May 29, 2022

Commits on Jun 1, 2022

Commits on Jun 3, 2022

Commits on Jun 5, 2022

Commits on Jun 6, 2022

Commits on Jun 12, 2022

Commits on Jun 13, 2022

Commits on Jun 14, 2022

Commits on Jun 15, 2022

Commits on Jun 16, 2022

Commits on Jun 17, 2022

Commits on Jun 19, 2022

Commits on Jun 20, 2022

Commits on Jun 21, 2022

Commits on Jun 22, 2022

Commits on Jun 24, 2022

Commits on Jun 29, 2022

Commits on Jun 30, 2022

Commits on Jul 6, 2022

Commits on Jul 7, 2022

Commits on Jul 13, 2022

Commits on Jul 15, 2022

Commits on Jul 18, 2022

Commits on Jul 19, 2022

Commits on Jul 20, 2022

Commits on Jul 26, 2022

Commits on Aug 2, 2022

Commits on Aug 3, 2022

Commits on Aug 4, 2022

Commits on Aug 5, 2022

Commits on Aug 7, 2022

Commits on Aug 8, 2022

Commits on Aug 9, 2022

Commits on Aug 10, 2022

Commits on Aug 12, 2022

Commits on Aug 15, 2022

Commits on Aug 16, 2022

Commits on Aug 17, 2022

Commits on Aug 18, 2022

Commits on Aug 19, 2022

Commits on Aug 21, 2022

Commits on Aug 24, 2022

Commits on Aug 28, 2022

Commits on Aug 30, 2022

Commits on Aug 31, 2022

Commits on Sep 2, 2022

Commits on Sep 3, 2022

Commits on Sep 7, 2022

Commits on Sep 11, 2022

Commits on Sep 12, 2022

Commits on Sep 13, 2022

Commits on Sep 17, 2022

Commits on Sep 22, 2022

Commits on Sep 23, 2022

Commits on Sep 27, 2022

Commits on Sep 29, 2022

Commits on Oct 3, 2022

Commits on Oct 4, 2022

Commits on Oct 6, 2022

Commits on Oct 14, 2022

Commits on Oct 15, 2022

Commits on Oct 24, 2022

Commits on Oct 25, 2022

Commits on Oct 26, 2022

Commits on Oct 27, 2022

Commits on Oct 28, 2022

Commits on Oct 29, 2022

Commits on Oct 30, 2022

Commits on Nov 14, 2022

Commits on Nov 15, 2022

Commits on Nov 22, 2022

Commits on Nov 30, 2022

Commits on Dec 3, 2022

Commits on Dec 4, 2022

Commits on Dec 21, 2022

Commits on Dec 30, 2022

Commits on Jan 10, 2023