mirror of
https://github.com/status-im/status-react.git
synced 2025-01-11 03:26:31 +00:00
1806cb792a
Adds support for swiping left/right on some types of notifications. Swiping left (from left to right) shows a blue button allowing the user to mark the notification as read/unread. Swiping right (from right to left) shows a red button, allowing the user to delete the notification for good. Related PR in status-go https://github.com/status-im/status-go/pull/3201. Fixes https://github.com/status-im/status-mobile/issues/14901 Fixes https://github.com/status-im/status-mobile/issues/14900 Technical notes =============== How's the performance? It feels near native performance in a production release in a mid-range smartphone. So I'd say it's pretty good, but let me know if you find any issue. - I refrained from trying to eliminate all code duplication in this PR. Some notifications will behave differently, especially the ones with call to action, so I ask you to please take that in consideration when reviewing. See https://github.com/status-im/status-mobile/issues/15118 - React Native Gesture Handler has a component named [Swipeable](https://docs.swmansion.com/react-native-gesture-handler/docs/api/components/swipeable/). I used it instead of writing a monstrosity 👹 of code in Reanimated to achieve the same results. - RN Gesture Handler touchables are the only ones that work with the Swipeable component, so I used them and added vars to `react-native.gesture`. - I had to manually interpolate the translation X of the buttons behind notifications because notifications are transparent. To make interpolation work with `Swipeable` it's mandatory to use RN `Animated.View` and not `Reanimated.View` (see next point). - `Swipeable` expects us to pass functions that will receive RN `AnimatedInterpolation` instances and the rendering lifecycle does not work as usual. Hooks didn't trigger as expected, functional Reagent components didn't behave as expected, etc. This means `Reanimated.View` and its interpolation function is out of question. I did try for almost two days, nothing works. Testing notes ============= These are some of the manual tests I ran. There are more scenarios to cover obviously. Assuming no unread notifications before each flow: Contact request notification ============================ From the perspective of an user A: 1. Receive a contact request from a non-mutual contact B. 2. Verify the unread count is displayed over the bell icon. 3. Verify the unread count is displayed on the `Messages > Contacts` tab, as well as on the AC `Contact requests` tab. 4. Open the AC and before accepting/declining the contact request, check that you CAN'T swipe left or right. 5. Accept or decline the contact request. 6. Check the unread indicator disappears in all necessary places. 7. Press on the notification and see if you're redirected to the chat. 8. Go back to the AC and swipe left to mark as `Unread`. Notice that opening the chat marks the notification as `Read`. Also very important, notice that the `Messages > Contacts` tab will NOT show the *pending contact requests* section at the top. This is on purpose, given the notification is unread, but the user has already accepted/declined the contact request, hence it's not pending. 9. Swipe left againg to mark as `Read`. Check all unread indicators are updated. 10. Swipe right to delete the notification (it won't be displayed ever again). Admin notification ================== 1. Generate an admin notification, e.g. a community owner receiving a request notification to join. 2. Verify the unread count is displayed over the bell icon, as well as the AC Admin tab. 3. Verify the community unread indicator is correctly displayed. 4. As an admin, open the AC and before accepting/declining the request, check that you CAN'T swipe left or right. 5. Accept or decline the membership request. 6. Check the unread indicator disappears accordingly. 7. Swipe left to mark as `Read`. 8. Swipe left to mark as `Unread`. 9. Swipe right to delete the notification (it won't be displayed ever again). Mentions & replies ================== Similar steps outlined for `Admin` notifications, but there's one important difference. Mention and reply notifications don't require a call to action from the user, so the user can swipe left/right **without** first having to do anything on the notification (such as pressing on it). See issue https://github.com/status-im/status-mobile/issues/15118 What about other types of notifications? ======================================== Swipe gestures for other notification types will be implemented in a separate PR.