这是一个创建于 265 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，写了两个简单的 vue demo ，实际业务代码比这个复杂很多
单向数据流版简单 demo
layouts.vue
AComponent.vue
BComponent.vue
状态管理流版简单 demo
layouts.vue
AComponent.vue
BComponent.vue
 |
1
ipwx 2025 年 4 月 21 日  1
明明是页面上的东西，为啥要用全局 store 。
改天需求发生变化，比如本来是一个页面只显示一套 id = ? 的东西，现在要改成用 tab 切换而不是新建一个页面，你看你这全局 store 会不会重构到心态爆炸。 |
 |
2
zhengfan2016 OP @ipwx store 的写法是应届生同事写的，他走了，现在我在改他的代码发现很难看懂，起因是 leader 发现打开网页很慢，有很多不必要的请求，要我去掉不必要的 api 请求
 |
|
3
ipwx 2025 年 4 月 21 日
@zhengfan2016 那你挺惨的。加油吧……
|
 |
4
shaozelin030405 2025 年 4 月 21 日
看是否先可以丢给 ai 帮你逐步优化吧
|
 |
5
rimworld 2025 年 4 月 21 日 via iPhone
两个都用啊，页面特有的就 props 传递，单向传递跨越两个以上就用 provide inject 。有些基础的、共同的，比如用户信息，网站设置就存到 store 里。如果数据需要跨越很多层级，或者最相邻的父不是同一个节点，那也肯定要单独写个 store 塞一下。
|
 |
6
runlongyao2 2025 年 4 月 21 日
之后的状态标识怎么简单怎么来，之前的就维持 store 的写法调用就行
|
 |
7
hahaFck 2025 年 4 月 21 日
tanstack query 这个东西我前段时间也看到了，好奇问下，前段什么场景需要这种缓存的查询库啊，每次直接请求到后端查询也可以吧，后端也可以做缓存之类的，然后就是怎么保证前段的数据不是过时的呢
|
|
8
zhengfan2016 OP @hahaFck 哥们你是后端吧。前端问这种问题面试得扣分的
 第一代的异步请求 API ，用的都是原生方法，纯纯的样板代码  第二代的异步请求 API ，把公用的封装到一个 hook 内，减少样板代码，还加了 loading 和 error 等状态  页面调用的使用只需要用一个 hook  使用 tanstack query 的相当于第二代的 Ultra 版本，你用的别人封装好的 useAPI 类似的 hook ，并且这个 hook 是被几万个项目测试验证过的，几乎没有 bug 你自己写着玩用第一代第二代的，没问题，如果多人前端协作，每个人都自己发明一套第一代或者第二代的异步请求 API 轮子，对团队来说某种程度上是一种灾难  |
 |
9
caiyuan 2025 年 4 月 21 日
props 、依赖注入、全局状态管理。根据三种场景，分别选择方案。
|
 |
10
lyxxxh2 2025 年 4 月 21 日
选择 props,原因: 简单。
之前接过一个外包: 所有接口获取的数据都放 store,很规范。 userModel orderModel ... 把 store 当作后端 model 。 可能是某个设计概念吧。 每次都要找对应的 store 文件,我嫌烦。 |
|
11
zhengfan2016 OP @lyxxxh2 你们这种还有多个 store ，我司的项目是单 store 架构，ts 全是 any
|
|
12
zhengfan2016 OP @rimworld 如果你是放 userInfo ，这种不怎么修改的，确实没问题，放经常需要 set 的数据，尤其复杂的页面逻辑，有时候数据变了你都找不到到底在哪个地方被触发修改了
 |
 |
13
wangtian2020 2025 年 4 月 21 日
从来没有 props 单向数据流这种东西，培训班发明出来误人子弟的。正确方式应该是 ref 引用子组件 调用子组件 expose 出来的方法，一次性传参，而不是 props computed watch 搞坨 shit 出来。
除非真的是全局并且基本不会改的东西可以全局引用使用 store ，否则每个组件各自重新请求数据 |
 |
15
iYume 2025 年 4 月 21 日
从 tanstack query 的角度来说，key 本质上就起到了全局共享的作用，用 pinia 封装相比于 hooks 封装来说，只是减少了一层 ref.value 的调用
|
|
16
zhengfan2016 OP @iYume 是的，但是问题是 tanstack query 是被上万个项目检验过的，你造的轮子没有被系统检验过，出了 bug 是同事给你收拾烂摊子
|
 |
17
chiaoyuja 2025 年 4 月 21 日
看这个 tanstack 就是 request 拦截器加强版么，什么时机调用 是自己用 onMounted ，watch 控制 还是他内部控制啊
|
|
18
rimworld 2025 年 4 月 21 日 1
|
|
19
rimworld 2025 年 4 月 21 日
@zhengfan2016 你不放 store 的话，组件自己维护，需要互传数据会很麻烦。追踪修改也一样麻烦。其实我现在感觉 vue 的 pinia 的 useStore 风格的状态管理算是傻抄 react 的生态？因为 vue 的 store 暴露出来的既可以直接修改响应式值，也可以通过函数进行修改，这样在追踪时候很麻烦。react 只能通过暴露出来的函数修改，就好很多。Vue 下感觉具体还是要加强项目规范，比如只允许 store 暴露出来的函数进行修改，方便查询函数使用位置，没有遗漏。
|
 |
20
WasteNya 2025 年 4 月 21 日 via Android
简单到一两层模块的页面用 Props
复杂到多层模块的肯定不能用 Props ，不然这种 Props 地狱代码非常难维护 Store 就是解决 Props 地狱的一个方法，但对于页面级的 Props 要么给它分模块，要么在页面模块下新建局部 Store |
 |
21
zhangk23 2025 年 4 月 21 日
看需求 需要什么用什么，但要我自己写就是 store
|
 |
22
twofox 2025 年 4 月 22 日
还好，不是 vben 那套狗屎 provide/inject + 莫名的 register hook 。
我公司现在的前端代码看的我想死。找一个功能嵌套了七八个 register hook ，any 满天飞。 vben ，狗屎！！ |
 |
23
TimPeake 2025 年 4 月 22 日
把所有的业务耦合到全局状态中这个骚操作要被打断腿....
|
 |
24
leaveeel 2025 年 4 月 22 日
除了类似父子、父子 1 子 2 的情况用 props ，其他就考虑用 store 或者 inject 了，一层层传来传去的相当麻烦。
还有页面 loading 之类的也用 store 。 |
 |
25
youyouzi 2025 年 4 月 22 日
看得我脑瓜子疼
|
 |
26
siteshen 2025 年 4 月 22 日
主职后端开发，会尽量避免全局变量（ store 在我眼中就是全局变量）。
|
|
27
runlongyao2 2025 年 4 月 29 日
这个问题本质是决定状态在哪个闭包内，而这取决于业务。简单讲，两种都存在。看业务需要
|
Select Language