Summary:
Add explicit annotations to useCallback as required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Codemod command: `flow codemod annotate-use-callback`
drop-conflicts
bypass-lint
Changelog: [Internal]
Reviewed By: evanyeung
Differential Revision: D40079418
fbshipit-source-id: 59750a5d07b2ac1f440927794a7523682f048a5e
Summary:
changelog: [internal]
Call flushQueue directly from useAnimatedProps to avoid mismatch between `NativeAnimatedHelper.API.setWaitingForIdentifier` and `NativeAnimatedHelper.API.unsetWaitingForIdentifier`
Previously, animation queue only got called if every `setWaitingForIdentifier` call was matched by `unsetWaitingForIdentifier`. If an error is thrown, this is not the case and they get out of sync. WHen they get out of sync, they never recover and animation queue is never flushedddddd.
Reviewed By: yungsters
Differential Revision: D38938858
fbshipit-source-id: c38fdef05cc70ce274b8e16114ffe49cc2dcb9b3
Summary:
This diff upgrades xplat to 0.178.1 and pre-suppresses errors from turning on constrained writes.
To generate this diff I:
* Modified every `env_mode=constrain_writes` to `env_mode=ssa` and made a commit (this is so our upgrade script will work)
* Ran scripts/flow/upgrade.sh 0.178.1 to upgrade all the flowconfigs to 178.1 and suppress new-env errors
* Modified arvr/js/flowconfig.ejs to use 0.178.1 and ran `scripts/gen-flowconfig/gen-flowconfig --project arvr`
* Modified xplat/js/flowconfig.ejs to use 0.178.1 and ran `scripts/gen-flowconfig/gen-flowconfig --project xplat`
* Unstacked from the commit in point 1
Reviewed By: SamChou19815
Differential Revision: D36676019
fbshipit-source-id: c3032f18ed838afc327f00de563e7f20713bdc26
Summary:
Add animation queuing back into createAnimatedComponent_EXPERIMENTAL.js, which is a concurrent-safe version of createAnimatedComponent.
T93269035 for details on why this is needed.
# How does this work?
In the old createAnimatedComponent, Animations were queued by calling `setWaitingForIdentifier` before render, and then calling `unsetWaitingForIdentifier` after render.
In this diff, instead we are calling `setWaitingForIdentifier` in an `useLayoutEffect` before calling `useAnimatedProps`, and we are calling `unsetWaitingForIdentifier` in a `useEffect` after `useAnimatedProps`. So the ordering for the effects are:
1. `useLayoutEffect` with `setWaiting`
2. `useLayoutEffect`s in `useAnimatedProps`
3. `useEffect`s in `useAnimatedProps`
4. `useEffect` with `unsetWaiting`.
There's a React guarantee that **if one effect is called, all of them will be called**, so we don't have a concern about the queue getting locked.
## **Main concerns:**
1. This works in my test cases, but it's not the same behavior as the old createAnimatedComponent (which is wait before and unset wait after render). This may still be ok because the relevant side effects in render from that component have been moved to `useLayoutEffect` or `useEffect` in `useAnimatedProps` (so the ordering is still the same?).
2. I'm not sure about the ordering of `onLayoutEffect`, `onLayout` callbacks, and `useEffect`. createAnimatedComponent_EXPERIMENTAL doesn't use `onLayout`, but with this new method of queuing, **`onLayout` calls will likely be called before the animation queue has been flushed**. It's not clear to me whether this is bad.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D29467458
fbshipit-source-id: 2be23a8968404526d0fa394a7879fda8b5ffbfdc
Summary:
Creates a `useAnimatedProps` hook that is compatible with concurrent mode, and uses this in `createAnimatedComponent_EXPERIMENTAL`.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28390393
fbshipit-source-id: d8aa471507a5d096832b93caf63a24f71733deda
Sam Zhou
Tim Yung
Samuel Susla
Jordan Brown
Andres Suarez
Kacie Bawiec
Tim Yung