How do I return the same type that is passed into a function? - flowtype

Question

I have a function which can receive a value of type either TLocation or {height: number, width: number}.
TLocation is defined as follows:
type TLocation = {
height: number,
width: number,
x: number,
y: number
}
Here is my function:
function transformer<
L: { height: number, width: number } | TLocation,
V: { height: number, width: number }
>(location: L, viewbox: V): L {
if (location.hasOwnProperty('height')) {
return {
height: location.height / viewbox.height,
width: location.width / viewbox.width,
x: location.x / viewbox.width,
y: location.y / viewbox.height
};
} else {
return {
height: location.height / viewbox.height,
width: location.width / viewbox.width
};
}
}
Here is a screenshot of where I have flow errors:
Both errors are:
Flow: Cannot return object literal because object literal [1] is incompatible with `L` [2].
I know I can't use hasOwnProperty as I am trying to do, but I'm not sure how to properly return the correct value (and therefore type).
If there is anything special I need to do when calling the function, I'd really appreciate an example of the usage as well.

Answer 1

The short answer is that no, you can't do this with flow, not in the way you're trying to.
Fundamentally, you have two different main things going on. You have a type refinement problem, and you have a problem with returning a generic type.
Type Refinement
Type refinement is an area where the official flow docs are really insufficient. It would be a lot more useful if they were just clear about what can't be accomplished with type refinement currently. It's really pretty simplistic.
You basically have two object types, A and B, but you know that A has a member B doesn't, so you should be able to refine the object to A or B based on whether or not that member exists. It makes sense to you, and it seems like it should make sense to flow. But flow doesn't implement a mechanism for that.
type A = {| +aMember: string |};
type B = {| +bMember: string |};
// `thing` is a union of `A` and `B` who have different properties
declare var thing: A | B;
// Only `A` has `aMember`, so we should be able to check for that
// to refine the type, right?
if (typeof thing.aMember === 'string') {
(thing: A); // ERROR! `thing` is still a union of `A` and `B`!
}
(try)
Unfortunately type refinement in flow is a bit too naive to figure this out. What this particular check does accomplish is that it refines the type of the property:
if (typeof thing.aMember === 'string') {
// we can now use `thing.aMember` as a string just fine, but
// `thing` is still a union of `A` and `B`
(thing.aMember: string);
}
(try)
The only way that we can refine whole objects into different types in flow is with a disjoint union. This would mean that we would introduce a literal field to distinguish between the two object types, which is probably not what you want to do in this case:
type A = {| type: 'a', +aMember: string |};
type B = {| type: 'b', +bMember: string |};
// `thing` is a union of `A` and `B` who have different properties
declare var thing: A | B;
if (thing.type === 'a') {
// flow now knows that `thing` is of type `A`
(thing.aMember: string);
} else {
// and here in the else, flow knows that `thing` is of type `B`
(thing.bMember: string);
}
(try)
Generic Return Type
So what happens if we decide to use a disjoint union to resolve this?
type Common = {| width: number, height: number |};
type Size = {| ...Common, type: 'size' |};
type Rect = {| ...Common, type: 'rect', x: number, y: number |};
const func = <T: Size | Rect>(thing: T): T => {
// Here we've bypassed the type refinement problem by using a
// disjoint union, but we're not returning `thing`, are we?
if (thing.type === 'size') {
// ERROR!
// Cannot return object literal because object literal [1]
// is incompatible with `T` [2].
return { type: 'size', width: 0, height: 0};
} else {
// ERROR!
// Cannot return object literal because object literal [1]
// is incompatible with `T` [2].
return {
type: 'rect',
width: 0,
height: 0,
x: 0,
y: 0,
}
}
}
(try)
The problem is that our function expects to return exactly T, but we're not returning T, we're returning some other type. You might think, "we're gonna return something of a type that T is compatible with at the time it gets returned," but that's not actually what we're telling flow. We're telling flow to expect us to return exactly T.
Let's look at an even simpler example:
const f = <T: number | string>(thing: T): T => {
if (typeof thing === 'number') {
return 0;
// ERROR!
// Cannot return `0` because number [1] is incompatible
// with `T` [2].
} else {
return 'stuff';
// ERROR!
// Cannot return `stuff` because string [1] is incompatible
// with `T` [2].
}
}
(try)
Why does this not work? Well, I think that the best mental model to use to consider this, is templates. Let's consider that the way that generic types work is by creating versions of the function for each member of the set that the generic type bounds define. This obviously isn't how this actually works, but it'll be useful when considering this example.
Our generic in this case defines a set of two types, string and number, so let's consider that this results in two versions of this function:
const fForNumber = (thing: number): number => {
if (typeof thing === 'number') {
return 0;
// Works fine.
} else {
return 'stuff';
// ERROR!
// Cannot return `stuff` because string [1] is incompatible
// with `number` [2].
}
}
const fForString = (thing: string): string => {
if (typeof thing === 'number') {
return 0;
// Cannot return `0` because number [1] is incompatible
// with string [2].
} else {
return 'stuff';
// Works fine.
}
}
(try)
So basically we've just copied and pasted the function, then replaced T with number in the case of the first function, and we've replaced it with string in the second case. It's pretty clear when looking at each of these versions independently why they would have errors. Now we just need to consider that the version with the generic is basically these two functions superimposed on top of each other, and the result is that we get both errors. To not get any errors in our generic functions, every type defined by the bounds of the generic must independently make sense in place of the generic through every path of the function.
Solutions
Given this formulation, the most immediate solution is to just ignore the errors basically:
type TLocation = {
height: number,
width: number,
x: number,
y: number
}
function transformer<
L: { height: number, width: number } | TLocation,
V: { height: number, width: number }
>(location: L, viewbox: V): L {
// Refine both of these properties so we can use them without errors:
if (typeof location.x === 'number' && typeof location.y === 'number') {
return (({
height: location.height / viewbox.height,
width: location.width / viewbox.width,
x: location.x / viewbox.width,
y: location.y / viewbox.height
// Type through `any` to `L`
}: any): L);
} else {
return (({
height: location.height / viewbox.height,
width: location.width / viewbox.width
// Type through `any` to `L`
}: any): L);
}
}
This is sort of okay because we (the authors, not flow) know what the type we should be returning is, so as long as we are returning that correctly it should work fine. But obviously this is sort of ugly since we're basically just turning off the type system. Unfortunately we're gonna have to make a compromise somewhere to make this particular formulation work.
Usually in this type of situation it makes the most sense to back up and implement a more explicit design:
type Size = {| width: number, height: number |};
type Rect = {| ...Size, x: number, y: number |};
function sizeTransformer(size: Size, viewbox: Size): Size {
return {
height: size.height / viewbox.height,
width: size.width / viewbox.width,
}
}
function rectTransformer(rect: Rect, viewbox: Size): Rect {
return {
...sizeTransformer({ width: rect.width, height: rect.height }, viewbox),
x: rect.x / viewbox.width,
y: rect.y / viewbox.height
}
}
(try)
Obviously you have to consider how this is currently being used, but usually there is a way to implement a more specific solution.
I think that one thing people tend to do when they start working with strongly typed code is to try and fit strong typing onto patterns they're used to from more dynamic environments. In my experience, this is often a code smell. It's often revealing that the code could be considered more from a data-first perspective. Generics are a big and powerful tool, but if you're asking yourself whether or not you can use them to solve a really small use case, then it might be a good time to step back and reconsider the approach.