Question

在以下示例中（或在flow.org/try上）当我们通过另一个变量检查null / undefined时，类型细化似乎不起作用。

This site can’t be reached

localhost refused to connect.
      Did you mean http://localhost-8080.com/?
      Search Google for localhost 8080
ERR_CONNECTION_REFUSED

但如果我们在没有type Position = {| x: number, y: number |} function anotherCondition(): bool{ return true; } function getIt(): ?Position{ return {x:7, y: 8} } function setIt(p:Position){ } const pos = getIt(); const isOk = pos && anotherCondition(); isOk && setIt(pos)变量的情况下进行内联，那么它可以正常工作。但我有几个地方可以检查这种情况并使用像isOk之类的变量来减少冗长。有没有办法使它工作？或者我在这里遗漏了什么？

Answer 1

问题是，您的getIt函数会返回可选 Position，这意味着flow不知道pos是否{}是否有价值。

在您给出的示例中，getIt应返回固定的Position之类的内容（请参阅flow.org/try）：

function getIt(): Position {
  return {
    x:7,
    y: 8,
  }
}

由于您完全确定pos属于Position类型（因为isOk只能是true，如果是这样的话），您可以显式地将它强制转换为Position（我知道这是一种肮脏的方式）（见flow.org/try）：

isOk && setIt(((pos: any): Position));

Answer 2

您应该定义一个反映两种情况的联合类型，而不是依赖于显然经常失效的优化：

// @flow

type Position = {|
  x: number,
  y: number
|} | null

function anotherCondition(): bool{
  return true;
}

function getIt(): Position {
  const r = Math.random();
  return r <= 0.5 ? {x:7, y: 8} : null;
}

function setIt(p:Position){
  if (p) {}
  else {}
}

const pos = getIt();
setIt(pos);

但是，现在，您必须考虑除了这种联合类型之外的函数中的不同情况。这应该更干。

我认为你应该尽可能避免使用类型，而是使用更准确的联合类型。

如果通过另一个vairable检查null / undefined，则流类型细化不起作用

2 个答案: