Disables the Button during onPress call in PressableWithFeedback #18122

priyeshshah11 · 2023-04-28T02:26:59Z

Details

The main purpose of this PR is to disable the button to prevent multiple clicks during onPress call execution.
It updates the PressableWithFeedback component to achieve this. It also updates the Button component to replace the usage of Pressable with PressableWithFeedback component to make use of this for all buttons. It also updates the createWorkspace action to return a Promise.

There are some minor changes to BaseGenericPressable component as well to fix some errors discovered during implementation.

Fixed Issues

$ #14572
PROPOSAL: #14572 (comment)

Tests

Go to Settings -> Workspaces.
Click on New Workspace multiple times quickly
Verify only one workspace is created.

Verify that no errors appear in the JS console

Offline tests

Same as above

QA Steps

Go to Settings -> Workspaces.
Click on New Workspace multiple times quickly
Verify only one workspace is created.

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Web

web.mov

Mobile Web - Chrome

mweb-chrome.mov

Mobile Web - Safari

mweb-safari.mov

Desktop

desktop.mov

iOS

ios.mov

Android

disable-button-android.mov

MelvinBot · 2023-04-28T02:27:05Z

@roryabraham @s77rt One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

…eshshah11-disable-buttons

s77rt · 2023-04-28T06:44:44Z

@priyeshshah11 Thank you. I will review asap, in the meantime can you please fill the details section of the PR highlighting the main changes here? (e.g. refactor Button to use PressableWithFeedback, etc.)

priyeshshah11 · 2023-04-28T07:13:17Z

@s77rt sorry had totally missed that, updated now!

s77rt · 2023-04-28T10:09:56Z

src/components/Button/index.js

