Page MenuHomePhabricator

[flow] Update `useResolvedThreadInfo` and fix subsequent `flow` issues
ClosedPublic

Authored by atul on Nov 15 2023, 1:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Oct 26, 12:55 AM
Unknown Object (File)
Mon, Oct 21, 2:17 AM
Unknown Object (File)
Sat, Oct 12, 4:52 PM
Unknown Object (File)
Sat, Oct 12, 4:52 PM
Unknown Object (File)
Sat, Oct 12, 4:52 PM
Unknown Object (File)
Sat, Oct 12, 4:52 PM
Unknown Object (File)
Sat, Oct 12, 4:52 PM
Unknown Object (File)
Sat, Oct 12, 4:52 PM
Subscribers
None

Details

Summary

As mentioned in D9896, there were quite a few places where refactoring code to accept MinimallyEncodedThreadInfo required the useResolvedThreadInfo hook to be updated. Updating that hook required a bunch of changes, which in turn required even more changes, etc.

There wasn't a super obvious way to break down the refactoring going into this since I was responding to flow issues as they surfaced, so apologize for the large diff. I think that the changes are straightforward enough that this is fine, but I can go back and chunk changes into separate diffs if that would make things easier to review.


Depends on D9896

Test Plan

Trusting flow, but also based on feedback here: https://phab.comm.dev/D9896#inline-61685... will make sure to read through this carefully a couple times and ensure the "base type(s)" and "minimally encoded type(s)" match up.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

lib/shared/thread-utils.js
1385–1399 ↗(On Diff #33304)

We have to branch here because unfortunately I wasn't able to refactor getCurrentUser to handle both ThreadInfo and MinimallyEncodedThreadInfo.

I'll give it another shot though, have a few ideas to try.

web/modals/threads/create/steps/subchannel-members-list.react.js
44–45 ↗(On Diff #33304)

We needed to get members from parentThreadInfo after minimallyEncoded check in order for this to work. Flow wasn't able to narrow the type of parentMembers that was previously destructured.

atul published this revision for review.Nov 15 2023, 2:01 PM

This was a massive diff. I really would've appreciated it if you had broken it down further like I requested yesterday. When you have a diff that is so huge, it's your responsibility as the diff author to make sure each line is basically identical and trivial. I would strongly prefer that next time, you break down ANYTHING that isn't "identical and trivial" into a separate, freestanding diff. Accepting this to unblock but please internalize this feedback – I will request changes next time

lib/shared/thread-utils.js
1320–1325 ↗(On Diff #33305)

Are you sure this function doesn't need to be parameterized? I would guess that if the caller gives you a ThreadInfo they want a ThreadInfo back, and vice versa. But not sure how / where it's used

1385–1393 ↗(On Diff #33305)

This change probably should've been a separate diff

lib/utils/drawer-utils.react.js
65 ↗(On Diff #33305)

This change probably should've been a separate diff

web/modals/threads/create/steps/subchannel-members-list.react.js
23 ↗(On Diff #33305)

Changes to this file really should've been in a separate diff imo

44–60 ↗(On Diff #33305)

Is there a way to keep the branching but reduce the copy-paste? Seems like a pretty "high level" to branch at

73–101 ↗(On Diff #33305)

Is there a way to keep the branching but reduce the copy-paste? Seems like a pretty "high level" to branch at

This revision is now accepted and ready to land.Nov 16 2023, 5:46 AM

add comment to parameterize function

lib/shared/thread-utils.js
1320–1325 ↗(On Diff #33305)

Yes it will be once createPendingThread is updated. For now createPendingThread always returns ThreadInfo:

6358f7.png (438×860 px, 53 KB)

I will put a TODO for the time being.

web/modals/threads/create/steps/subchannel-members-list.react.js
44–60 ↗(On Diff #33305)

Was able to pull the .filter and .map into a separate function where the "input" was typed as

$ReadOnlyArray<RelativeMemberInfo | MinimallyEncodedRelativeMemberInfo>

and was able to get rid of copy/paste and branching:

030d36.png (978×1 px, 172 KB)

Open to any other solutions.

Will put this in a separate followup diff so it's easier to review.

73–101 ↗(On Diff #33305)

Same as above, was able to refactor:

c803f5.png (1×1 px, 199 KB)

Will put in followup diff so it can be reviewed separately.

web/modals/threads/create/steps/subchannel-members-list.react.js
44–60 ↗(On Diff #33305)
This revision was landed with ongoing or failed builds.Nov 16 2023, 2:09 PM
This revision was automatically updated to reflect the committed changes.
lib/utils/entity-helpers.js
93

The new version of Flow revealed a type error in this diff. Now that useResolvedThreadInfos might return MinimallyEncodedThreadInfo, we need to do one of two things here:

  1. Update this method to do the same
  2. Update useResolvedThreadInfos to have a type param, so that this method can call it with ThreadInfo and know that it'll get ResolvedThreadInfo back
    • This might be difficult with Flow. I'd suggest using $If and $IsA constructions like this... then you might be able to do something like:
$If<
  $IsA<T, MinimallyEncodedThreadInfo>,
  MinimallyEncodedResolvedThreadInfo,
  ResolvedThreadInfo,
>

One more

lib/shared/thread-utils.js
1735

This change is also causing a type error with the new Flow on this line.

This one should be easier to resolve than the other one, though... I think you can add a simple type param to resolve it

native/input/input-state-container.react.js
516–525

When you add the type parameterization I suggest above, you'll need to get rid of this branching – it's causing a Flow error when minimallyEncoded is being read

web/input/input-state-container.react.js
1287–1296

When you add the type parameterization I suggest above, you'll need to get rid of this branching – it's causing a Flow error when minimallyEncoded is being read

lib/shared/thread-utils.js
1735

Actually, it's not as easy as simply adding a type param... you'll need to parameterize createPendingThread too, which results in a new set of errors

Let's discuss this ASAP

lib/shared/thread-utils.js
1735

Do you happen to have the type error that occurs on that line in web/input/input-state-container.js handy?

lib/shared/thread-utils.js
1735

This is the error that occurs in web/input/input-state-container.js when I revert the changes to patchThreadInfoToIncludeMentionedMembersOfParent here:

Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ input/input-state-container.react.js:1322:38

Cannot get threadInfo.minimallyEncoded because property minimallyEncoded is missing in ThreadInfo [1]. [prop-missing]

 [1] 1247│     inputThreadInfo: ThreadInfo,
         :
     1319│     };
     1320│
     1321│     // Branching to appease `flow`.
     1322│     const newThreadInfo = threadInfo.minimallyEncoded
     1323│       ? {
     1324│           ...threadInfo,
     1325│           id: newThreadID,



Found 1 error
lib/shared/thread-utils.js
1735

I believe just D9947 should resolve the issue.

  1. I patched the latest diff in your stack
  2. Observed the flow issue in web/input-input-state-container

ff1630.png (466×2 px, 144 KB)

  1. Made the same change as D9947 and ensured that the flow issue disappeared.

eb1098.png (270×1 px, 45 KB)