转换实体/标准化响应

Question

我想知道在将响应实体设置为Redux状态之前，在哪里转换响应实体的好地方。

示例

• 我有一个chat_message实体
• 它具有服务器发送的read布尔属性
• 我需要计算一个新的unread布尔属性= !message.read && message.user_id !== currentUser.id

问题

1. 我是否可以在getChatMessages选择器（reselect）中计算这个新属性？
2. 在将标准化响应设置为我的状态之前，我是否要计算此新属性？ –因此，我的问题是“转换”
3. 我只是在我的Component中计算它，但是这个逻辑（简单）并未在整个地方共享和重复...
4. 我是否从服务器发送unread属性...

注释

• unread属性示例是一个简化示例。
• 我不喜欢解决方案1，因为您仍然需要在选择器之间共享此逻辑。因此，您可能有isMessageUnread，getLastChatMessage选择器共享的getChatMessages辅助函数。我也不喜欢选择器做太多的逻辑。
• 我倾向于解决方案2。仅在收到响应时才计算新的unread属性。
• 解决方案3.是我目前的懒惰解决方案（这里到处都是实验，但实际上没有定论）
• 我不喜欢解决方案4，这些属性与UI的关系比与后端的关系更多。
• 如果使用解决方案2，我觉得reducers不是进行此转换的好地方。对于简单的实体来说可能很容易，但是“繁重”的转换（遍历集合，检查关系等）呢？我更喜欢将新逻辑放在选择器，简化器和实体之外。有点像normalizr的“插件” /拦截器/变压器/后处理器...

Answer 1

解决方案取决于如何使用属性：

• 是unread属性专用于单个组件的呈现目的，在其他任何地方都没有使用。例如：通知点。如果是，那么您可以使用解决方案3，因为您可以在组件内部定位使用情况。

• 如果需要在组件/中间件之间共享unread属性，则可以将逻辑放在选择器/缩减器中。但是，如果要放置在化简器中，请询问预订unread实体的所有组件是否都需要chatBox。如果不是这样，最好将其放置在选择器中，该选择器只能由需要它的那些组件/中间件调用。有一个额外的运行时计算权衡，但是它提供了适当的关注点分离，因为如果将来有更多这样的派生属性，最终将受益。

Answer 2

Normalizr提供了processStrategy option：

  

预处理实体时要使用的策略。使用此方法添加   额外的数据，默认值和/或之前完全更改实体   标准化完成。