如题，写了两个简单的 vue demo ，实际业务代码比这个复杂很多
单向数据流版简单 demo
layouts.vue

AComponent.vue

BComponent.vue

状态管理流版简单 demo
layouts.vue

AComponent.vue

BComponent.vue

明明是页面上的东西，为啥要用全局 store 。

改天需求发生变化，比如本来是一个页面只显示一套 id = ? 的东西，现在要改成用 tab 切换而不是新建一个页面，你看你这全局 store 会不会重构到心态爆炸。

store 的写法是应届生同事写的，他走了，现在我在改他的代码发现很难看懂，起因是 leader 发现打开网页很慢，有很多不必要的请求，要我去掉不必要的 api 请求

那你挺惨的。加油吧……

看是否先可以丢给 ai 帮你逐步优化吧

两个都用啊，页面特有的就 props 传递，单向传递跨越两个以上就用 provide inject 。有些基础的、共同的，比如用户信息，网站设置就存到 store 里。如果数据需要跨越很多层级，或者最相邻的父不是同一个节点，那也肯定要单独写个 store 塞一下。

之后的状态标识怎么简单怎么来，之前的就维持 store 的写法调用就行

tanstack query 这个东西我前段时间也看到了，好奇问下，前段什么场景需要这种缓存的查询库啊，每次直接请求到后端查询也可以吧，后端也可以做缓存之类的，然后就是怎么保证前段的数据不是过时的呢

哥们你是后端吧。前端问这种问题面试得扣分的
第一代的异步请求 API ，用的都是原生方法，纯纯的样板代码

第二代的异步请求 API ，把公用的封装到一个 hook 内，减少样板代码，还加了 loading 和 error 等状态

页面调用的使用只需要用一个 hook

使用 tanstack query 的相当于第二代的 Ultra 版本，你用的别人封装好的 useAPI 类似的 hook ，并且这个 hook 是被几万个项目测试验证过的，几乎没有 bug

你自己写着玩用第一代第二代的，没问题，如果多人前端协作，每个人都自己发明一套第一代或者第二代的异步请求 API 轮子，对团队来说某种程度上是一种灾难

props 、依赖注入、全局状态管理。根据三种场景，分别选择方案。

选择 props,原因: 简单。

之前接过一个外包:
所有接口获取的数据都放 store,很规范。
userModel orderModel ...
把 store 当作后端 model 。
可能是某个设计概念吧。
每次都要找对应的 store 文件,我嫌烦。

你们这种还有多个 store ，我司的项目是单 store 架构，ts 全是 any

如果你是放 userInfo ，这种不怎么修改的，确实没问题，放经常需要 set 的数据，尤其复杂的页面逻辑，有时候数据变了你都找不到到底在哪个地方被触发修改了

从来没有 props 单向数据流这种东西，培训班发明出来误人子弟的。正确方式应该是 ref 引用子组件 调用子组件 expose 出来的方法，一次性传参，而不是 props computed watch 搞坨 shit 出来。
除非真的是全局并且基本不会改的东西可以全局引用使用 store ，否则每个组件各自重新请求数据

tanstack query 是好文明，useQuery 和 useMutation 太好用了

从 tanstack query 的角度来说，key 本质上就起到了全局共享的作用，用 pinia 封装相比于 hooks 封装来说，只是减少了一层 ref.value 的调用

是的，但是问题是 tanstack query 是被上万个项目检验过的，你造的轮子没有被系统检验过，出了 bug 是同事给你收拾烂摊子

看这个 tanstack 就是 request 拦截器加强版么，什么时机调用 是自己用 onMounted ，watch 控制 还是他内部控制啊

cn.vuejs.org/guide/components/props.html＃one-way-data-flow

你不放 store 的话，组件自己维护，需要互传数据会很麻烦。追踪修改也一样麻烦。其实我现在感觉 vue 的 pinia 的 useStore 风格的状态管理算是傻抄 react 的生态？因为 vue 的 store 暴露出来的既可以直接修改响应式值，也可以通过函数进行修改，这样在追踪时候很麻烦。react 只能通过暴露出来的函数修改，就好很多。Vue 下感觉具体还是要加强项目规范，比如只允许 store 暴露出来的函数进行修改，方便查询函数使用位置，没有遗漏。

简单到一两层模块的页面用 Props
复杂到多层模块的肯定不能用 Props ，不然这种 Props 地狱代码非常难维护

Store 就是解决 Props 地狱的一个方法，但对于页面级的 Props 要么给它分模块，要么在页面模块下新建局部 Store

看需求 需要什么用什么，但要我自己写就是 store