Discussion on: Flow 0.99: Callable Properties, Function Statics, and More

[Yawar Amin]

It's an iterative process for me. While I'm working on a specific area I try to type everything on the 'mainline' of what I'm doing, and tell myself to come back and type out the 'side jobs' later. For example, I've recently been working with JSON validation for models, so I created a type that is essentially type Decoder<A> = Object => Promise<A>, and a constructor for this type function decoder<A>(jsonSchema: JsonSchema): Decoder<A>. For now I have type JsonSchema = Object, but I know that when I have some time I'll circle back and put in a definition that should only allow legal JSON Schemas.

Regarding the issue in Try Flow, I may be missing something, but it's not quite working like that. Even when interface Common, I'm seeing an error on this line: obj.missingProperty && console.log(obj.missingProperty); // error

The error is:

    17:   obj.missingProperty && console.log(obj.missingProperty);  // error
          ^ all branches are incompatible: Either property `missingProperty` is missing in `Common` [1]. Or property `missingProperty` is missing in object type [2].
        References:
        6: type HasExtra = Common & {
                           ^ [1]
        6: type HasExtra = Common & {
                                    ^ [2]

That looks about right, missingProperty is not mentioned in any of the type definitions so I would not expect it to work. When that is commented out though I am surprised that this works: takesExtra(obj) because we know obj: Common but takesExtra takes obj: HasExtra. Effectively Flow is having to downcast a supertype to a subtype to report no errors?!

Wow, the planned Flow inexact/exact type switch is going to be a big one. I've asked on that post, but I have a feeling that interfaces will not be affected, i.e. they will continue to be 'inexact'. My tendency is to use interfaces as much as possible; sometimes, there's just no point in giving a sub-object type a name so I directly use an object type {foo: bar}. I'm not sure I understand the post's argument that this being an inexact type makes it unsafe. I know there are some cases where you just don't want to allow passing in extra properties but IMHO it would be more annoying than unsafe. I have some examples in a post I wrote, dev.to/yawaramin/interfaces-for-sc...

[Wei Gao]

Oops, sorry I think my annotation on the previous flow try was confusing.

The previous link works as expected, missingProperty is expecting error because it is not mentioned, and c is OK because it is annotated as optional in HasExtra. However, once we change interface to type, while both c and missingProperty still work as expected, there is an error on line 12 that does not let us pass the common object.

I will definitely need to read your post on interface. Thanks for sharing! Nobody in our team has any experience with it and Flow's doc doesn't say much about it neither 😅

[Yawar Amin]

Oh I see what you mean now–and why the interface type works! Because an object with type:

interface Common {
  a: number,
  b: string,
}

... can always be safely downcast to its subtype type HasExtra = Common & {c?: string}. In fact now I'm surprised the type version doesn't work, ha ha. In any case, yeah I recommend to looking at interfaces more heavily. The doc page doesn't mention this but they can be used to model the shapes of not just classes but also 'POJOs', just like in TypeScript. This gives them quite a wide variety of use cases.

[Wei Gao]

So, it turns out that (from my understanding) interfaces allow structural subtyping which distincts themselves from types.

Although, I run into this error that I don't quite understand, but looks interesting..

[Yawar Amin]

Wow, yeah that's a head-scratcher. No idea what's happening there!