Flow: Unannotated function components are broken since v0.89.0

[TrySound]

Flow version:
0.92-0.95

The problem started to appear when React.memo was rewritten from function component to AbstractComponent. This problems already gave me many pain in ass.

I guess this is related https://github.com/facebook/flow/issues/7341

Expected behavior

Correct errors as before

Actual behavior

AbstractComponent based HOCs produce empty props

• Link to Try-Flow or Github repo:

https://flow.org/try/#0JYWwDg9gTgLgBAKjgQwM5wEoFNkGN4BmUEIcA5FDvmQNwBQduEAdqvALJYgTABeWAEzgBeTFRgA6EFwgAeAN4AfOGGRRkIAIwAuOMwCuIAEZYoAGhVqNAJl1sowZgHM4igL4A+ABRhiYdMIecPJ0cHCUMPpQzCp+qBKOAG7IADbAAgAKViCo9G4AlPRAA

@jbrown215 I believe this is quite critical bug and should be at the top of priority list.

[jbrown215]

This is not related to #7341 nor is it a problem with AbstractComponent either. This is a bug that has to do with polymorphism and how Flow infers polymorphic types from calls.

It is high on our priority list, and is one of the big things we are working on.

[jbrown215]

I actually misdiagnosed this problem. The issue here is that props is not sufficiently constrained, but it has nothing to do with polymorphism or AbstractComponent. You'll notice the argument here is also inferred to be empty. That is because is never receives lower bounds from a call.

I'll investigate more in April.

[TrySound]

My team will not be happy. Flow catches less and less bugs with latest releases.

[jbrown215]

Sorry to hear that.

You can work around it by annotating the parameter of your function component.

[TrySound]

Thanks, will try that

[jbrown215]

Notes for myself for when I do tackle this:
The issue _is_ related to AbstractComponent.

When we explicitly annotate an HOC that is parameterized by the config of a component and we supply an unannotated function component, there is no Flow that sets the props type on the component even though it is set for the config. Take a look at memo:

declare function memo<P: {}>(
  Component: React.ComponentType<P>
): React.ComponentType<P>

an explicitly annotated call would look like this:

const Memoized = memo<{| foo: number |}>(props => props.what);

This produces the following constraint:

props => props.what <: React.ComponentType<{| foo: number |}>

props has no lower bounds, so I expect that the config computation here never even fires. We should ask for an annotation

[jbrown215]

@samwgoldman independently found another issue that blamed back to this same bug and also proposed a fix. I'm going to take a look this week :) thanks for reporting!

[jbrown215]

I have a fix ready and waiting for review!

This also lead us to discover #7582, which I'll handle in April

[TrySound]

Hey @jbrown215 any news on this?

[jbrown215]

Still waiting on review, but I have a fix. It might be related to the
other React issue you reported also, but I need to work more on that one.

On Sun, Apr 7, 2019 at 1:28 PM Bogdan Chadkin [e-mail]
wrote:

Hey @jbrown215 https://github.com/jbrown215 any news on this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/flow/issues/7561#issuecomment-480612301, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIJ9zxOyRcCIhPlIEU93z0gfSciQGwYeks5veiq1gaJpZM4b2RKA
.

>

Sent from Gmail Mobile

[TrySound]

@jbrown215 How's it going?

[jbrown215]

Still in review

[jbrown215]

aaaand accepted! will land ASAP

[TrySound]

Hooray!

[TrySound]

Fixed in 0.99