目前是不是就哪种 api 设计适合 react/redux 应用程序达成共识？

Posted 2023-02-19

技术标签:

【中文标题】目前是不是就哪种 api 设计适合 react/redux 应用程序达成共识？【英文标题】：Is there currently a consensus on which api design fits a react/redux app?目前是否就哪种 api 设计适合 react/redux 应用程序达成共识？ 【发布时间】：2017-02-06 01:01:51 【问题描述】：

我正在使用 react 和 redux 构建一个单页应用程序。当然，它的数据需要一个后端。现在我们正在研究哪种 api 架构最好，但我无法就哪种 api 架构最适合 react/redux 应用程序达成共识。

现在我知道您基本上可以以任何您喜欢的方式使用数据。但是仍然有明确的市场领导者，例如 redux over mobx。这并没有让他们变得更好，但至少知道偏好在哪里是件好事。

所以我的问题是：目前哪个 api 架构最常用于 react/redux 应用程序？

【问题讨论】：

【参考方案1】：

如今，新技术层出不穷。关于选择使用什么并没有真正的共识，就像过去一样。找不到最适合 react/redux 应用程序的架构。找到最适合您项目的架构。

【讨论】：

我期待这个答案，当然我正在尝试这样做。但是了解哪种架构得到最多使用是有价值的。这是一个很好的起点，通常它会得到最多的使用，因为它做对了一些事情。知道了，点击这个链接查看一些图表github.com/reactjs/redux/issues/653，view -> action -> dispatch -> reducer -> state change，这就是 redux 为我们的状态管理所做的事情。我还建议在此处查看 redux 的 Ducks 文件结构：medium.com/@scbarrus/… 感谢您的回复，但这不是我的意思。我的意思是哪种 json api 架构（或标准，例如 odata 或 jsonapi.org）最常与 react/redux 应用程序结合使用。【参考方案2】：

根据我们的经验，最好不要让 API“适合”react/redux，反之亦然。只需使用 thunk-action-creators 并以任何形式或形式处理 API 调用。

这是一个人为的例子：

export function getUserById (userId) 
    return async dispatch => 
        dispatch( type: 'REQUEST_USER_BY_ID', payload: userId )
        try 
            const user = await api.get(`/users/$userId`)
            ga('send', 'event', 'user', 'profile', 'view')

            dispatch(
                type: 'LOAD_USER',
                payload: user
            )

            dispatch(
                type: 'NOTIFY_SUCCESS',
                payload: `Loaded $user.firstname $user.lastname!`
            )
        
        catch (err) 
            dispatch(
                type: 'NOTIFY_ERROR',
                payload: `Failed to load user: $err.message`,
            )

这种方法的最大好处是灵活性。 API 对消费者完全没有意见。您可以在任何页面上以不同的方式处理错误、添加重试逻辑、回退逻辑。轻松将需要并行或顺序调用多个不同 API 的操作粘合在一起。

我们尝试了许多方法，例如“redux over the wire”和relays/apollos“将组件绑定到查询”。这个被认为是最灵活、最容易理解和重构的。

【讨论】：

【参考方案3】：

很难找到有关此主题的权威信息或指南，但很难说如果您专门为一个 Flux/redux 应用程序创建 API，并将数据以规范化的形式存储在数据库中，那么这样做是相当愚蠢的在您的 API 端点中对其进行反规范化，以便在您的客户端中直接对其进行规范化（使用 normalizr）...在这种情况下，只需将数据规范化并通过网络将其传递给您的客户端。

具体来说，你会有这样的东西：

GET /meetings


    "result": ["1", "2"],
    "entities": 
        "meetings": 
            "1":  "id": 1, "date": "2016-01-01", "attendees": [1, 2, 3] ,
            "2":  "id": 2, "date": "2016-01-02", "attendees": [2, 3, 4] 
        ,
        "users": 
            "1":  "id": 1, "name": "User 1" ,
            "2":  "id": 1, "name": "User 2" ,
            "3":  "id": 1, "name": "User 3" ,
            "4":  "id": 1, "name": "User 4"

鉴于这些实体中的每一个都对应于您的状态中的一个属性，因此此类响应在 reducer 操作中为 trivial to merge into your store，使用类似 Lodash merge 的内容：

return _.merge(, state, action.entities);

如果您有多个消费者，您可能会选择normalize=true 查询参数。您可能还想将其与某种 expand|include=entities,to,include 查询参数结合使用。

最后，请注意 JSON API 规范 doesn't play nicely 具有通量/redux 存储的规范化结构。