-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Implement Archived Workspace Chat UI #7831
Conversation
@@ -1329,6 +1320,15 @@ const styles = { | |||
minHeight: variables.componentSizeNormal, | |||
}, | |||
|
|||
chatFooter: { |
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.
This is the same as chatItemCompose
, just renamed. I just moved it so that it wasn't in between a number of other chatItem*
styles.
# Conflicts: # src/pages/home/report/ReportActionCompose.js
Updated. @TomatoToaster let me know if this is what you had in mind, not sure i completely understood your last comment. |
# Conflicts: # src/pages/home/report/ReportActionCompose.js
This is ready for review. The welcome messages are still weird for archived workspace chats but I'd prefer to handle that in a follow-up if that's okay with everyone. Created an issue here: #8272 |
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.
Looks great - had a few ideas for improvement.
@@ -87,20 +88,20 @@ function formatPersonalDetails(personalDetailsList) { | |||
|
|||
// This method needs to be SUPER PERFORMANT because it can be called with a massive list of logins depending on the policies that someone belongs to | |||
// eslint-disable-next-line rulesdir/prefer-underscore-method | |||
Object.keys(personalDetailsList).forEach((login) => { | |||
const personalDetailsResponse = personalDetailsList[login]; | |||
Object.entries(personalDetailsList).forEach(([login, details]) => { |
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.
The terrifying comment above this line seems to imply that Object.keys()
+ forEach()
is more performant than underscore. I can't really think of why that would be, but at the same time my default is to trust whoever wrote it.
Since we are changing this to Object.entries()
is there some way we can verify there are no performance regressions. Maybe testing against production with an account that will have many personal details (someone who has been at Expensify for a while perhaps)?
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.
Since we are changing this to Object.entries() is there some way we can verify there are no performance regressions. Maybe testing against production with an account that will have many personal details (someone who has been at Expensify for a while perhaps)?
Yes, I can add QA steps here.
FWIW here is the PR that introduced that, and the problem with the code before wasn't necessarily that we were using underscore instead of vanilla JS, just that we were using the spread operator in a reduce
, which is an O(n^2)
operation because it copies the whole object for every iteration.
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.
So it would probably be safe to just use _.each(personalDetailsList, (details, login) => {...})
because it doesn't have that spread inside a reduce.
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.
Added QA steps. Applause has access to some high-volume accounts with large policies (Expensify.org policies I think) that will give them thousands of personalDetails
.
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.
A bit of extra context here: #7649 (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.
Ok cool. It's a weird comment then and sounds like we could update this to use underscore, but NAB.
/> | ||
</View> | ||
{ | ||
props.shouldRenderHTML |
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.
NAB, alternatively just always render HTML because plain text run through an HTML renderer is just text anyway
@@ -87,20 +88,20 @@ function formatPersonalDetails(personalDetailsList) { | |||
|
|||
// This method needs to be SUPER PERFORMANT because it can be called with a massive list of logins depending on the policies that someone belongs to | |||
// eslint-disable-next-line rulesdir/prefer-underscore-method | |||
Object.keys(personalDetailsList).forEach((login) => { | |||
const personalDetailsResponse = personalDetailsList[login]; | |||
Object.entries(personalDetailsList).forEach(([login, details]) => { |
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.
Ok cool. It's a weird comment then and sounds like we could update this to use underscore, but NAB.
I think we can merge this because the remaining NAB is minor. We can open a separate PR if we want to remove the renderHTML and test it works the same on all platforms. |
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Deployed to staging by @TomatoToaster in version: 1.1.46-0 🚀
|
@roryabraham We are seeing the following numbers in Console. Response is missing time variant. Let us know if this looks good |
Thanks. That's in |
@roryabraham @marcaaron FYI I believe this PR caused this bug: #13452 |
Actually nvm. I think it was this PR actually: #11363 |
Details
Implements the Archived Workspace Chat UI.
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/195474
Tests
Storybook
Run storybook, verify that you can see the new stories for the
Banner
component.There are a number of issues with Storybook at present, none having to do with this PR or the new stories.
Setup
Settings
><Your workspace>
>Manage members
and invite all four employees to the workspace.Account Closed
Open the workspace chat for employee A. Verify that it's in the open state.
BUG
: I had to sign out and sign back in for the workspace chat(s) to appear.Sign into OldDot as employee A. Go to
Settings
>Account
>Account Details
and close the account.Go back to NewDot. Verify that the workspace chat for employee is archived, and that you see the following:
BUG
: I had to refresh the page for the UI to update.Go back to the workspace chat for the employee w/ the closed account, and verify that you see the following:
Account Merged
Sign in to NewDot as employee B.
Go to
Settings
>Profile
and set a first and last nameSign in to NewDot as employee C.
Go to
Settings
>Profile
and set a first and last nameSign in to NewDot as the admin and find the workspace chat for employee C.
Sign in to OldDot as employee B.
Go to
Settings
>Account
>Account Details
and merge employee C's account into employee B's account.Go back to NewDot and employee C's workspace chat should now look like this:
Go to NewDot
Settings
>Preferences
and switch the language to Spanish.Go back to the workspace chat for employee C and you should see the following copy:
Removed from Policy
Testing blocked on https://github.com/Expensify/Auth/pull/6456
Policy Deleted
Testing blocked on https://github.com/Expensify/Auth/pull/6456
QA Steps
Most of this will be tested internally before we add a large suite of regressions to cover workspace chats. However, there is something that needs to be QA'd here (Chrome web only) to prevent performance regressions.
Sign out.
Open the JS console. Make sure you have verbose logs enabled. This dropdown should say
All Levels
:Sign into a high traffic account with very large policies.
Search the logs for
Timing:expensify.cash.personal_details_formatted
Verify that the number is very low (ideally less than
1000ms
).Repeat these same steps on production with the same account, and post the difference in timing between staging and production in this PR.
Tested On
Screenshots
Web
All of the screenshots for the above steps were taken on web.
Mobile Web
Desktop
iOS
Android