Tom Sherman

I'm running into a problem with @derekrjones and @paullessing workarounds when the first overload has one or more params: ```ts declare function fn(x: number): void; declare function fn(x: 1): void;...

Also I want to call out a real problem this is causing in adding TypeScript definitions to a popular library: https://github.com/sindresorhus/pify#why-is-pify-choosing-the-last-function-overload-when-using-it-with-typescript Ideally `pify(overloadedFn)` would transform each overload with the same...

@paullessing `T1` has the type of `never` in your playground, am I missing something?

@eloytoro That's unrelated to overloads, the following also isn't a type error: ```ts declare function overloaded(): void; type NotOverloaded = (notSomething: boolean) => void; const notOverloaded: NotOverloaded = overloaded; notOverloaded(true);...

For prosperity, there are two ways to suppress the warning that I know of: 1. Use startTransition: https://github.com/tom-sherman/react-suspense-reproduction/commit/24388fcfa2b2838d511cc9ad509827da1b8e99f2 2. Memoize the suspense boundary so that the state update doesn't cause...

From #24082 > We can go even further and allow updates at higher priority (though not sync) by implementing selective hydration at the root, like we do for Suspense boundaries:...

There is also https://github.com/react-native-community/RNNewArchitectureLibraries to act as a demo

@lluia It probably makes sense to also run the examples through jest-axe. Related to #626 and #624

Good point, I wonder if that can be communicated (or is already communicated) in the name and API. I only see this useful when using typescript and in Dev mode.

Maybe an alternative could be a type predicate function, not as ergonomic though IMO - not much benefit over doing the conditional yourself.