Skip to content

Conversation

akwasniewski
Copy link
Contributor

@akwasniewski akwasniewski commented Oct 3, 2025

Description

While writing examples I noticed that some types would be useful. This includes types for each gesture and their HandlerData. This PR adds those types.

Important: The v3 gesture types take over the names of old v2 types, the v2 types are getting a type suffix. This change will have to be added to the migration guide. Added this as a task to roadmap.

Test plan

yarn lint-js

@akwasniewski akwasniewski marked this pull request as draft October 3, 2025 11:01
@akwasniewski akwasniewski marked this pull request as ready for review October 3, 2025 11:24
Copy link
Contributor

@m-bert m-bert left a comment

Choose a reason for hiding this comment

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

Looks ok. Do we need SingleGestureType exported?

export {
SingleGestureName,
SingleGestureType,
ComposedGesture as ComposedGestureType,
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, what do you think about going in the other direction and exporting SingleGesture, LongPressGesture, ...?

That will conflict with the API v2, so we may want to rename those and keep that in mind for the migration guide.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that would be prefarable, and was my first choice, but I didn't want to conflict with v2 api. If you think it is Ok I will gladly change it.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I think we can rename the old types to something else to free up the "makes sense" names for the future. We would have to include that in the migration guide.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'll just point out that we should write it somewhere in case we forget. Not sure if doing TODO comment` is the best, but but we could include it in the roadmap.


export { SingleGestureName } from './v3/types';
export {
SingleGestureName,
Copy link
Member

Choose a reason for hiding this comment

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

Why is that needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

SingleGestureName? I'm preety sure it is no longer needed after we added dedicated gesture hooks, am I correct cc @m-bert? I could remove it in this PR

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, I think it is no longer required. It was with useGesture but now it is only internal (but please make sure that it's true before removing it 😅)

gestureRelations: GestureRelations;
};

export type SingleGestureType = SingleGesture<unknown, unknown>;
Copy link
Member

Choose a reason for hiding this comment

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

What do you think about a union: TapGestureType | PanGestureType | ...

It would have to be defined elsewhere, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great idea, done in 43bd77d

@akwasniewski
Copy link
Contributor Author

akwasniewski commented Oct 3, 2025

Looks ok. Do we need SingleGestureType exported?

I figured there is a need for a more general type than handlers corresponding to each gesture, so the user doesn't have to do PanGesture | TapGesture | .... Gesture and GestureType were taken so I figured I can stick with SingleGesture name

Comment on lines 1 to 9
import { FlingGestureEvent, FlingGesture } from './useFling';
import { HoverGestureEvent, HoverGesture } from './useHover';
import { LongPressGestureEvent, LongPressGesture } from './useLongPress';
import { ManualGestureEvent, ManualGesture } from './useManual';
import { NativeGestureEvent, NativeGesture } from './useNative';
import { PanGestureEvent, PanGesture } from './usePan';
import { PinchGestureEvent, PinchGesture } from './usePinch';
import { RotationGestureEvent, RotationGesture } from './useRotation';
import { TapGestureEvent, TapGesture } from './useTap';
Copy link
Contributor

Choose a reason for hiding this comment

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

If this imports only types, please use import type instead of only import

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, done in 704d604

export {
SingleGestureName,
SingleGestureType,
ComposedGesture as ComposedGestureType,
Copy link
Contributor

Choose a reason for hiding this comment

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

I'll just point out that we should write it somewhere in case we forget. Not sure if doing TODO comment` is the best, but but we could include it in the roadmap.

@m-bert m-bert mentioned this pull request Oct 6, 2025
Comment on lines +59 to +61
export type FlingGestureEvent =
| GestureStateChangeEvent<FlingHandlerData>
| GestureUpdateEvent<FlingHandlerData>;
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we actually want to combine these? At the end of the day, those events are accessed in different callbacks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants