我应该使用一种还是多种操作类型来表示此异步操作? [英] Should I use one or several action types to represent this async action?

问题描述

我正在为搜索系统构建一个前端，其中几乎所有用户操作都需要触发相同的异步操作来重新获取搜索结果.例如，如果用户输入一个关键字，那么我们需要获取/api/search?q=foo，如果他们稍后选择了一个类别，我们获取/api/search?q=foo&categoryId=bar.我最初为 FETCH_RESULTS、SELECT_CATEGORY、DESELECT_CATEGORY 等设置了单独的动作类型.我为 FETCH_RESULTS 创建了一个异步动作创建器>，但其他是同步的.我想得越多，他们最终都需要从后端重新获取结果，并根据后端的响应更新应用状态.

I'm building a front-end for a search system where almost all user actions need to trigger the same async action to re-fetch search results. For example, if a user enters a keyword, then we need to fetch /api/search?q=foo, and if they later select a category we fetch /api/search?q=foo&categoryId=bar. I originally had separate action types for FETCH_RESULTS, SELECT_CATEGORY, DESELECT_CATEGORY, etc. I created one asynchronous action creator for FETCH_RESULTS, but the others are synchronous. The more I think about it, they all end up needing to re-fetching the results from the backend and update the app state based on the response from the backend.

使用单个异步动作创建器进行任何更改对我来说有意义吗?还是为每个不同的用户操作(选择关键字、类别或过滤器)使用异步操作创建器会更好?

Would it make sense for me to use the single async action-creator for any change? Or would it be better to use async action creators for each distinct user action (selecting a keyword, category, or filter)?

我认为细粒度操作的优点是事件更准确地反映了用户所做的事情(例如用户选择了一个类别)，而不是必须查看有效负载才能找出实际更改的内容，但它们都非常相似.

I think the advantage of granular actions would be the events more accurately reflect what the user did (e.g. the user selected a category) vs having to peer into the payload to figure out what actually changed, but they are all pretty similar.

推荐答案

这当然只有您才能根据您对项目的了解来真正回答.我不认为让动作更细化有任何固有的优势，如果没有，也不值得付出额外的努力.我会有一个通用的 FILTER_CHANGED 事件，而不用担心能够看到具体发生了什么变化——大概这个动作不会很复杂，所以我不会调试这个动作很多.随着过滤器状态变得越来越复杂和多样化，分解动作可能更有意义.不过，默认情况下，我真的没有看到太多价值.

This is of course something only you can really answer based on what you know about the project. I don't think that there is any inherent advantage to having the actions be more granular, and if there aren't any, its not worth the extra effort. I would have a generic FILTER_CHANGED event and not worry about being able to see what specifically changed--presumably the action isn't going to be complicated, so I'm not going to be debugging the action a lot. As the filter state becomes more complicated and diverse, it might make more sense to break out the actions. By default though, I don't really see much value.

这篇关于我应该使用一种还是多种操作类型来表示此异步操作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！