Add example for Pressability with Native Driver in RNTester #45413
+76
−0
Conversation
This file contains 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
facebook-github-bot
added
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D58182480 |
|
This pull request was exported from Phabricator. Differential Revision: D58182480 |
cipolleschi
force-pushed
the
export-D58182480
branch
from
975ed27 to
6463a98
Compare
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
Jul 15, 2024
…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Reviewed By: sammy-SC Differential Revision: D58182480
…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Reviewed By: sammy-SC Differential Revision: D58182480
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
Jul 15, 2024
…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Differential Revision: D58182480 Reviewed By: sammy-SC
|
This pull request was exported from Phabricator. Differential Revision: D58182480 |
cipolleschi
force-pushed
the
export-D58182480
branch
from
6463a98 to
01bc97a
Compare
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
Jul 16, 2024
…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Differential Revision: D58182480 Reviewed By: sammy-SC
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
Jul 16, 2024
…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Differential Revision: D58182480 Reviewed By: sammy-SC
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
Jul 16, 2024
…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Differential Revision: D58182480 Reviewed By: sammy-SC
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
Jul 16, 2024
…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Differential Revision: D58182480 Reviewed By: sammy-SC
|
This pull request has been merged in 050006a. |
|
This pull request was successfully merged by @cipolleschi in 050006a When will my fix make it into a release? | How to file a pick request? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
Changes
Add an example in RNTester to test that pressability with NativeDrivers works properly.
Context
The pressability handling is a bit peculiar.
We have to handle 3 main behaviors:
PressIn->PressOut=> triggers theonPressPressIn-> move inside the rectangle ->PressOut=> triggers theonPressPressIn-> move outside the rectangle ->PressOut=> cancelonPress.For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works.
When a move is involved, we:
The problem is that with
nativeDriverand animations, the C++ layer doesn't know about where the receiver view actually is.This results in issues like the one shown by #36504, where the onMove is not handled correctly.
Solution
The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision.
We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations.
Changelog
[General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers
Differential Revision: D58182480