代码之家  ›  专栏  ›  技术社区  ›  Flame_Phoenix

民间故事的未来是什么?

  •  3
  • Flame_Phoenix  · 技术社区  · 6 年前

    背景

    我正在阅读每一寸文档,并试图尽可能多地了解民间故事。 最近,我决定试试 Future 是的。

    我们需要未来吗?

    现在我明白了 Task Promise 以及 任务 未来 (支持取消)我不清楚 未来 许诺 .

    我为什么要用 未来 而不是 承诺 是吗?我会有什么好处? 好吧,你可以说:“这样你就有了一个单子,而不是一个对不起的借口单子。”

    这是一个很好的论据,但…考虑到我总是需要从承诺转变为其他(未来),并且 未来 的API几乎是一样的,我不清楚,作为一个新人,我为什么要关心 未来 完全。

    代码示例

    假设我有这个函数,其中 request 是发出请求并返回某些结果的函数。

    extractRequestInfo 是从响应对象中提取数据的函数。 如果失败了,我 catch 错误并返回一个包含所有数据、badid和错误的对象。

    const requestFruit = request => data =>
        request( data )
            .then( extractRequestInfo )
            .catch( error => ( { badId: prop( [ "Id" ], data ), error } ) );
    

    既然这是一个http请求,我知道我不需要 任务 因为我不能在这里取消。所以我的选择是 承诺 未来 .

    问题

    1. 我该怎么用 未来 在这个样本里?
    2. 既然这是可能失败的东西,我应该用 Result 也?
    1 回复  |  直到 6 年前
        1
  •  1
  •   Flame_Phoenix    6 年前

    引用创建者quil的响应:

    未来解决了同样的问题,所以 两者在概念上的区别。不同之处在于 他们解决了这个问题。

    承诺要么成功,要么失败。在任何转变中 如果你应用承诺的值,同步抛出的错误将是 含蓄地抓住并拒绝承诺。这很有趣 在async/await中,因为您可以处理这些错误(synchronous和 异步)以类似的方式——您不需要 将同步操作转换为promise,因为运行时将执行此操作 为你。

    这样做的缺点是很容易发现 不是故意的,系统运行的状态不一致。我 你也不认为你能在这里做很多静态分析。

    未来不会有这个问题,因为没有什么东西会被提升到 含蓄的未来。如果希望同步操作使用 未来处理错误的管道,你必须把它们放在那里 明确地。这使您可以更好地控制错误处理,并且 未预料到的错误仍将按预期使进程崩溃(避免 当你的程序运行到不一致的内存状态时 没有预料到),但是这样写程序需要更多的努力。

    除此之外,如果你考虑任务,未来模型 具有成功案例、失败案例和 取消案件。承诺只有成功和失败 因此,取消被建模为一个特殊的故障值。这个 稍微改变一下处理取消的习惯用法。有可能 使用承诺处理失败的代码,而不知道这一点 特殊的取消值,这可能是一个问题,因为这个值 在这些转换过程中很容易丢失。

    在混合承诺和任务的代码库中,这些问题更多 很复杂,因为承诺所做的错误的隐含提升是 不太符合明确提出的错误 任务/未来预期(这可能会导致像这样的问题:163)。 找到这些虫子比你承诺的要困难得多 或者只有任务/未来。不知道什么是处理这些问题的最好方法 还有案子。

    对于最初的讨论:

    https://github.com/origamitower/folktale/issues/200

    推荐文章