Page MenuHomePhabricator

[lib] introduce createPendingPersonalThread function
ClosedPublic

Authored by ginsu on Sep 19 2023, 3:09 PM.
Tags
None
Referenced Files
F3002073: D9235.id31355.diff
Fri, Oct 18, 6:17 AM
F3001399: D9235.id31289.diff
Fri, Oct 18, 4:26 AM
F3001392: D9235.id31353.diff
Fri, Oct 18, 4:25 AM
Unknown Object (File)
Mon, Oct 14, 6:55 PM
Unknown Object (File)
Mon, Oct 14, 5:51 PM
Unknown Object (File)
Mon, Oct 14, 5:03 PM
Unknown Object (File)
Mon, Oct 14, 1:39 PM
Unknown Object (File)
Sat, Sep 21, 9:14 PM
Subscribers

Details

Summary

This diff introduces a helper function called createPendingPersonalThread. At the moment we are going to use this function if we search for a user that we don't have a preexisting shared personal thread yet, but we will also need to do the same thing for user profiles (if we view a user profile that we don't have a preexisting shared personal thread yet).

Depends on D9120

Test Plan

flow and confirmed that there are no regressions with the search experience when I try and search for a user that I don't already have a thread with yet

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

ginsu requested review of this revision.Sep 19 2023, 3:27 PM
ginsu added reviewers: atul, inka.

Adding @ashoat and @tomek here since I don't have a ton of context on pending threads

ashoat requested changes to this revision.Sep 20 2023, 2:28 PM
ashoat added inline comments.
lib/shared/thread-utils.js
420 ↗(On Diff #31314)

There's something subtly different here: you're stripping any properties other than id and username from the pendingPersonalThreadUserInfo that you pass in as part of members to createPendingThread.

Previously, the UserIDAndUsername would be passed in whole-sale.

Can you explain / justify this change?

This revision now requires changes to proceed.Sep 20 2023, 2:28 PM
ginsu added inline comments.
lib/shared/thread-utils.js
420 ↗(On Diff #31314)

Sorry I can see how this is concerning/I should have called this out prior to review...

Anyways, in the createPendingThread function for members we only care about the id and username fields since we recreate userInfos object within that function using only those fields. In other places where we use members in createPendingThread we only grab the id:

Since we aren't accessing any of the other fields for UserInfo, it is a personal preference of mine to be very explicit and only pass in what is needed instead of passing in an entire object. I feel like it also makes the function more clear that these are the exact parameters that are needed for the function to work.

However, if we prefer to use the UserIDAndUsername type I can update this diff to fix this

ashoat added inline comments.
lib/shared/thread-utils.js
420 ↗(On Diff #31314)

Thanks for explaining!

This revision is now accepted and ready to land.Sep 21 2023, 12:59 PM
This revision was landed with ongoing or failed builds.Sep 21 2023, 1:45 PM
This revision was automatically updated to reflect the committed changes.