On the Flowtype "Try" siteКак структурировать разделительную оболочку объединения для улучшения работы?
// @flow
type One = {type: "One"};
type Two = {type: "Two"};
type Node = One | Two;
class Foo<N: Node> {
node: N;
constructor(n: N) {
this.node = n;
}
}
const fooNode: Foo<Node> = new Foo({type: "One"});
if (fooNode.node.type === "One") {
const fooOne: Foo<One> = fooNode;
}
if
проверка типа не достаточно, чтобы уточнить тип, если я понимаю правильно, потому что тип не гарантируется постоянным.
Поскольку я хочу избежать возможности того, что это проблема X/Y, в настоящее время мы играем с данного узла с помощью метода .find
, который возвращает утонченный тип, например. используя
parent(): Foo<N> | null {
// ...
return null;
}
find<U: Node>(callback: (foo: Foo<N>) => Foo<U> | null): Foo<U> | null {
let p = this;
do {
const result = callback(p);
if (result) return result;
p = p.parent();
} while (p);
return null;
}
с
const f: Foo<Node> = new Foo({type: "One"});
const result: Foo<Two>|null = f.find((p) => p.node.type === "Two" ? p : null);
, который позволил бы мне вернуть изысканный вид на время поиска.
Интересно. Я устанавливал тип явно, потому что в нормальном случае я, вероятно, ожидал бы, что логика 'fooNode' будет в функции с этим значением, исходящим из аргумента функции. Это случай, когда я должен сделать аргумент функции 'fooNode: Foo <*>'? – loganfsmyth
возможно, или просто иметь общий тип N (с привязкой типа: узел) к функции тоже –
Оба примера не имеют смысла. В первом нет никакой утонченности, вы можете просто удалить 'if'. Второй просто ломает поток, а 'f' заканчивается« any' – vkurchatkin