Refactor：单一职责优化——用户鉴权模块与用户数据模块分离

[jerry765]

内容

拆分user.ts用户鉴权与数据的用户鉴权模块为单独的auth.ts文件，分离鉴权和数据

影响范围

• 用户登录
• 用户数据获取

附加信息

issue #145

[jerry765]

原计划拆分的useFetchSelect.ts因拆分后调用过于麻烦，暂未提交

[pany-ang]

哈喽，仓库首页加我微信，我拉你进一下维护群

[yeyunwen]

内容

拆分user.ts用户鉴权与数据的用户鉴权模块为单独的auth.ts文件，分离鉴权和数据

影响范围

• 用户登录
• 用户数据获取

附加信息

issue #145

首先，单一职责优化，这点非常好。但是我有如下疑问：
拆分出的auth.ts中并没有涉及到auth自身store的state，而只是拆了login的逻辑，auth这个store
中没有state，而是修改了user这个sotre中的state，是否又会造成数据修改情况的不清晰。毕竟store最初的目的是存放数据和修改数据的逻辑的。

[jerry765]

内容

拆分user.ts用户鉴权与数据的用户鉴权模块为单独的auth.ts文件，分离鉴权和数据

影响范围

• 用户登录
• 用户数据获取

附加信息

issue #145

首先，单一职责优化，这点非常好。但是我有如下疑问： 拆分出的auth.ts中并没有涉及到auth自身store的state，而只是拆了login的逻辑，auth这个store 中没有state，而是修改了user这个sotre中的state，是否又会造成数据修改情况的不清晰。毕竟store最初的目的是存放数据和修改数据的逻辑的。

感谢你对单一原则应用的认可。我将认证auth逻辑拆分为单独的模块，而是操作原有user模块的状态，出于以下考虑：

1. auth模块处理认证逻辑，但认证state需要全局引用，因此auth state留在user模块中会更方便跨模块贡献
2. auth认证模块专注于所有用户认证相关操作，而user模块存储用户信息相关的状态和逻辑，可以在调试和维护时更容易理解数据流

考虑到数据修改逻辑可能不够清晰，或许可以通过增加状态映射（Pinia）或通过事件驱动更新（回调）以方便理解数据流？

在我使用本模板的项目中需要较为复杂的权限认证，导致user.ts文件过于冗长，所以我认为拆分出auth.ts有助于控制模块单一职责。