Skip to content

Conversation

@m-bert
Copy link
Contributor

@m-bert m-bert commented Jan 8, 2026

Description

This PR handles state management in our docs:

  • Moves information about states to "under the hood" section
  • Rewrites entire states & events page to focus more on callbacks
  • Updates GestureStateManager entry and moves it to fundamentals
  • Merges manual gesture guide with manual gesture docs

Test plan

Read docs 🤓

@m-bert m-bert changed the title @mbert/docs state manager [docs] Rewrite "States & Events" page Jan 8, 2026
@m-bert m-bert marked this pull request as draft January 8, 2026 14:06
@m-bert m-bert changed the title [docs] Rewrite "States & Events" page [docs] State management Jan 9, 2026
@m-bert m-bert added the Documentation Documentation change/enhancement label Jan 9, 2026
@m-bert m-bert marked this pull request as ready for review January 12, 2026 13:27
onUpdate: (event: GestureEvent<HandlerData>) => void
```

Called every time a gesture is updated after it has started.
Copy link
Member

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"?

Copy link
Contributor Author

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?

Comment on lines +34 to +44
const longPress = useLongPressGesture({
onActivate: () => {
console.log('LongPress activated!');
},
});

const pan = usePanGesture({
onBegin: () => {
GestureStateManager.activate(longPress.handlerTag);
},
});
Copy link
Member

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)

Comment on lines +71 to +72
Triggers first [`onDeactivate`](/docs/fundamentals/callbacks-events#ondeactivate), then [`onFinalize`](/docs/fundamentals/callbacks-events#onfinalize) callbacks on gesture with specified `handlerTag`.

Copy link
Member

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?

Comment on lines +49 to +55
### begin

```tsx
begin: (handlerTag: number) => void;
```

Triggers [`onBegin`](/docs/fundamentals/callbacks-events#onbegin) callback on gesture with specified `handlerTag`.
Copy link
Member

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?

Copy link
Contributor Author

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.
Copy link
Member

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.
Copy link
Member

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.

Copy link
Contributor Author

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.

  1. It mentions TouchEvent, but only to say that "you don't have to use manual, you have more info on other gestures already"
  2. It introduces concept of continuous gestures, which is not explained in the docs
  3. 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>;
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldActivateOnActivate 😄

Comment on lines +18 to +19
| **`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) |
Copy link
Member

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.

m-bert and others added 2 commits January 26, 2026 17:05
…re.mdx

Co-authored-by: Jakub Piasecki <jakub.piasecki@swmansion.com>
Co-authored-by: Jakub Piasecki <jakub.piasecki@swmansion.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Documentation Documentation change/enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants