CODEWITHSUNDEEP
objecttypesreferenceflowtype
mike87
mike87

Reputation: 329

Type check with typeof === custom type with Flow error

Given the following code:

type CustomTypeA = {
  x: number,
  y: number,
}

type CustomTypeB = CustomTypeA & {
  z: number,
}

type CustomType = CustomTypeA | CustomTypeB

export const myFunction = (a: CustomType | number): number | void => {
  if (typeof a === 'number') {
    return a; // THIS WORKS WELL, it's considered number after the check, which is correct
  } else if (typeof a === CustomType) {
    
    const newX = a.x // ERR: Flow: Cannot get `a.x` because property `x` is missing in `Number`
    const newZ = a.z // SAME ERR, Flow: Cannot get `a.z` because property `z` is missing in `Number`.
  }
}

Also, the typeof a === CustomType check is highlighted as an error as well:

Flow: Cannot reference type `CustomType` from a value position.

This however doesn't happen for the typeof a === 'number' one.

It's like the check against the custom object type I created is not valid/recognized.

Can someone explain why and possibly how to escape this? Thanks.

Upvotes: 1

Views: 845

Answers (1)

Danielo515
Danielo515

Reputation: 7061

Flow custom types are not values, they do not exist, they vanish after transpilation, therefore you can not use them with a JS operator like typeof because it requires a value. So when you do typeof a === CustomType it will fail, because after compilation you will end with typeof a === , CustomType is just stripped out and you end with invalid JS.

This seems to be a flow limitation to be honest.

There is the %checks operator which allows you to build type guard functions. One may think you can use this feature to build a type refinement for your custom types with a function that has the proper logic, but nothing on its documentation suggest that it can be used to refine custom types. It also requires the body of the guard function to be very simple so flow can understand what do you mean. Some type guard function examples may look like this (from flow docs):

function truthy(a, b): boolean %checks {
  return !!a && !!b;
}

function isString(y): %checks {
  return typeof y === "string";
}

function isNumber(y): %checks {
  return typeof y === "number";
}

However when you try a more complex check, for example checking that something is an object, but it is not an array or a date, flow fails to understand your intention and the predicate function will not work. Something like this:

function isObject(obj: mixed): boolean %checks {
  return Object.prototype.toString.call(obj) === '[object Object]'
}

Will fail because flow doesn't understand that as a type refinement for object. For that particular case, there is a workaround suggested on a github issue that consist on declaring the function on the type level asserting that it checks for the object type:

declare function isObject(obj: mixed): boolean %checks(obj instanceof Object)

But you can not use that either for your particular case, because you can not do instanceof on a custom type, because it is not a class.

So your options are either go verbose and check all the expected properties are present on a type check, like this:

  if (typeof a.x === 'number' && typeof a.y === 'number' && typeof a.z === 'number') {
    const {x: ax, y: ay, z: az} = a
    // now you can safely use the extracted variables

Note you need to extract the props from the object because, any time you call a function flow will invalidate your type refinement and the next line that access a.x will fail.

You can declare your point as a Class, and use the type system checking for instances of that class.

Or you build a validation function that returns either the correct type or null, so flow can understand the type has been refined:

function isCustomType (p: mixed): CustomType | null {
  const validated = ((p:any):CustomType)
  if (typeof validated.x === 'number' && typeof validated.y === 'number') return validated
  return null
}

  const validA = isCustomType(a)
  if (validA) {
    const {x: ax, y: ay} = validA
    // do stuff

This has the disadvantage that you need to allocate extra variables just to satisfy the type system, but I think that is a minor problem. Also, it will not allow flow to validate the isCustomType function for you, because we are doing type casts to basically cheat flow. But given the surface is small and the objective is very focused it should be ok to be able to keep it manually correct.

Upvotes: 2

Related Questions