@@ -109,6 +109,9 @@ const propTypes = {

    /** Id to use for this button */
    nativeID: PropTypes.string,
+
+    /**  accessibility label for the component */
+    accessibilityLabel: PropTypes.string,


This should be required

does that mean all Buttons will need an accessibility label? & should adding all of them be in scope of this PR?

Well since accessibilityLabel is required on GenericPressable it would make sense to have this required on Button too. I think it would be better to split this to two PRs:

Migrate from Pressable to PressableWithFeedback for Button

Disable PressableWithFeedback on press

cc @roryabraham thoughts on this?

Or given that I have already done the majority of the work for both the things above, I would prefer to move updating all usages of Button to add accessibilityLabels to a seperate PR.

I agree that accessibilityLabel should be required. I also agree that we should start by disabling PressableWithFeedback on press in this PR, then create a separate PR to migrate from Pressable to PressableWithFeedback for Button.

@roryabraham I have already done the migration part in this PR as we didn't get a reply for ~2 weeks, so what's the plan of action here?

s77rt · 2023-04-28T10:10:32Z

src/components/Button/index.js

+                    (this.props.isDisabled && (this.props.success || this.props.danger)) ? styles.buttonOpacityDisabled : undefined,
+                    (this.props.isDisabled && !this.props.danger && !this.props.success) ? styles.buttonDisabled : undefined,


Why we are moving those from inner style to wrapper style?

that's how the new component works, it'll make sense when you try it out.

Can you please elaborate? Those styles were being passed to <OpacityView /> why we are passing them to <Pressable />

s77rt · 2023-04-28T10:11:11Z

src/components/Pressable/GenericPressable/BaseGenericPressable.js

            style={state => [
                getCursorStyle(isDisabled, [props.accessibilityRole, props.role].includes('text')),
-                props.style,
+                StyleUtils.parseStyleFromFunction(props.style, state),


Why this change is required?

It is required to apply styles based on the component states like isHovered, isDisabled, etc just like the lines below it. @robertKozik told me to add it so maybe he can add more context here if needed

The idea inside BaseGenericPressable was to spread styling based on Pressable state into different props (HoverStyle, focusStyle etc.). So in place of:

style={({isHovered, isPressed}) => ({ isHovered && <<hoverStyle>>, isPressed && <<pressStyle>> })}

We would get:

pressedStyle={<<pressStyle>>} hoverStyle={<<hoverStyle>>}

But as PressableWithFeedback shifts all these state-aware styling into opacityView and passes wrapperStyle as the style prop to GenericPressable, I suggested this change in order to still have the possibility of state-aware styling inside the wrapperStyle prop.

During our convo with @priyeshshah11 I came up with this change because I thought It could be used there.
All in all, even when there is no use here, this change is beneficial.

src/pages/workspace/WorkspacesListPage.js

s77rt · 2023-04-28T10:27:45Z

src/libs/actions/Policy.js

@@ -949,7 +950,7 @@ function createWorkspace(ownerEmail = '', makeMeAdmin = false, policyName = '',
        ],
    });

-    Navigation.isNavigationReady()
+    return Navigation.isNavigationReady()


Actions should not return a promise. Just revert this. The InteractionManager seems to be enough for our case, so no promise is actually needed.

but didn't @roryabraham say so here ?

This may create a pattern for further devs which I'm not sure if we want that.

But do we actually need a promise here?

yes we do need it, as InteractionManager is not enough. And I think we were aware of this pattern change & accepted it before assigning/commencing work on this PR as per @roryabraham's comments in Slack.

Yes, I understand that this is a new pattern. In general @s77rt is right that actions should not return a promise, but the spirit of that rule is that we should never be waiting for API requests to complete before doing something, because all our API interactions are completed optimistically.

What we need is a way to wait for the optimistic data to be written to Onyx and for subscribers to be updated before returning. But because that's async we need to use a Promise.

Actually at this point (the following statement may change) we are waiting for onyx data update since the optimistic data use onyx SET method which is blocking (sync).

The promise used here does not wait for onyx. It waits for navigation, it just happen that at that point onyx data is updated.

Yes, that's a very good point. I think this is maybe fine for now, but long-term we do need a better way to wait for just the optimistic data to be written to cache and for subscribers to be updated.

optimistic data use onyx SET method which is blocking (sync).

Onyx.set is async:

https://github.com/Expensify/react-native-onyx/blob/0fbe0a4d077f96c4bc30b0b14359f634b271b03b/lib/Onyx.js#L862

https://github.com/Expensify/react-native-onyx/blob/0fbe0a4d077f96c4bc30b0b14359f634b271b03b/lib/Onyx.js#L778

We could feasibly make a sync Onyx API on iOS and Android right now using JSI, but have no way to do so on web currently. We make Onyx.set async to make it more consistent with Onyx.merge

Right, sorry for the confusion I was actually referring to another behaviour. See https://expensify.slack.com/archives/C01GTK53T8Q/p1682938682704609 but that's unrelated to the PR.

yes we do need it, as InteractionManager is not enough. And I think we were aware of this pattern change & accepted it before assigning/commencing work on this PR as per @roryabraham's comments in Slack.

@priyeshshah11, hi, very sorry for the interruption. We are a little confused about the Promise here. Do you have any description or links that can show us the actual effect of this Promise? If we remove it, what problems may occur? 🙂

@ntdiary If this is not a promise then we don't have a simple way of knowing when this action completed & when to re-enable the button.

s77rt · 2023-04-29T00:39:14Z

@priyeshshah11 Can you please fix the hover style (and press style). The button looks too much dimmed than it should

main:

PR:

priyeshshah11 · 2023-04-30T10:41:34Z

@priyeshshah11 Can you please fix the hover style (and press style). The button looks too much dimmed than it should

So earlier we were using the same dimming value for hover & press which was 0.5 & now PressableWithFeedback correctly uses the pressDimValue (0.2) when pressed & pressHoverValue (0.5) when hovered. Let me know what we want.

cc: Hi 👋 @shawnborton 😄

…eshshah11-disable-buttons

s77rt · 2023-04-30T11:21:44Z

It looks too dim for a hover state 😅 Let's get this to reflect the staging values

s77rt · 2023-04-30T12:05:08Z

src/components/Button/index.js

+                    (this.props.isDisabled && (this.props.success || this.props.danger)) ? styles.buttonOpacityDisabled : undefined,
+                    (this.props.isDisabled && !this.props.danger && !this.props.success) ? styles.buttonDisabled : undefined,


Can you please elaborate? Those styles were being passed to <OpacityView /> why we are passing them to <Pressable />

s77rt · 2023-04-30T12:16:50Z

src/components/Button/index.js

+                    (this.props.success && isHovered && !isDisabled) ? styles.buttonSuccessHovered : undefined,
+                    (this.props.danger && isHovered && !isDisabled) ? styles.buttonDangerHovered : undefined,


The style here is not correct. Previously we had const activeAndHovered = !this.props.isDisabled && hovered; where the active state was solely base on the isDisabled prop. Now it's based on the isDisabled state which is based on both isDisabled prop and isLoading prop.

you're right for both the above comments, changes applied.

s77rt · 2023-04-30T12:32:36Z

src/components/Pressable/PressableWithFeedback.js

+            {...propsWithoutStyling}
+            disabled={disabled}
+            onPress={(e) => {
+                if (disabled) { return; }


Is this required? If the button is disabled how would the onPress even get called?

you're correct, I had added it as for some reason I was still able to click it while initial testing but couldn't reproduce it now so have removed it.

priyeshshah11 · 2023-04-30T12:58:17Z

It looks too dim for a hover state 😅 Let's get this to reflect the staging values

happy to change it to whatever needed, but can we please get a confirmation from @robertKozik & @shawnborton first? As I believe @robertKozik added that value here

shawnborton · 2023-05-01T12:54:33Z

Hmm we already have a value for the hover color right? And then when it is actively being pressed, we can use the .2 opacity dim.

priyeshshah11 · 2023-05-01T13:02:11Z

Hmm we already have a value for the hover color right? And then when it is actively being pressed, we can use the .2 opacity dim.

yup that's correct, hover has greenHover colour & a 0.5 opacity dim & press has 0.2 opacity dim.

shawnborton · 2023-05-01T13:03:14Z

We should not be dimming opacity on hover, we just use a different color for that. We should just have a global dim on the pressable stuff.

priyeshshah11 · 2023-05-01T13:05:58Z

@robertKozik could you please share your thoughts on why you had added/used hoverDimmingValue on hover? & is it ok for me to remove it if the design suggests so?

priyeshshah11 · 2023-05-01T13:27:46Z

@s77rt I have made the changes as per Shawn's comments above, i.e. use hover colours when hovered (without any dim) & use 0.2 opacity dim when pressed.

s77rt

Just a slight change

s77rt · 2023-05-01T14:11:25Z

src/components/Button/index.js

+                <View>
+                    {this.renderContent()}
+                    {this.props.isLoading && (
+                        <ActivityIndicator
+                            color={(this.props.success || this.props.danger) ? themeColors.textLight : themeColors.text}
+                            style={[styles.pAbsolute, styles.l0, styles.r0]}
+                        />
+                    )}
+                </View>


Suggested change

<View>

{this.renderContent()}

{this.props.isLoading && (

<ActivityIndicator

color={(this.props.success || this.props.danger) ? themeColors.textLight : themeColors.text}

style={[styles.pAbsolute, styles.l0, styles.r0]}

/>

)}

</View>

<>

{this.renderContent()}

{this.props.isLoading && (

<ActivityIndicator

color={(this.props.success || this.props.danger) ? themeColors.textLight : themeColors.text}

style={[styles.pAbsolute, styles.l0, styles.r0]}

/>

)}

</>

s77rt · 2023-05-01T14:15:46Z

@priyeshshah11 Thank you

@shawnborton Isn't 0.2 too dim compared to staging or this is actually intended?

hungvu193 · 2023-05-04T08:32:50Z

Hello guys, I'm working on an issue that need to use PressableWithFeedback and I realized when user first try to click the Submit button, the cursor will briefly change into none-select cursor for a while. Is this a feature?

Screen.Recording.2023-05-04.at.15.30.02.mov

priyeshshah11 · 2023-05-04T08:39:36Z

Hello guys, I'm working on an issue that need to use PressableWithFeedback and I realized when user first try to click the Submit button, the cursor will briefly change into none-select cursor for a while. Is this a feature?

Screen.Recording.2023-05-04.at.15.30.02.mov

That happens when a button is disabled, and we disable the button when initially clicked until the onPress is completed to avoid multiple quick clicks. But that should be only in this PR, are you using this PR in your case? could you link that issue for reference?

hungvu193 · 2023-05-04T08:53:03Z

That happens when a button is disabled, and we disable the button when initially clicked until the onPress is completed to avoid multiple quick clicks. But that should be only in this PR, are you using this PR in your case? could you link that issue for reference?

@priyeshshah11 I'm working on this issue (#17103), I need to replace TouchableOpacity with Pressable but still want to keep the activeOpacity behavior, so I decided to use PressableWithFeedback, it's working fine with mWeb, but with Web version, it will look like this:

Screen.Recording.2023-05-04.at.15.44.47.mov

So I have questions:

Should we add more props to PressableWithFeedback that allow user to interact with button multiple times in very short moment (similar with takeEvery and takeLatest in redux-saga).
In case this is feature, is there any way to prevent that or is there any alternative solution?
Thank you.

s77rt · 2023-05-05T17:36:13Z

@priyeshshah11 @roryabraham Can you please address @hungvu193's concern. Should we add an option to opt out from the "disable button on click" functionality?

priyeshshah11 · 2023-05-05T17:49:22Z

@hungvu193 I cannot answer the 1st point as that's for @roryabraham to decide but I don't see any harm in adding it if you need it. For the second point, currently there is no way to prevent this.

Either way, it doesn't need to hold up this PR.

cc: @s77rt

roryabraham · 2023-05-09T17:41:57Z

@robertKozik let me know where the best place is to discuss this, but I think having elements at .2 opacity onPress is just way too dim. Can we change that to .8 please?

If @shawnborton thinks this is best, I think we can make that change without further discussion

roryabraham · 2023-05-09T17:43:33Z

@roryabraham & @slafortune would it be fair to ask to increase the job price based on the increase in scope & effort than initially planned?

@priyeshshah11 the issue is the better place to ask this question than in the PR

roryabraham

Interesting concern from @hungvu193, and not one that I considered before. I think it is a feature that:

When a Pressable becomes disabled, then we show the none-select cursor.
When a Pressable is pressed, it becomes disabled until onPress completes to prevent multiple repeated interactions.

However, when these things both happen in a very short time period, it looks janky, and that's a problem we should solve.

In order to solve that problem, I suggest a naïve workaround to only change the cursor style after a brief timeout. Something like this (haven't tested but this should illustrate the idea):

const isDisabled = useMemo(() => {
    let shouldBeDisabledByScreenReader = false;
    if (enableInScreenReaderStates === CONST.SCREEN_READER_STATES.ACTIVE) {
        shouldBeDisabledByScreenReader = !isScreenReaderActive;
    }
    
    if (enableInScreenReaderStates === CONST.SCREEN_READER_STATES.DISABLED) {
        shouldBeDisabledByScreenReader = isScreenReaderActive;
    }
    
    return props.disabled || shouldBeDisabledByScreenReader;
}, [isScreenReaderActive, enableInScreenReaderStates, props.disabled]);
  
const [shouldUseDisabledCursor, setShouldUseDisabledCursor] = useState(isDisabled);
useEffect(() => {
    if (!isDisabled) {
        setShouldUseDisabledCursor(isDisabled);
    } else {
        setTimeout(() => setShouldUseDisabledCursor(isDisabled), 1000);
    }
}, [isDisabled]);


...
...

getCursorStyle(shouldUseDisabledCursor, [props.accessibilityRole, props.role].includes('text')),

priyeshshah11 · 2023-05-10T16:55:39Z

Interesting concern from @hungvu193, and not one that I considered before. I think it is a feature that:

@roryabraham I assume you're asking for this feature to be implemented in a seperate PR as it wasn't in the scope for this PR, right?

…eshshah11-disable-buttons

priyeshshah11 · 2023-05-12T09:49:45Z

Interesting concern from @hungvu193, and not one that I considered before. I think it is a feature that:

@roryabraham I assume you're asking for this feature to be implemented in a seperate PR as it wasn't in the scope for this PR, right?

@roryabraham could you please confirm? or merge this PR if it's good to go?

cc: @s77rt @mananjadhav

s77rt · 2023-05-12T18:58:11Z

I'm okay going either way. Deferring to @roryabraham

roryabraham

Ok, we can handle this in a follow-up

OSBotify · 2023-05-12T19:07:45Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

OSBotify · 2023-05-15T09:19:32Z

🚀 Deployed to staging by https://github.com/roryabraham in version: 1.3.14-0 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

OSBotify · 2023-05-17T00:19:22Z

🚀 Deployed to production by https://github.com/yuwenmemon in version: 1.3.14-14 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

0xmiros · 2023-05-19T16:14:21Z

src/libs/actions/Policy.js

@@ -1078,7 +1079,7 @@ function createWorkspace(ownerEmail = '', makeMeAdmin = false, policyName = '',
        },
    );

-    Navigation.isNavigationReady().then(() => {
+    return Navigation.isNavigationReady().then(() => {


Coming from #17452 (comment), this return promise is not used anywhere. So this change is unnecessary.
Can you please confirm?
cc: @roryabraham @priyeshshah11 @s77rt @mananjadhav

Oops we were actually supposed to return a value on Button. ~~We still need the promise though.~~ Actually we may not need it. I raised this here #18122 (comment) already. Gven that this worked even that the promise was never used then it's probably not needed.

@priyeshshah11 Can you please raise a quick follow up PR?

But I couldn't reproduce the original issue with this PR. Still need promise though?

cc: @tgolen @ntdiary

Looks like we don't need it.

@s77rt what's the conclusion here? do you still want me to raise another PR? to remove the promise part or instead return it from the onPress? My view is that we should keep it & return it but up to you.

@priyeshshah11 Raise a PR that simply return the onPress on Button. (promise may be removed on the other PR)

@s77rt here it is #19378

s77rt · 2023-06-29T11:41:37Z

src/components/Pressable/PressableWithFeedback.js

+                InteractionManager.runAfterInteractions(() => {
+                    if (!(onPress instanceof Promise)) {
+                        setDisabled(props.disabled);


The props.disabled that we are using inside the InteractionManager.runAfterInteractions callback or the one after the promise is resolved (few lines below) is evaluated at the time we call onPress and that value is used later. Meaning props.disabled does not reflect the current state but the state that we evaluated when onPress was initially called.

To better explain, here is an example:

props.disabled is false

Call onPress

Evaluate the promise callback, After the promise is resolved we will call setDisabled(false) // props.disabled is evaluated now

Promise is not resolved yet (button action still being executed)

props.disabled is set to true

Promise is resolved

Now we will call the previously evaluated callback which is setDisabled(false) even though the current props.disabled is true

This logic is copied from OptionRow but we missed that case in both PRs which lead to a regression #20983.

added disabling of Button during onPress call in PressableWithFeedback

4471e8b

priyeshshah11 requested a review from a team as a code owner April 28, 2023 02:27

melvin-bot bot requested review from roryabraham and s77rt and removed request for a team April 28, 2023 02:27

priyeshshah11 changed the title ~~added disabling of Button during onPress call in PressableWithFeedback~~ Disables the Button during onPress call in PressableWithFeedback Apr 28, 2023

priyeshshah11 mentioned this pull request Apr 28, 2023

[HOLD for payment 2023-06-01] [HOLD for payment 2023-05-23] [$2000] Fast clicking any button 'n' times execute 'n' times #14572

Closed

1 task

Merge branch 'main' of https://github.com/priyeshshah11/App into priy…

90d9b72

…eshshah11-disable-buttons

s77rt suggested changes Apr 28, 2023

View reviewed changes

hoangzinh mentioned this pull request Apr 28, 2023

[HOLD on #16506] [$1000] Double-tapping on an existing emoji reaction sends multiple API requests #17978

Closed

6 tasks

code cleanup

0c045be

Merge branch 'main' of https://github.com/priyeshshah11/App into priy…

fcee719

…eshshah11-disable-buttons

s77rt suggested changes Apr 30, 2023

View reviewed changes

code cleanup

76500fc

fixed hover & pressed styles

cb06109

s77rt suggested changes May 1, 2023

View reviewed changes

replace View with frgament

11a0929

hungvu193 mentioned this pull request May 4, 2023

[HOLD for payment 2023-06-01] [HOLD PR #18865][$1000] iOS / Safari - On long pressing "terms of service" link it gets completely hidden #17103

Closed

6 tasks

roryabraham requested changes May 9, 2023

View reviewed changes

Merge branch 'main' of https://github.com/priyeshshah11/App into priy…

bba4458

…eshshah11-disable-buttons

priyeshshah11 dismissed mananjadhav’s stale review via bba4458 May 10, 2023 17:03

hungvu193 mentioned this pull request May 11, 2023

[$1000] Confirm Task menu item is cut off on touch #18753

Closed

6 tasks

roryabraham approved these changes May 12, 2023

View reviewed changes

roryabraham merged commit 756e9d8 into Expensify:main May 12, 2023

roryabraham mentioned this pull request May 12, 2023

[HOLD for payment 2023-05-25] [$1000] Disabled cursor briefly shows #18862

Closed

6 tasks

OSBotify mentioned this pull request May 15, 2023

Deploy Checklist: New Expensify 2023-05-15 #18938

Closed

67 tasks

ntdiary mentioned this pull request May 15, 2023

clean up the deep link code #17452

Merged

56 tasks

0xmiros reviewed May 19, 2023

View reviewed changes

priyeshshah11 mentioned this pull request May 22, 2023

return onPress callback from Button #19378

Merged

57 tasks

Pujan92 mentioned this pull request Jun 12, 2023

Fix: Resend magic code option behaves inconsistently #18632

Merged

57 tasks

s77rt reviewed Jun 29, 2023

View reviewed changes

rfwoolf mentioned this pull request Jul 12, 2023

[HOLD for payment 2023-08-08] [$1000] Web - Assign Task - Delay in transitioning from a hand cursor to a "not allowed" sign. #22058

Closed

6 tasks

		(this.props.isDisabled && (this.props.success \|\| this.props.danger)) ? styles.buttonOpacityDisabled : undefined,
		(this.props.isDisabled && !this.props.danger && !this.props.success) ? styles.buttonDisabled : undefined,

		(this.props.success && isHovered && !isDisabled) ? styles.buttonSuccessHovered : undefined,
		(this.props.danger && isHovered && !isDisabled) ? styles.buttonDangerHovered : undefined,

Disables the Button during onPress call in PressableWithFeedback #18122

Disables the Button during onPress call in PressableWithFeedback #18122

Conversation

priyeshshah11 commented Apr 28, 2023 • edited Loading

Details

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

MelvinBot commented Apr 28, 2023

s77rt commented Apr 28, 2023

priyeshshah11 commented Apr 28, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priyeshshah11 Apr 28, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

s77rt May 9, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

s77rt commented Apr 29, 2023

priyeshshah11 commented Apr 30, 2023

s77rt commented Apr 30, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priyeshshah11 commented Apr 30, 2023

shawnborton commented May 1, 2023

priyeshshah11 commented May 1, 2023

shawnborton commented May 1, 2023

priyeshshah11 commented May 1, 2023

priyeshshah11 commented May 1, 2023

s77rt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

s77rt commented May 1, 2023

hungvu193 commented May 4, 2023

priyeshshah11 commented May 4, 2023

hungvu193 commented May 4, 2023

s77rt commented May 5, 2023

priyeshshah11 commented May 5, 2023

roryabraham commented May 9, 2023

roryabraham commented May 9, 2023

roryabraham left a comment

Choose a reason for hiding this comment

priyeshshah11 commented May 10, 2023

priyeshshah11 commented May 12, 2023

s77rt commented May 12, 2023

roryabraham left a comment

Choose a reason for hiding this comment

OSBotify commented May 12, 2023

OSBotify commented May 15, 2023

OSBotify commented May 17, 2023

Choose a reason for hiding this comment

s77rt May 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priyeshshah11 commented Apr 28, 2023 •

edited

Loading

priyeshshah11 Apr 28, 2023 •

edited

Loading

s77rt May 9, 2023 •

edited

Loading

s77rt May 19, 2023 •

edited

Loading