小编psc*_*scl的帖子

通过首先掌握组件props,在组件级别封装UI状态this.state并有选择地通过组件树传递它,我一直在遵循广泛给出的学习React开发的建议.这是一次启发性的经历.我开始欣赏无状态视图设计模式的强大功能,我觉得我已经能够使用这些技术实现健壮且组织良好的结果.

继续,我现在正在尝试使用更复杂的状态管理redux.但是当我redux逐渐深入了解复杂性并集成到我的应用程序中时,我发现自己面临着关于我的代码如何发展的以下观察.其中一些发展似乎是明智的,但其他人让我怀疑我是否做得对'.

1)Action Creators是业务和UI逻辑的关联

我发现之前在React生命周期函数componentDidUpdate等中以及onTouch/onPress处理程序中实现的大部分逻辑现在都在动作创建器中实现.这似乎是一个积极的发展,因为它保持"一切都在同一个地方",并允许单元测试.

问题:将业务逻辑集中在相当复杂的动作创建者网络中是最佳做法吗？

2)挖空了 reducers

作为上面#1的推论,我发现我reducers和他们相应的action对象已经发展成一个事实上的setter列表,它只是用这种方式用传递的值来更新状态存储:

case types.SAVE_ORDER: 
  return Object.assign({}, state, {
    order: action.order,
  });

其中很大一部分原因是它reducers应该是纯函数,因此我对它的功能有限(例如没有异步处理).另外,减速器仅允许在它们各自的商店状态的子部分上操作.鉴于我的应用程序的大部分复杂性已经必然存在于动作创建者中,我发现很难证明任意将复杂性迁移到reducers仅仅是为了使它们"看起来有用".

问题:是否正常,并且可以接受的做法是使样板reducers仅仅作为减少存储状态的美化设置者？

3)redux-thunk无处不在

我已经单独询问了为什么redux-thunk甚至是必要的(而不是在异步回调/效用函数中调用标准动作创建者).我一直指出Dan Abramov的这个答案提供了一个非常令人满意的解释(相对于可扩展性,服务器端渲染和其他原因).

接受了必要性后redux-thunk,我发现我的大多数动作创建者需要执行异步操作,需要访问getState或dispatch对状态进行多次更改.结果我一直在' thunks' 回归' .

问题: redux应用程序广泛依赖于thunk"ed动作创建器"并且很少直接触发标准对象动作是否正常？

4)Redux全球化 this.state …

我有一个第 3 方 Lombok builder POJO，一个我无法修改的，我想使用 jackson 进行序列化。值得注意的是它并没有有NoArgsConstructor。

@Data
@Builder
public class ExternalClass {
   private String name;
   private String data; 
   // etc.
} 

从表面上看，这似乎很简单，但在实践中却令人难以置信地令人沮丧，因为每个可能的选项似乎都被不同的并发症所抵消。从本质上讲，我很难让外部Lombok构建器与 jackson mixin一起工作。

Lombok 生成流利的样式设置器，.name(String name)而 Jackson 的内置构建器解串器期望.withName(String name). Lombok 文档和其他地方的食谱（例如此处）建议@JsonDeserialize(builder=ExternalClass.ExternalClassBuilder.class)与@JsonPOJOBuilder(withPrefix="")预先声明的内部存根构建器结合使用。但这是不可能的，因为 Lombok 类位于外部库中。

将这些注释应用于 mixin 没有任何效果。

@JsonDeserialize(ExternalClass.ExternalClassBuilder.class)
public abstract class ExternalClassMixin {
   @JsonPOJOBuilder(withPrefix="")
   public static ExternalClassBuilder {
   }
} 

我发现唯一有效的方法是利用由@Builder以下构造函数创建的包访问 AllArgsConstructor并填充 mixin

public abstract class ExternalClassMixin {
   @JsonCreator …

我正处于理解 redux 状态管理的学习阶段，并且仍在尝试在令人眼花缭乱的样板代码和中间件丛林中进行谈判，其中大部分我认为是“良药”。所以我希望你能容忍我这个可能是基本的问题。

我知道这redux-thunk允许动作创建者异步进行并在随后的时间调度常规动作。例如，我可以在我的中定义一个 thunk 动作创建者actions.js：

export function startTracking() {
  return (dispatch => {
     someAsyncFunction().then(result => dispatch({
       type: types.SET_TRACKING,
       location: result
     }))
  })
}

并从 React 组件中调用它，如下所示：

onPress={() => this.props.dispatch(actions.startTracking())}

我的问题是，与简单地从异步回调内部调度操作相比，上面的代码有什么优势？

import { store } from '../setupRedux'
...

export function startTracking() {
 someAsyncFunction().then(result => {
   store.dispatch({
     type: types.SET_TRACKING,
     location: result
   })
 })
}

我会在我的组件中调用它

onPress={() => actions.startTracking()}

甚至

onPress={actions.startTracking}

store正如我在第二个示例中所做的那样，通过导入直接访问有什么问题吗？