2 个回答

现在你想在你的 Redux 应用中使用路由功能,可以搭配使用 React Router 来实现。 Redux 和 React Router 将分别成为你数据和 URL 的事实来源(the source of truth)。 在大多数情况下, 最好 将他们分开,除非你需要时光旅行和回放 action 来触发 URL 改变。

redux 文档: http://cn.redux.js.org/docs/a...

官方文档还对什么数据放 store 里提供了一些建议

这里有一些将怎样的数据放入 Redux 的经验法则:
应用的其他部分是否关心这个数据?
是否需要根据需要在原始数据的基础上创建衍生数据?
相同的数据是否被用作驱动多个组件?
能否将状态恢复到特定时间点(在时光旅行调试的时候)?
是否要缓存数据(比如:数据存在的情况下直接去使用它而不是重复去请求他)?

http://cn.redux.js.org/docs/f...

首先,你要先搞清楚store是什么?

然后搞清楚你要传递的数据的类型,和用途。

没有什么是绝对的

A 界面的数据 —> 跳转到B界面 -> 跳转到C界面

如果A界面的数据只在A或者B界面使用,C、D、F等等都用不到,也就是数据无复用性,那也就不需要去存入store。

如果A、B、C、等某几个界面要使用,那么传递成本很高,每次上个界面都要发送,下个界面都要接受,并且链路还不能断。

flux架构图:
clipboard.png

(以下是拷贝的)[]
这是来源

优点

  1. 用户体验,对于切换频率高的页面,用户体验直线上升。设想一下,如果数据放到页面组件内部,离开当
  2. 前页数据即被销毁,当用户一秒后再次返回该页。。。
  3. 资源优化,减少对服务器的请求,对于更新周期长的数据,例如用户个人信息,完全可以仅请求一次
  4. 可预测性,flux所提倡的数据可预测成为可能,各种数据追踪工具得以大展身手(微信小程序开发工具的数据追踪就挺不错)
  5. 可读性,component只有view逻辑,不掺杂modal逻辑,业务逻辑清晰易维护
  6. 扩展性强,例如需要加入权限控制,进行数据过滤,在store层面就可以轻松解决。而如果业务数据在组件内部。。。
  7. 统一性,所有业务数据统一存取,管理方便。

缺点

再来看看持观点1的人所反对的:

  1. store庞大,持观点1的人首先反对的就是这个。但是,对于SPA来说,对于现代PC来说,你的SPA的store能达到以G为单位不?
  2. 编写繁琐,嗯,这算一个理由吧。不过,对于其所带来的优点来说,这点牺牲并不算什么吧?
  3. 数据时效,有人提到,一次性数据(比如订单结算)不应被放入store。没错,这点我们可以在页面destory时手动清理不是么?
  4. 单store文件难维护,有人提到,所有业务数据操作都在store里,难维护。其实利用现在的构建工具,5. 我们已经可以做到把各个页面组件的store单独切出来,构建时再合并,这并不会影响可维护性。
    数据污染,有人担心,这么多数据放到store里,会不会造成污染。对于这点,无论Redux和vuex,都是支持子store的。也就是命名空间的概念。比如 store.pageModule1、store.pageModule2。再配合一些测试工具(如mocha)做重名检测,这方面完全不是问题这是flux框架,为了
推荐问题
宣传栏