TypeScriptの型推論の穴についてのメモ

TypeScript をぼちぼちやってきた中で、型推論が素直に決まらないみたいな所が出てきたので書き置きとして残しておきます
具体的には何かしらの関数を通して処理を隠蔽すると上手くいかなくなるケースがあります

型が推論されないケース

検査関数的なものを通した場合に、後続処理で期待通り型が推論されなくなるケースです

その 1

type HogePiyo = 'hoge' | 'piyo';
type InputProps<ValueT> = { value: ValueT; error: string;
};
const required = (val: string) => { return val === '';
};
const registerHogePiyo = (value: HogePiyo) => { console.log('register', value);
};
const input: InputProps<HogePiyo | ''> = { value: '', error: '',
};
if (required(input.value)) { input.error = 'ERR'; console.error(input.error);
} else { // ここでは input.value は 'hoge' | 'piyo' となるはずだが // TSC は 'hoge' | 'piyo' | '' と解釈する registerHogePiyo(input.value);
}

その 2

type HogePiyo = 'hoge' | 'piyo';
type InputProps<ValueT> = { value: ValueT; error: string; hasError: boolean;
};
const required = <ValueT>(obj: InputProps<ValueT | ''>) => { if (obj.value === '') { return { value: '', error: '必須入力です', hasError: true }; } else { return { value: obj.value, error: '', hasError: false }; }
};
const registerHogePiyo = (value: HogePiyo) => { console.log('register', value);
};
const input: InputProps<HogePiyo | ''> = { value: '', error: '', hasError: false,
};
const result = required(input);
if (result.hasError) { console.error(result.error);
} else { // ここでは input.value は 'hoge' | 'piyo' となるはずだが // TSC は 'hoge' | 'piyo' | '' と解釈する registerHogePiyo(result.value);
}
export {};

型を推論されるようにしたケース

オブジェクトに型判定用のプロパティを生やし as で型を明示することでクリアしています

type HogePiyo = 'hoge' | 'piyo';
type InputProps<ValueT> = { value: ValueT; error: string; hasError: boolean;
};
const required = <ValueT>(obj: InputProps<ValueT | ''>) => { if (obj.value === '') { return { value: '', error: '必須入力です', hasError: true } as { value: ''; error: string; hasError: true; }; } else { return { value: obj.value, error: '', hasError: false } as { value: ValueT; error: string; hasError: false; }; }
};
const registerHogePiyo = (value: HogePiyo) => { console.log('register', value);
};
const input: InputProps<HogePiyo | ''> = { value: '', error: '', hasError: false,
};
const result = required(input);
if (result.hasError) { console.error(input.error);
} else { registerHogePiyo(result.value);
}
export {};

あとがき

  • Assertion Functions を使う方法もあると思いますが、何も考えず Assertion Functions を書くと次のような弊害があり、積極的に採用しづらいと考えています
    • 何もしていなければ基本的にバンドル後のソースコードに出てくる
      • 要するにバンドルサイズが大きくなります
    • throw を書く必要性があり、バンドル後に残っている以上、この throwcatch する必要性がある
      • 無意味な実装工数が生まれる
    • そもそも論として Assertion Functions を書く工数が生まれる
    • Assertion Functions の振る舞いを見ている限り、as に限りなく近く、ぶっちゃけ as で書いたほうが楽
  • 絶対に as を使わず現実的な工数で開発するというのは、割と非現実ではないかという感触があります
    • 個人的に型推論は IDE が勝手にやってくれるおかげで楽ができるシステムだと考えているので、型推論の補佐をする仕組みに工数をかけるというのは本末転倒な気がしています
  • 品質は大切なことですが、反面で少なくないビジネスには期限もあります
    • 品質に寄せすぎた過剰に冗長なコードも、納期に寄せすぎた脆弱性不具合山盛りスパゲティコードもどちらも考えものであり、その辺のバランスが上手くとれるやり方がなんかないかなーと考えることはしばしばあります
      • いわゆる要はバランス。要バラみたいなやつ