1
duduaba 2022-01-10 19:50:31 +08:00 1
没什么关系,你可以理解这个 store 其实就是一个全局变量,然后监听这个全局变量,当全局变量里面有数据变化时绑定了全局变量的组件就会重新渲染,就是这个原理。
|
2
popbones 2022-01-10 20:13:20 +08:00 via iPhone
MVVM 了解下
|
3
cxh116 2022-01-10 20:22:35 +08:00 via Android
比如简单的场景,嵌套组件传属性。从 list 传到 item 。
|
4
janus77 2022-01-10 20:23:31 +08:00
小型项目连架构都不需要关心啊。。。。架构这个词就是为大型项目准备的
|
5
rioshikelong121 2022-01-10 22:02:39 +08:00 2
没什么关系。
Store 对前端应用来说是一个 Single Truth Source ( https://en.wikipedia.org/wiki/Single_source_of_truth)。 里面可以放一些 api 返回的数据。通过 store 可以代替顶层组件进行应用级别状态的共享。如果你无脑把后端 api 返回放在 store 里面的话,你可以把它认为是一个后端 api 的 cache (实际场景下,store 里面的数据也可以进行一系列的变形和转换过程。),如果是简单 cache 的场景,其实更推荐使用 swr / rtk-query 这样的的 data fetching & caching tools. 而 redux 是一个 state management tools ,这是两个范畴。 如果 redux 的 time travel, redo-undo ,易于调试,易于进行状态追踪等特性你用不上,说明你可能不需要 redux 。 |
6
sillydaddy OP @rioshikelong121
考虑 redux 主要还是因为用它容易实现 MVC 的模式。之前考虑的都是纯前端,现在跟后端 api/数据库打交道,对于 redux 的 store 和后端 api/数据库是什么关系,有点疑惑,比如前后端数据怎么同步等等。 |
7
sillydaddy OP |
8
wwk 2022-01-12 11:53:15 +08:00
和数据库没什么直接关系。
用 redux 这种形式一般为了管理复杂前端应用(前端自身需要长期维护数据状态,不是通过接口来进行直接刷新数据)的数据流,收束状态变更来源。 |