前端 props 单向数据流 vs 状态管理流 你更能接受哪种代码

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

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

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

@zhengfan2016 那你挺惨的。加油吧……

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

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

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

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

@hahaFck 哥们你是后端吧。前端问这种问题面试得扣分的

第一代的异步请求 API ，用的都是原生方法，纯纯的样板代码


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

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


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

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

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

选择 props,原因: 简单。

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

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

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

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

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

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

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

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

@wangtian2020 https://cn.vuejs.org/guide/components/props.html#one-way-data-flow

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

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

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