1

我写这篇文章是为了知道我是否做对了。

在网上找到的例子中，模式通常是这样的（这里的例子是在状态和远程数据库上添加/删除操作）：

效果.ts：

@Effect()
add$ = this.action$
  .ofType(ADD)
  .switchMap((action: Action) => {
     return this.http.put(...)
       .map( response => response.json() )
       .map( response => Observable.of({ type: ADD_SUCCESS, payload: action.payload }))
       .catch( response => Observable.of({ type: ADD_FAIL, payload: response.status }))

减速器.ts

...
switch (action.type){
  case 'ADD_SUCCESS':
     ...
     return new_state;
  case 'ADD_FAIL':
     return state;
}

它可以工作，但用户感受到的执行速度取决于网络的速度。因此，我想出了一个模式，押注 API 不会返回错误的概率很高：

减速器.ts

...
switch (action.type){
  case 'ADD':
     ... // make the adequate addition
     return new_state;
  case 'ADD_FAIL':
     ... // delete the addition previously made
     return new_state;
}

效果.ts：

@Effect()
add$ = this.action$
  .ofType(ADD)
  .switchMap((action: Action) => {
     return this.http.put(...)
       .map( response => response.json() )
       .catch( response => Observable.of({ type: ADD_FAIL, payload: action.payload }))

在这种模式下，保存到数据库的动作确实是一个“副作用”。在 API 返回错误的不太可能但可能的情况下，将采取第二个操作来撤消第一个操作。

但是我还没有在网上给出的例子中找到这个设计：因为我是一个业余开发者，我想知道我是否错过了一些最终使它出错/危险/低效的东西。

4

1 回答 1

0

我不会说它有任何错误/危险/低效。一切都取决于您的程序要求。如果您正在处理非常慢的网络，那么需要考虑到这一点。

但是在那种情况下，如果出现问题，那么用户在操作完成之前不会知道它。在网络非常慢且同时具有SUCCESS和FAIL动作的情况下，用户对他们拥有的数据更有信心，因为SUCCESS必须触发动作。如果您绕过该操作，那么用户可能正在工作并且在操作发生SUCCESS之前不知道他们的数据不正确。FAIL结果可能很小，或者可能会中断用户工作流程。

现在，一般来说，提交put或post请求并获得响应所需的时间应该相当短。并且您的SUCCESSorFAIL操作不应该太大，以至于它们需要很长时间来计算。

以结账系统为例。用户去结账和posts服务器。在您知道帖子是否成功之前，您不想路由到确认页面。因此，在这种情况下，有必要采取 单独SUCCESS的行动。FAIL

我认为它提供了最好的用户体验，以确保他们看到的数据是准确的，并且不会在失败后回滚更改。如果用户posts或puts某事到服务器，则该SUCCESS操作应将其添加到应用程序状态，而不是在此之前和可能的用户通知。一个FAIL动作将根据应用程序处理用户通知、潜在的日志记录等。

另一个例子：假设用户正在编辑在线个人资料。如果他们单击“保存”，那么您希望在服务器上成功保存时通知用户。这样他们就不会离开页面，想“我希望它保存了，我没有得到回应”。

我想说在大多数情况下，同时拥有 aSUCCESS和FAILaction 是合适的。但就像我说的，一切都取决于您的应用程序以及您的用户在您的环境中可以接受的内容。

希望有帮助。

于 2017-03-31T13:13:53.940 回答