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 😅
Programming languages enthusiast. Author of Learn Type Driven Development: https://www.packtpub.com/application-development/learn-type-driven-development
Oh I see what you mean now–and why the interface type works! Because an object with type:
interfaceCommon{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.
Programming languages enthusiast. Author of Learn Type Driven Development: https://www.packtpub.com/application-development/learn-type-driven-development
Oops, sorry I think my annotation on the previous flow try was confusing.
The previous link works as expected,
missingPropertyis expecting error because it is not mentioned, andcis OK because it is annotated as optional inHasExtra. However, once we change interface to type, while bothcandmissingPropertystill 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 😅
Oh I see what you mean now–and why the interface type works! Because an object with type:
... 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.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..
Wow, yeah that's a head-scratcher. No idea what's happening there!