-
-
Notifications
You must be signed in to change notification settings - Fork 1k
[docs] State management #3905
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: @mbert/docs-detector
Are you sure you want to change the base?
[docs] State management #3905
Conversation
| onUpdate: (event: GestureEvent<HandlerData>) => void | ||
| ``` | ||
|
|
||
| Called every time a gesture is updated after it has started. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does it mean that "gesture is updated"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I agree that it might not make much sense. However, I'm not sure how to rephrase it. Maybe something like
"Called every time a gesture receives a GestureEvent, provided it has previously activated."
What do you think?
| const longPress = useLongPressGesture({ | ||
| onActivate: () => { | ||
| console.log('LongPress activated!'); | ||
| }, | ||
| }); | ||
|
|
||
| const pan = usePanGesture({ | ||
| onBegin: () => { | ||
| GestureStateManager.activate(longPress.handlerTag); | ||
| }, | ||
| }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This example doesn't make sense, why not in reverse? (long press activating pan)
| Triggers first [`onDeactivate`](/docs/fundamentals/callbacks-events#ondeactivate), then [`onFinalize`](/docs/fundamentals/callbacks-events#onfinalize) callbacks on gesture with specified `handlerTag`. | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if I call it before the gesture activates?
| ### begin | ||
|
|
||
| ```tsx | ||
| begin: (handlerTag: number) => void; | ||
| ``` | ||
|
|
||
| Triggers [`onBegin`](/docs/fundamentals/callbacks-events#onbegin) callback on gesture with specified `handlerTag`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually need the explicit "begin" method here? Won't all gestures automatically begin when detecting the first touch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it always the case? What about pinch and rotation? At first glance (at least on web), they won't begin unless interacting with at least 2 pointers.
| import SharedValueInfo from './\_shared/shared-value-info.md'; | ||
|
|
||
| A discrete gesture that activates when the corresponding view is pressed for a sufficiently long time. | ||
| This gesture's state will turn into [END](/docs/fundamentals/states-events#end) immediately after the finger is released. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to get rid of all the state links? We could be linking to specific callbacks instead.
|
|
||
| ## Modifying existing gestures | ||
|
|
||
| While manual gestures open great possibilities we are aware that reimplementing pinch or rotation from scratch just because you need to activate in specific circumstances or require position of the fingers, would be a waste of time as those gestures are already available. Therefore, you can use touch events with every gesture to extract more detailed information about the gesture than what the basic events alone provide. We also added a `manualActivation` modifier on all continuous gestures, which prevents the gesture it is applied to from activating automatically, giving you full control over its behavior. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure whether this is the right place for this information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tl;dr
I think we can remove it. If we really want to keep this, then I believe it should be rephrased - in that case we have to decide what we actually want to say here.
Whole answer
Probably not. However, I have mixed feelings about this message. It looks like it gathers information from few sections and tries to merge them into one, but I'm not sure if it works.
- It mentions
TouchEvent, but only to say that "you don't have to use manual, you have more info on other gestures already" - It introduces concept of
continuous gestures, which is not explained in the docs - It also describes
manualActivation, which is already described when looking at specific handlers' configs.
I'm also not sure where do we want to put this if we were to move it. Overall it just sounds like "hey, we have manual handlers, but probably you could use the ones that are already configured" and that doesn't make much sense, especially after whole "tutorial" of how you use them.
| ### shouldActivateOnStart (**Android only**) | ||
|
|
||
| ```ts | ||
| shouldActivateOnStart: boolean | SharedValue<boolean>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated, but this name doesn't make sense with the current api.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldActivateOnActivate 😄
packages/docs-gesture-handler/docs/gestures/use-pinch-gesture.mdx
Outdated
Show resolved
Hide resolved
packages/docs-gesture-handler/docs/gestures/use-rotation-gesture.mdx
Outdated
Show resolved
Hide resolved
| | **`FAILED`** | The handler failed to recognize the gesture. | [`onFinalize`](/docs/fundamentals/callbacks-events#onfinalize) | | ||
| | **`CANCELLED`** | The system interrupted the gesture. | [`onFinalize`](/docs/fundamentals/callbacks-events#onfinalize) | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Failed and Cancelled will also trigger onDeactivate if the gesture was active.
…re.mdx Co-authored-by: Jakub Piasecki <jakub.piasecki@swmansion.com>
Co-authored-by: Jakub Piasecki <jakub.piasecki@swmansion.com>
Description
This PR handles state management in our docs:
GestureStateManagerentry and moves it to fundamentalsTest plan
Read docs 🤓