Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix StagingDeployBlocker where chat draft message is kept in the test input while switching chats #4761

Merged
merged 2 commits into from
Aug 20, 2021

Conversation

mountiny
Copy link
Contributor

@mountiny mountiny commented Aug 20, 2021

cc @marcaaron @luacmartins

Details

Testing on Staging has discovered a bug when using a Search sidebar modal to switch between chats does not update the composer box and draft from previous chat is shown in the new chat.

The issue was most likely introduced in this PR #4538. As a result of the refactoring the ReportActionCompose does not mount when switching the chats using the search bar and hence the text input is to updated either.

As a probably temporary workaround, I have updated the componentDidUpdate function to check if the comment value has changed between this.props and prevProps and update it manually using ref.

Fixed Issues

$ #4756

Tests

QA Steps

Follow the steps described in the linked issue #4756 and make sure that the bug does not prevail.

Tested On

  • Web
  • Mobile Web
  • Desktop
  • iOS
  • Android

Screenshots

Web

Screen.Recording.2021-08-20.at.14.59.02.mov

Mobile Web

Desktop

iOS

Android

@mountiny mountiny requested a review from a team as a code owner August 20, 2021 13:55
@mountiny mountiny self-assigned this Aug 20, 2021
@MelvinBot MelvinBot requested review from HorusGoul and removed request for a team August 20, 2021 13:55
@mountiny mountiny changed the title Update the comment in text input manually in componentUpdate Fix StagingDeployBlocker where chat draft message is kept in the test input while switching chats Aug 20, 2021
@github-actions
Copy link
Contributor

⚠️ ⚠️ Heads up! This pull request has the CP Staging label. ⚠️ ⚠️
Merging it will cause it to be immediately deployed to staging, even if the open StagingDeployCash deploy checklist is locked.

@mountiny
Copy link
Contributor Author

@HorusGoul We still need to test it on mobile, especially Android if the workaround does not cause too much of a trouble.

@HorusGoul
Copy link
Contributor

@HorusGoul We still need to test it on mobile, especially Android if the workaround does not cause too much of a trouble.

Tested! Working fine in both iOS and Android.

@HorusGoul HorusGoul merged commit e9b3a59 into main Aug 20, 2021
@HorusGoul HorusGoul deleted the vit-testForDeployBlocker branch August 20, 2021 15:22
github-actions bot pushed a commit that referenced this pull request Aug 20, 2021
Fix StagingDeployBlocker where chat draft message is kept in the test input while switching chats

(cherry picked from commit e9b3a59)
Copy link
Contributor

@luacmartins luacmartins left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks for the fix @vitHoracek

@mountiny
Copy link
Contributor Author

I should have created the test github account with a different name/tag haha 😄

@luacmartins
Copy link
Contributor

Lol clearly tagging people is not my forte 🤣

@mountiny
Copy link
Contributor Author

@luacmartins 😂 I admit this is definitely more my fault haha

@OSBotify
Copy link
Contributor

🚀 Cherry-picked to staging by @HorusGoul in version: 1.0.86-4 🚀

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

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

// so we need to update the comment manually.
if (prevProps.comment !== this.props.comment) {
this.textInput.setNativeProps({text: this.props.comment});
}
Copy link
Contributor

Choose a reason for hiding this comment

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

What about updating this.comment as well in this block or does that not matter? Honestly, I don't totally get why we started using setNativeProps() for this in the first place (I think to fix some bug) - but seeing this updateComment() makes me think it should be the one used here:

updateComment(newComment) {
this.textInput.setNativeProps({text: newComment});
this.setState({
isCommentEmpty: newComment.length === 0,
});
this.comment = newComment;
this.debouncedSaveReportComment(newComment);
this.debouncedBroadcastUserIsTyping();
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see, I have not considered the updateComment(), but I agree now it might be better. I was trying to go with as small change as possible because I have tried updating this.comment too, but it worked the same as without explicitly updating it, so I took it away.

I can submit a PR to use updateComment function and leave it in main and not CP as the functionality is same for now (at least what I could have seen myself).

I thought this would only be a temporary workaround because the componentDidUpdate function is called many times so we should aim to put as little logic in there as possible.

Copy link
Contributor

Choose a reason for hiding this comment

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

I can submit a PR to use updateComment function and leave it in main and not CP as the functionality is same for now (at least what I could have seen myself).

That sounds good to me. One reason why I would maybe use this is that if we refactor or change the setNativeProps thing in the future there will be only one place where we did it. Or said another way setting the native props is feels like more of a "detail" of the "update comment" code we are running.

I thought this would only be a temporary workaround because the componentDidUpdate function is called many times so we should aim to put as little logic in there as possible.

I'm curious what would the real solution be? It's fine to have logic in this method as long as we check when we should run it e.g. if we only need this to happen when the report switches then maybe it would be better to look at another prop besides the comment. I have one in mind... :)

Copy link
Contributor Author

@mountiny mountiny Aug 20, 2021

Choose a reason for hiding this comment

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

Created a PR here 🙌

Or said another way setting the native props is feels like more of a "detail" of the "update comment" code we are running.

You are right there could be some hidden problem along the way by using solely the ref to update it. I think the reason it work d is that the component gets to the correct state eventually, but there is the couple of renders, which are still with the old reportID, which are causing the initial bug.

I have one in mind... :)

Thank you for the sneaky hint :) I have used this.props.report.reportID, because the reportID changes before the this.props.report is updated to the correct one and thus the bug would prevail.

Copy link
Contributor

Choose a reason for hiding this comment

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

but there is the couple of renders, which are still with the old reportID, which are causing the initial bug.

Let's discuss this in the new PR. I'm not sure I am getting why the reportID itself could not be used 🤔

@OSBotify
Copy link
Contributor

🚀 Deployed to production by @roryabraham in version: 1.0.86-11 🚀

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

@OSBotify
Copy link
Contributor

🚀 Deployed to production by @roryabraham in version: 1.0.88-2 🚀

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

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.

5 participants