-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Conversation
|
@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. |
Fix StagingDeployBlocker where chat draft message is kept in the test input while switching chats (cherry picked from commit e9b3a59)
There was a problem hiding this 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
I should have created the test github account with a different name/tag haha 😄 |
Lol clearly tagging people is not my forte 🤣 |
@luacmartins 😂 I admit this is definitely more my fault haha |
🚀 Cherry-picked to staging by @HorusGoul in version: 1.0.86-4 🚀
@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}); | ||
} |
There was a problem hiding this comment.
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:
App/src/pages/home/report/ReportActionCompose.js
Lines 312 to 320 in 9135cfb
updateComment(newComment) { | |
this.textInput.setNativeProps({text: newComment}); | |
this.setState({ | |
isCommentEmpty: newComment.length === 0, | |
}); | |
this.comment = newComment; | |
this.debouncedSaveReportComment(newComment); | |
this.debouncedBroadcastUserIsTyping(); | |
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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... :)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 🤔
🚀 Deployed to production by @roryabraham in version: 1.0.86-11 🚀
|
🚀 Deployed to production by @roryabraham in version: 1.0.88-2 🚀
|
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 betweenthis.props
andprevProps
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
Screenshots
Web
Screen.Recording.2021-08-20.at.14.59.02.mov
Mobile Web
Desktop
iOS
Android