Page MenuHomePhabricator

[web] Memoize friend list row buttons
ClosedPublic

Authored by tomek on May 11 2022, 8:36 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, May 15, 12:37 PM
Unknown Object (File)
Wed, May 15, 12:36 PM
Unknown Object (File)
Wed, May 15, 12:36 PM
Unknown Object (File)
Wed, May 15, 12:36 PM
Unknown Object (File)
Wed, May 15, 12:36 PM
Unknown Object (File)
Tue, May 14, 4:53 AM
Unknown Object (File)
Fri, Apr 19, 7:11 PM
Unknown Object (File)
Fri, Apr 19, 7:11 PM

Details

Summary

Shouldn't matter that much, but still it is probably a good idea

Depends on D4007

Test Plan

The same as D4007. Also check if cancel request and reject still work.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Add explicit return undefined

This revision is now accepted and ready to land.May 11 2022, 10:47 AM
This revision now requires review to proceed.May 12 2022, 8:16 AM
atul added inline comments.
web/settings/relationship/friend-list-row.react.js
64 ↗(On Diff #12559)

Not sure we need to explicitly include this return undefined

If we do include it, imo it should be an early return at the start of the useMemo block (though that conditional would probably be pretty verbose)

It's kind of "hidden" here at the bottom

This revision is now accepted and ready to land.May 12 2022, 9:00 AM
web/settings/relationship/friend-list-row.react.js
64 ↗(On Diff #12559)

My preference is that if a function ever does return something;, then every code branch should have an explicit return something;

(Does not apply if the only return in a function is a simple return;)

web/settings/relationship/friend-list-row.react.js
64 ↗(On Diff #12559)

I don't have a strong preference and having an implicit return undefined is fine for me - but we have a convention so it's best to keep it.

Regarding @atul suggestion, I don't agree it is a good idea. Adding an if at the beginning will introduce a duplication in our logic. If we ever decide to have a new branch, we would need to update two places - so keeping it at sync would be more expensive.

Early returns are generally advantageous, but only if they simplify the logic and mental effort. They shouldn't be the goal on their own.

One possible option would be to create an object with status as a key and function that returns a React.Node as a value. Then we can have an early return without compromising the maintainability, but I don't think it is worth it.

This revision was automatically updated to reflect the committed changes.