Zustand 的文件组织?

[NerdHND]

最近在写一个三维相关的项目, 按照经验我用的是 Zustand 而非之前我更习惯的 Jotai 了.

这以后我的代码里就多了很多 useXXX.ts 的文件, 按照我原来用 Jotai 习惯的思路我是将 Zustand 的这些 store 尽量和相关的组件贴着, 然后在相关的组件里暴露, 比如一个 KitAside 的组件里要选用不同的 Kit, 那么就 import KitAside, {useKit} from "..." 这样去引入.

但是随着我的业务变得复杂, 我发现我很难再组织一个 store 是和哪个组件相关的, 因为 Zustand 的状态里往往掺杂着逻辑, 而且没法像 Jotai 那样很容易的拆分成子状态. 所以我现在的文件就出现了很多很多的相对引用去引用一个不相干的组件文件里的 store.

我目前的改动是发现有这样的引用就把暴露改到那个 useXXX.ts 文件去, 这样虽然解决了引用的地方来源莫名其妙, 但是已经没能解决大量的相对引用.

各位是如何处理 Zustand 的 store 文件的呢? src 下有个专门的 stores 文件夹还是说和我一样放在相关的组件旁边?

[foolishcrab]

文件夹组织也是样板代码的一部分
zustand 的优点是无样板，放哪按你项目其他部分的分割逻辑来就行了

[foolishcrab]

你现在这个问题的根本原因是不是一些应该存在上层的公共状态，错误下沉到了组件里？

你说的两种方式组合起来也是可以的

[importmeta]

https://zustand.docs.pmnd.rs/guides/practice-with-no-store-actions

[flmn]

为啥不继续用 Jotai 呢？

[mouyase]

理论上如果业务逻辑改变了，那 Stroe 大概就需要提升到上层了吧。

如果你在一个子组件里做了一些不属于他责任范围的事情，那本身这个设计就有点问题。

[ysmood]

我也是头疼 zustand 的文件组织和冗长代码，于是最近自己写了个库 stalo 。我写了个 todo app 用来演示如何将一个 store 分割成逻辑隔离的多个文件： https://github.com/ysmood/stalo/tree/main/examples/TodoApp

从目前我自己的使用来看，各项指标都由于 zustand ，我甚至用 stalo 写了个 devtools 来 debug stalo 自己： https://stalo-examples.vercel.app/examples/Devtools.tsx

[NerdHND]

@flmn 主要是和 Hook/Component 外作用域逻辑打交道的时候 Zustand 好解决一些.