fix: Check Panning for AutoHide state.

[HyopeR]

Detail

Check the "panning" status of the user in "Auto Hide" state. If the user is in "interacting" state, skip the auto-closing process.

Incompatibility between the state and the interface can lead to many side effects, such as corrupted touch events, empty space coverage, or toast that cannot be removed.

Related Issues

#531, #562

What's happening?

1. Toast is shown.
2. User is holding down Toast.
3. "Auto Hide" is triggered in the useToast hook and the state is updated to "false".
4. The component continues to be shown because the user is holding down Toast.
5. So isVisible=false but Toast is visible.

What has changed?

1. Added a new context. To use Gesture values ​​as global references.
2. Updated the "panning" value in GestureContext in AnimatedContainer.
3. In the useToast hook; "Auto Hide" management is done according to the "panning" value.

[HyopeR]

Details

@calintamas

This package uses "Pan Responder" to handle "Pan Gestures". In this case, there is a limitation. Toast component accepts "Customizable Components" from the user.

If "Customizable Component" contains a "Touch or Click" and the user only interacts with this "Touch or Click" and only holds it, "Pan Responder" will not capture any touch action.

In this case, the "panning" value in this pull request cannot be changed. Therefore, the old problems continue. There are 2 different things that can be done to prevent this situation;

1. Create a base Touch component for the user to wrap clickable components in Toast. Control the panning situation inside this Touch component.

2. Migrate to react-native-gesture-handler. Thus, layered touch actions can be processed.

I implemented a temporary method to get rid of the side effects of touch actions in these child components and to prevent state incompatibility. And here is what the difference between the old version and the new version looks like.

Samples

Old Version	New Version
old.mp4	new.mp4

Scenarios

Scenario 1: User shows Toast. Toast is hidden after a certain time.
New: Everything is OK.
Old: Everything is OK.

Scenario 2: User shows Toast and taps and holds on Toast area.
New: Toast is not closed because panning is active. User can close it by dragging or closing.
Old: Toast is permanently locked on screen. Touch actions do not work.

Scenario 3: User shows Toast and taps and holds on touchable child component inside Toast.
New: Toast cannot change "panning" value due to "PanResponder" restriction but Toast is hidden after time is up.
Old: Toast is permanently locked on screen. Touch actions do not work.

[HyopeR]

#488 This pull request is a bit dangerous. If there is any side effect, it will cause a "Non-Interactive Toast". Therefore, this code should be reverted.

"Toast is Visible on Screen" but "isVisible=false" -> "Non-Interactive Toast"

The pull request made here will already eliminate most of the "Side Effects". However, it should still be reverted as a precaution.

[calintamas]

@HyopeR Thanks for taking the time to do this! Please check the test suite, some test cases are failing.

[HyopeR]

Some of the checks that did not pass the tests seem to be buggy outside of this pull request.

PASS src/__tests__/Toast.test.tsx (11,213 s)
PASS src/contexts/__tests__/LoggerContext.test.tsx
PASS src/__tests__/ToastUI.test.tsx

I don't know much about tests. But I can't run tests locally.
Maybe it's related to environment setup, yarn version or something else. I'm not sure.

[calintamas]

To be able to run them locally, you need a setup similar to what's on CI (a setup that is long overdue for an update, I must add). You can see the details here (node, react, react-native versions, etc).

Note: after you yarn add react and react-native locally, make sure to discard the changes to package.json / yarn.lock.

--

One more thing, the coverage went down on this branch, would you be able to add tests to cover the new code paths? Or do you need my help? Thanks again!

[HyopeR]

I was able to run the tests by installing the react and react-native versions mentioned here and downgrading the node.js version to 16. The coverage appeared to be 100%.

More guidance on ".lock" problems and "testing" processes would be really nice to make contributing to the package a bit easier.

[HyopeR]

If there is anything that needs to be changed, let me know. I would like to continue with the version instead of the fork.

[calintamas]

All good, I'll merge and publish it in a new version. Thank you for doing this!