string is incompatible with string literal

[youngzhao-xyz]

I got flow error from this code snippet

type MyType = 'aa' | 'bb'
    
const str = 'a'
const test1: MyType = `a${str}`	// ERROR
const test2: MyType = 'a' + str	// ERROR

Error

    const test1: MyType = `a${str}`	// ERROR
                             ^ Cannot assign template string to `test1` because: Either string [1] is incompatible with string literal `aa` [2]. Or string [1] is incompatible with string literal `bb` [3].
    References:
    6: const test1: MyType = `a${str}`	// ERROR
                             ^ [1]
    3: type MyType = 'aa' | 'bb'
                     ^ [2]
    3: type MyType = 'aa' | 'bb'                        ^ [3]

Link: https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCyWAKrgQLxgDkAhrdWAD40BGr16AxnAHYDOGMIIBOYKnU48BQjHkEBGAFxFS5cWAAGtACQBvUQF9NASGDAwAUQBK1gPLXU0wWDmCATCuJl8GyWABqYQwRMwsbe2sgA

Does anyone know why flow doesn't support this? Or is there a better way to write this code? Thanks!

[wchargin]

Flow does not understand type-level concatenation of string-literal
types (or type-level addition of number-literal types, or most
type-level logical operations on boolean-literal types).

Literal types are meant to be treated as atomic units, not combined at
runtime. The better way to write this code is not to write it.

Is there a more complete example that you can share to indicate why
you want this functionality?

[youngzhao-xyz]

@wchargin Thanks. That makes sense.

Below is the reason I want this functionality:

// @flow

// =====================
// Icon component
// =====================

// ICONS contains all the svg icons in the app
// I use prefix like FRUIT_ to differentiate the categories
const ICONS = {
  FRUIT_APPLE: <svg>...</svg>,
  FRUIT_ORANGE: <svg>...</svg>,
  VEGE_BROCCOLI: <svg>...</svg>,
  VEGE_TOMATO: <svg>...</svg>,
  ...
}

const Icon = ({ type }) => (
  <i className={`Icon Icon--{type}`} />  
)

// =====================
// FruitCard component
// =====================
type Props = {
  fruitType: 'APPLE' | 'ORANGE',
  foo: string,
  ...
}

const FruitCard = (props: Props) => (
  <div>
     <div>{props.foo}</div>
     // below will trigger a Flow error 
     <Icon type={`FRUIT_${props.fruitType}`} />
  </div>
) 

I think what you said makes sense. Currently I use an object to map fruitType to icon type:

// =====================
// FruitCard component
// =====================
type Props = {
  fruitType: 'APPLE' | 'ORANGE',
  foo: string,
  ...
}

const FRUIT_TYPE_TO_ICON_TYPE = {
  APPLE: 'FRUIT_APPLE',
  ORANGE: 'FRUIT_ORANGE',
}

const FruitCard = (props: Props) => (
  <div>
     <div>{props.foo}</div>
     // Flow is happy with this 
     <Icon type={FRUIT_TYPE_TO_ICON_TYPE[props.fruitType]} />
  </div>
) 

Or maybe there is a better way to write this code?

[wchargin]

The approach that you propose makes sense. It’s a straightforward
solution that should work well, with the minor cost of having to use the
combined "FRUIT_APPLE" literals in some places.

You could also embed the hierarchy into the type system. If you do so
carefully, you can write a type signature for Icon such that these are
valid:

• <Icon category="FRUIT" type="APPLE" />;
• <Icon category="VEGE" type="BROCCOLI" />;

…but these are not:

• <Icon category="FRUIT" type="BROCCOLI" />;
• <Icon category="VEGE" type="APPLE" />;
• <Icon category="NOT_A_CATEGORY" type="WAT" />;
• <Icon category="FRUIT" type="NOT_A_FRUIT" />;

Here is one way to do so, making use of $ObjMap:

import React, {type Element} from "react";

// Type definitions. (There are other ways to structure these; this is
// relatively simple and works fine.)
type IconCategories = {
  FRUIT: FruitTypes,
  VEGE: VegeTypes,
};
type FruitTypes = {
  APPLE: "APPLE",
  ORANGE: "ORANGE",
};
type VegeTypes = {
  BROCCOLI: "BROCCOLI",
  TOMATO: "TOMATO",
};

// ICONS contains all the SVG icons in the app.
// Each category has its own nested object.
// This will fail to typecheck if you forget to include a category, or
// include an extra category, or forget to include a fruit/vegetable, or
// include an extra fruit/vegetable, or if any of the leaves is not an
// <svg /> element.
const ICONS: $Exact<$ObjMap<IconCategories, <T>(T) =>
  $Exact<$ObjMap<T, <U>(U) => Element<"svg">>>
>> = {
  FRUIT: {
    APPLE: <svg />,
    ORANGE: <svg />,
  },
  VEGE: {
    BROCCOLI: <svg />,
    TOMATO: <svg />,
  },
};

// Icon component
// Example usage: <Icon category="FRUIT" type="APPLE" />.
const Icon = <T: $Keys<IconCategories>>(props: {
  category: T,
  type: $Keys<$ElementType<IconCategories, T>>,
}) => (
  <i className={`Icon Icon--${props.category}_${props.type}`} />
);

// The following typecheck (which is good):
<Icon category="FRUIT" type="APPLE" />;
<Icon category="VEGE" type="BROCCOLI" />;

// The following do not typecheck (which is good):
/*
<Icon category="FRUIT" type="BROCCOLI" />;
<Icon category="VEGE" type="APPLE" />;
<Icon category="NOT_A_CATEGORY" type="WAT" />;
<Icon category="FRUIT" type="NOT_A_FRUIT" />;
*/

// FruitCard component
type Props = {
  fruitType: "APPLE" | "ORANGE",  // or: `fruitType: $Keys<FruitTypes>`
  foo: string,
};

const FruitCard = (props: Props) => (
  <div>
    <div>{props.foo}</div>
    {/* This typechecks, correctly */}
    <Icon category="FRUIT" type={props.fruitType} />
  </div>
);

Honestly, I’d use the simple solution myself. Easier to read, easier to
maintain, less likely to break or encounter other issues with Flow. But
I present the more structured solution for your consideration
nonetheless. (At the very least, it’s interesting to know that Flow can
do these kinds of things.)

(Edited to use a more precise type for ICONS.)

[youngzhao-xyz]

@wchargin Thanks so much for the thorough explanation and example!! This is very helpful

I like your ObjMap solution too. It is more structured and doesn't require an additional object to map fruitType to icon type.