5

最近，我一直在使用两个 redux 存储构建通用 Web 应用程序：一个在客户端，一个在服务器上。Redux 似乎是管理状态数据的好工具。可以将 Redux 用于 React 之外的东西吗？例如，你可以在命令行应用程序中使用 Redux 吗？

我觉得这种客户端存储和服务器存储方法打破了“单一事实来源规则”，但感觉非常好，到目前为止效果很好。我发现我可以重用大约 80% 的减速器来组成两个商店。服务器上的状态通常是一个集合，其中客户端上的状态可以是单个对象。

例如：假设您有一个聊天应用程序的客户端状态：

{
    user: 'mike@aol.com',
    room: {
       name: 'sports',
       users: [ ... ],
       messages: [ ... ]
    }
}

服务器状态类似，可以使用类似的 reducer，但它使用集合而不是对象。

{
    connectedUsers: ['mike@aol.com', ... ],
    rooms: [
      {
          name: 'sports',
          users: [ ... ],
          messages: [ ... ]
      },
      { ... },
      { ... }
    ]
}

创建两个状态树会重用许多相同的 reducer。这种方法还允许我向服务器发送操作并以来自客户端的操作进行响应。当有新连接时，使用服务器存储来生成状态客户端存储也不是很困难。

我的问题

我很喜欢这种通用应用程序的方法。这是否违反任何规则？你可以有一个客户端商店和一个服务器商店吗？使用服务器存储来生成初始值并不是很难。

还有其他人以这种方式使用通用应用程序吗？

4

2 回答 2

0

这可能是一个有点晚的反应，但无论如何。我做了一个实验，我正在实现一个多浏览器多人井字游戏。Redux 是后端的主要状态分发器。

该实验以一系列文章的形式结束，这些文章以非常详细的方式描述了在后端使用 Redux 的方式和原因，与您更喜欢在前端使用 Redux 还是经典的 React 状态无关。

  1. 服务器端 Redux。第一部分，Redux。
  2. 服务器端 Redux。第二部分。该设计。
  3. 服务器端 Redux。第三部分。编码。

如果您有任何问题，请随时给我留言。

于 2020-04-09T05:56:29.930 回答
0

我使用这种方法遇到的主要问题是服务器上的 redux 存储将保留在节点实例的内存中。当您进入生产环境并希望从单个服务器实例进行扩展时，这将是一个问题。

例如，如果您部署到 Heroku，当您增加 dyno 的数量时，您会增加节点进程的数量。每个节点进程都有自己的 redux 状态副本。因此，您的客户可能会在第一个请求时获得一个进程，而在下一个请求时获得一个具有不同数据的不同进程。

于 2017-01-25T20:29:09.573 回答