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

[Performance] Refactor SidebarLinks to not use getDerivedStateFromProps() and other static methods #7948

Closed
1 task
marcaaron opened this issue Mar 1, 2022 · 11 comments
Assignees
Labels
Engineering Improvement Item broken or needs improvement. Internal Requires API changes or must be handled by Expensify staff Monthly KSv2 Plane An item that takes a good amount of time like big refactors / code removals and can be done offline.

Comments

@marcaaron
Copy link
Contributor

marcaaron commented Mar 1, 2022

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!


Coming from https://github.com/Expensify/App/pull/7907/files#r816376801

Code cleanup

The file here seems to be following some practices that we should avoid because they are very uncommon in this codebase:

static getDerivedStateFromProps(nextProps, prevState) {
const shouldReorder = SidebarLinks.shouldReorder(nextProps, prevState.orderedReports, prevState.currentlyViewedReportID, prevState.unreadReports);
const recentReports = SidebarLinks.getRecentReports(nextProps);
const orderedReports = shouldReorder
? recentReports
: _.map(prevState.orderedReports,
orderedReport => _.chain(recentReports)
.filter(recentReport => orderedReport.reportID === recentReport.reportID)
.first()
.value());

There are some well documented reasons why we should use this and not here:

https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html

And it looks like we just want to perform a side effect where when various props change we update the reports we display in the sidebar. But for some reason have used derived state to do this instead of something like componentDidUpdate().

Finding this component pretty hard to understand in general...

Solution

  1. Clean this up and make it use componentDidUpdate()
  2. Put something in the style guide or eslint rule to forbid this practice
@marcaaron marcaaron added Engineering Monthly KSv2 Improvement Item broken or needs improvement. labels Mar 1, 2022
@marcaaron marcaaron self-assigned this Mar 1, 2022
@marcaaron marcaaron changed the title Refactor SidebarLinks to not use getDerivedStateFromProps() and other static methods Refactor SidebarLinks to not use getDerivedStateFromProps() and other static methods Mar 1, 2022
@ctkochan22
Copy link
Contributor

Taking up your offer on letting me steal this :)

@ctkochan22 ctkochan22 self-assigned this Mar 1, 2022
@parasharrajat
Copy link
Member

parasharrajat commented Mar 1, 2022

There is one more component that uses it. PopoverWithMeasuredContent.

But I think it is needed there. The popover render function is expensive for EmojiPicker and using it prevents render until we are fully ready. I don't exactly remember why I used it there but there was a race condition that I was trying to overcome.

@marcaaron
Copy link
Contributor Author

Thanks @parasharrajat. This issue is just for SidebarLinks and not all usages of getDerivedStateFromProps(). But I do think we should treat it as a potential anti-pattern and call attention to it if ever observed (hence why adding something the style guide would be good).

@parasharrajat
Copy link
Member

Ok. Great.

@ctkochan22
Copy link
Contributor

Punting

@melvin-bot
Copy link

melvin-bot bot commented Jun 14, 2022

@marcaaron, this Monthly task hasn't been acted upon in 6 weeks; closing.

If you disagree, feel encouraged to reopen it -- but pick your least important issue to close instead.

@melvin-bot melvin-bot bot closed this as completed Jun 14, 2022
@marcaaron marcaaron added Plane An item that takes a good amount of time like big refactors / code removals and can be done offline. Internal Requires API changes or must be handled by Expensify staff and removed Not a priority labels Jun 15, 2022
@marcaaron marcaaron reopened this Jun 15, 2022
@tgolen tgolen self-assigned this Aug 23, 2022
@melvin-bot melvin-bot bot added the Overdue label Aug 31, 2022
@tgolen
Copy link
Contributor

tgolen commented Aug 31, 2022

Work is coming along here nicely. Getting a lot of unit tests written

@melvin-bot melvin-bot bot removed the Overdue label Aug 31, 2022
@trjExpensify
Copy link
Contributor

Added this App issue to the WhatsApp Quality project to keep track of it.

@tgolen
Copy link
Contributor

tgolen commented Sep 14, 2022

Got the first PR done which optimizes some of the current code which figures out the order reports should be displayed in. My second PR refactors the sidebar to render items more efficiently.

@tgolen
Copy link
Contributor

tgolen commented Sep 19, 2022

The last PR is in final stages of review and testing. It should merge this week!

@JmillsExpensify JmillsExpensify changed the title Refactor SidebarLinks to not use getDerivedStateFromProps() and other static methods [Performance] Refactor SidebarLinks to not use getDerivedStateFromProps() and other static methods Sep 22, 2022
@tgolen
Copy link
Contributor

tgolen commented Sep 28, 2022

This is all done

@tgolen tgolen closed this as completed Sep 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Engineering Improvement Item broken or needs improvement. Internal Requires API changes or must be handled by Expensify staff Monthly KSv2 Plane An item that takes a good amount of time like big refactors / code removals and can be done offline.
Projects
None yet
Development

No branches or pull requests

6 participants