如果通过另一个可行的方法检查null/undefined，则流类型细化不起作用

在下面的示例中（或在flow.org/try上），当我们通过另一个变量检查null/undefined时，类型细化似乎不起作用。如果通过另一个可行的方法检查null/undefined，则流类型细化不起作用

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，它工作正常。但我有几个地方来检查这种情况，并使用像isOk这样的变量使其不那么冗长。有什么办法可以使它工作吗？或者我在这里错过了什么？

来源

2017-10-05 Tharaka Wijebandara

的问题是，你的getIt函数返回一个可选Position，这意味着flow不知道是否pos有值与否。

在您的例子给出，getIt应该返回一个固定Position等（参见flow.org/try）：

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

既然你知道100％肯定pos是Position型的（因为isOk只能true如果是这样的情况下），你可以明确其类型强制转换为Position（这是一个肮脏的方式，我知道）等（参见flow.org/try）：

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

来源

2017-10-05 13:34:14 MichaelDeBoey

我希望它是可选的。这只是一个例子。在实际情况中，有些情况下'getIt'也可能返回null。 –

我已经添加了一个替代方案，您可以对我的回答进行操作 – MichaelDeBoey

问题在于流程的细化算法往往难以预测，如OP示例中所示。 – ftor

而不是依靠改进，这显然是经常无效的，你更应该定义反映了这两种情况下的联合类型：

// @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);

但是现在，你必须在职责范围内考虑到不同的案件除了这种联合类型。这应该仍然更干。

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

来源

2017-10-06 15:43:03 ftor

如果通过另一个可行的方法检查null/undefined，则流类型细化不起作用

回答

相关问题