如果通過另一個可行的方法檢查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，則流類型細化不起作用

回答

相關問題