基于React / Redux构建成熟的应用程序架构,承诺和依赖注入

时间:2017-06-19 23:03:51

标签: reactjs typescript promise async-await

我是React的新手,并试图了解如何使用它构建一个优秀的应用程序架构。 我还使用具有所有功能的typescript:interfaces,async-await,泛型等。所以,我对实现某些模式感到困惑:

1)依赖注入和可重用的组件实例

我能做的第一件事就是DI。我们假设我们得到了一个组件类UserProfile,它需要一些依赖项,例如UserProvider。如果组件实例(注入了deps)可以重复使用,那将是完美的,但我担心它只是我的梦想,而不是反应的家伙'。 :) 所以,我应该这样放置这个组件:

<UserProfile id={123} />

好的,在这里注入依赖关系的正确方法是什么?作为这样的属性<UserProfile id={123} dependency={userProvider: userProviderInstance} />? 你认为将组件输入数据,选项/参数和依赖关系放在一起是不是很奇怪?如果我能清楚地将它们分开并对组件类放置通用限制,我会很高兴。什么是最佳做法?

重用组件实例不可能的另一方面是我们必须通过所有组件结构携带一些不必要的对象,只是为了将它们注入深层底部。没有人告诉你哪些组件​​真正使用它们。并试着想象一下,在低级别组件中添加依赖项会占用大型项目​​。我不能。

2)使用承诺

让我们考虑一个应该呈现计数器的简单组件:<Counter value={123} />。 现在,通过调用方法getCounter(id: number): Promise<number>;从某些API获取值,因此将所有这些放在一起的显而易见的方法可能如下所示:

<Counter value={await provider.getCounter(id)} />

但我知道,我不可能。通常的做法告诉我们通过setState方法完成它并在收到值后重新呈现组件。

现在想象一下,父组件非常复杂,并且有许多不同的提供者。因此,父组件可能没有明确的状态类型。它也可能是有条件的,你知道......

你可以建议我在Counter组件中实现异步获取,但我会拒绝一个简单的原因:该组件对值的来源一无所知。在其他情况下,该值直接作为数字传递。那么,你是否有更好的想法如何在使用promises时保持代码清洁和简单?

如果您遇到一些好的文章或者有解决这些问题的经验,请告诉我。

PS:感谢您的关注! :)

1 个答案:

答案 0 :(得分:0)

这个主题是一个偏见的主题 - 所以下面我将对那些不假装绝对真理的主题提出我的 非常个人的 想法。

  1. DI 即可。
  2. 这确实不是那么常见的反应模式,因为它是有角度的。但是,在组件中同时具有上下文和属性允许您归档与纯DI相同的分离级别。检查context - 它将帮助您摆脱在整个组件树中传递相同的道具。已经有很多关于这个主题的文章(onetwo) - 检查出来。您也可能有兴趣阅读此thread)。

    1. 承诺
    2. 我真的没有看到任何问题。 React有一个简单的概念 - 基本上你有状态,并且基于这个状态你的应用程序可以自我呈现。虽然rendering不是异步操作,但状态的preparation / update可以很容易地异步完成,并且结果是assigned到状态的相应部分之后 - 必要的子组件将自动更新。如果你的组件不知道如何获得价值 - 它不应该首先尝试 - 值应该作为道具传递。