关于 React App 业务逻辑的组织

Ray-D-Song 嗯，我这里核心是有复杂交互的前端应用的状态处理策略，目前我们的业务用的挺重度。SWR、React Query 主要关注的是后端状态的同步，只是其中一部分。

复杂应用状态可以参考的例子是开源项目 lobe-chat 里面用 zustand 实现的 store
https://github.com/lobehub/lobe-chat/blob/7d037f6/src/store/chat/store.ts

在以展示为主，纯前端交互不重，大部分都在和后台数据打交道的场景，确实不需要单独去管理，做好后端状态同步就足够了。后端状态同步的模式都很固定，所以也可以抽象出一些类库，去干掉这块的冗余逻辑。

Ray-D-Song 还好吧，主要是我们没办法用一套思维模型完全覆盖所有场景，俗话说没有银弹嘛。

从类库设计的目标侧重出发来看，zustand 是走类 Flux 模式的路线，适合去理顺庞大复杂应用的状态。

signals 我没有深入用过，但看起来核心还是借助 getter 来收集依赖 + 订阅变化，实现更优雅细致的响应式封装，对于变化可以有更精确的响应，从而提升性能。但对于更复杂的应用并没有给到什么解决方案，估计还是得回到类 flux 模式的怀抱。

以我文中思路来说，有时候甚至都不需要状态库，写一个 class 定一些 state 和修改 state 的 action，以及用一些特定方式在修改时，触发组件同步数据，可以做的很简洁，业务直接使用这个 class 实例的引用，怎么传都可以。

核心还是根据业务需求来选择合适手段，手段本身可以很灵活。