Javascript 在屏幕和等待结果之间传递承诺、减少等待时间的最佳方式是什么

我的目的是减少用户在过渡到需要API数据的屏幕时的等待时间

目前是这样的，

fetchSomeData

返回一个承诺：

// Screen 1
this.navigateToScreenTwo()

// Screen 2
async componentDidMount(){
  try {
    const data = await fetchSomeData()
    this.setState({ data })
  } catch(e){}
}

我想做的是启动promise，在导航状态下将其传递到下一个屏幕，然后在下一个屏幕中等待其结果。因为屏幕转换需要300毫秒，所以这足够从API获得结果，使转换和数据加载无缝

这样做是一种好的做法吗？如果没有，最好的方法是什么？

// Screen 1
const dataPromise = fetchSomeData() // purposely without await
this.navigateToScreenTwo({ dataPromise }) // pass promise in navigation

// Screen 2
async componentDidMount(){
  try {
    const data = await this.navigation.dataPromise // the promise from navigation state
    this.setState({ data })
  } catch(e){}
}

---

较不重要的是：在第一屏中是否应该有一个try/catch，在第一屏中承诺是首先返回的？

只要您已经验证了

navigateToScreenTwo

的任何实现都没有问题，并且只要它在一个足够简单的应用程序中，这可能是可行的

// Screen 1
const dataPromise = fetchSomeData() // purposely without await
this.navigateToScreenTwo({ dataPromise }) // pass promise in navigation

// Screen 2
async componentDidMount(){
  try {
    const data = await this.navigation.dataPromise // the promise from navigation state
    this.setState({ data })
  } catch(e){}
}

但这不是一个很容易维护的策略，也不遵循正常的反应模式。与此相反，我将使用一个跨组件工作的状态管理系统，例如React Context、Mobx、Redux或许多其他选项中的任何一个。异步作业将通过更新应用程序状态结束，并且根本不需要传递

---

屏幕1中的try/catch只能捕获同步错误，不能保证拒绝。在大多数情况下不太必要，但这取决于

fetchSomeData

是否会同步抛出错误（在返回承诺之前）。

屏幕是不同的页面吗？也就是说，当您从“屏幕1”移动到“屏幕2”时，是否会破坏并重新创建全局环境？“在屏幕1中首次返回承诺时是否应该尝试/捕获”每个问题问一个问题，而不是两个问题。解决第二个问题：承诺的基本规则之一是：要么处理错误，要么将承诺传递给其他东西（处理错误，或者将承诺传递给…。@T.J.Crowder是的，我主要是在移动环境中发言，但这同样适用于web。例如，在web中，这将是一个react-router转换。有没有一个原因可以解释为什么您不能在组件树中处理父级中的异步调用？@kriaoe例如在react-router中，我在路由器内的交换机组件内的屏幕之间转换，目前，该级别上没有任何状态可以作为应用程序的最高上下文。在一个有100多个页面的应用程序中，必须有一个非常通用的解决方案，如redux等。“屏幕1中的try/catch只会捕获同步错误，而不会承诺拒绝。”如果它在

异步

函数中，则不是这样。我们在“Screen 1”代码中没有任何调用上下文……我们知道它是在没有

await

关键字的情况下被有意调用的，因此如果它被包装在try/catch中，则只会处理同步错误。在这种情况下，如果屏幕1上的函数被标记为async并不重要，重要的是它没有使用

await

关键字。那一行有一条评论说“故意不等待”，我没有读任何东西：）哈！就是这样，我在看第一个代码块。我仍然要澄清这部分答案。不会花很多时间。