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.

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.

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

I will put a TODO for the time being.

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:

Open to any other solutions.

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

Same as above, was able to refactor:

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

D9917

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,
>

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

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

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

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

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

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

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

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