前端AI 技能【免费下载链接】basic⭐⭐⭐⭐⭐ 面向 AI 编程的管理系统框架兼容PC、移动端。AI-oriented management system framework, compatible with PC and mobile device.项目地址https://gitcode.com/GitHub_Trending/ba/basic点击查看免费下载Store状态仓库是管理系统中承载全局共享数据的核心设施。本文围绕 fa-store-generator 技能 及其配套的 Store 模板与示例系统讲解在 Fantastic-admin 这类 monorepo 管理框架中如何规范地创建 Pinia Store包括创建前的交互式需求收集、命名规范、四种代码模板变体、持久化方案、自动导入机制以及组件外部使用 Store 的正确姿势。读完本文你将能独立为任意应用模块设计并落地一个可维护、可持久化、可被全局自动注入的业务 Store。一、为什么需要 Store技能触发的典型场景在 Fantastic-admin 中Store 解决的是数据需要在多个页面、多个组件之间共享并且刷新页面后仍然存在这类问题。官方技能文档明确列出了应当启用 Store 生成流程的触发条件多个页面需要共享数据需要全局状态管理数据需要持久化刷新后还在登录状态 / 用户信息需要缓存购物车、通知、权限等全局数据需要在组件外访问状态。用户可能只是简单说一句这个数据要全局共享或刷新后数据不能丢此时就应当按本技能生成对应 Store。对应的触发关键词包括创建 store、全局状态、状态管理、pinia、持久化、共享数据。从源码结构看框架本身正是围绕这些场景组织 Store 的登录与账号、主题设置、菜单、标签页、路由、页面保活各自都有独立的 Store 模块见 apps/core/src/store/modules/app/因此业务开发中新增 Store 是极其频繁的操作规范化生成流程能显著减少样板代码与踩坑。二、第一步确认目标应用monorepo 工作区本项目是 monorepo 架构apps/目录下存放各应用如core、core-naive-ui、example等每个应用拥有独立的src/store/modules/目录。因此在执行任何文件读写操作之前必须先确认目标应用执行ls apps/列出所有可用应用立即向用户提问明确询问要在哪个应用中创建 Store并停止等待回复收到用户明确回复后才能继续后续步骤。严格规则如果用户没有在请求中明确说明目标应用例如在 example 应用中、apps/core则必须提问不得自行猜测或默认选择任何应用。确认后后续所有文件路径均以该应用目录为根例如apps/app/src/store/modules/。项目 Store 概览维度约定位置apps/app/src/store/modules/业务 store代码风格全部使用Composition API风格defineStore setup 函数导入方式通过unplugin-auto-import自动导入组件中无需手动 import持久化pinia-plugin-persistedstatev4配置persist: { pick: [...] }其中自动导入机制已在 Vite 插件层落地详见下文第五节。三、交互式工作流先收集信息再生成代码Store 的字段结构、持久化需求、异步 action 直接决定代码骨架——跳过信息收集会生成空壳用户后续还要大量修改。因此官方技能要求按三步推进。Step 1收集基本信息向用户提问可合并为一次Store 用途管理什么数据例如用户信息、购物车、通知列表存放位置apps/app/src/store/modules/— 业务 store推荐apps/app/src/store/modules/app/— 框架级 store仅框架内部使用State 字段需要哪些状态字段请列出字段名、类型和初始值Step 2收集功能需求根据 Step 1 的回答继续询问持久化是否需要持久化到 localStorage如果是哪些字段需要持久化异步 Action是否有需要调用 API 的操作如果有请描述接口用途Computed是否需要派生状态computed例如从列表中过滤、统计数量等Step 3确认并生成汇总用户的回答展示将要生成的内容摘要确认后再写入文件。这一工作流与真实框架 Store 的复杂度完全对应——例如 useAppRouteStore 同时包含ref状态、computed派生路由、异步 actiongenerateRoutesAtBack请求后端路由并构建匹配器useAppAccountStore 则同时包含异步登录/登出、权限拉取与 localStorage 持久化。字段结构、异步链路、派生逻辑三者缺一不可。四、命名规范类型Store ID函数名文件名业务 storecamelCaseuseNameStorename.ts框架 storeappNameuseAppNameStorename.ts示例购物车 → ID:cart函数:useCartStore文件:apps/app/src/store/modules/cart.ts通知 → ID:notification函数:useNotificationStore文件:apps/app/src/store/modules/notification.ts该规范在框架现有代码中得到了完整贯彻useAppAccountStore、useAppSettingsStore、useAppMenuStore、useAppTabbarStore、useAppRouteStore、useAppKeepAliveStore均位于apps/core/src/store/modules/app/下文件名与 ID 一一对应见 apps/core/src/store/modules/app/。五、Store 模板与四种变体5.1 基础模板所有 Store 均采用defineStore setup 函数Composition API风格结构统一为 State / Computed / Actions 三段式最后统一return暴露import { defineStore } from pinia export const useNameStore defineStore(id, () { // State const field refType(initialValue) // Computed const computed computed(() ...) // Actions function action() { ... } return { field, computed, action, } })5.2 变体一纯状态 Store无持久化、无异步适合购物车这类会话内共享即可的数据。注意addItem中对已存在条目做数量累加、total用reduce实时计算总价的写法是典型的派生状态用法import { defineStore } from pinia export const useCartStore defineStore(cart, () { const items refCartItem[]([]) const visible ref(false) const total computed(() items.value.reduce((sum, item) sum item.price * item.quantity, 0), ) function addItem(item: CartItem) { const existing items.value.find(i i.id item.id) if (existing) { existing.quantity } else { items.value.push({ ...item, quantity: 1 }) } } function removeItem(id: string) { items.value items.value.filter(i i.id ! id) } function clear() { items.value [] } return { items, visible, total, addItem, removeItem, clear } })框架中 useAppKeepAliveStore 就是典型的纯状态 Store仅维护list: string[]提供add/remove/clean三个同步 action没有任何持久化与异步逻辑。5.3 变体二带持久化的 Store这是刷新后数据不能丢类需求的推荐写法利用pinia-plugin-persistedstatev4 的第二参数persist配置import { defineStore } from pinia export const useUserPreferenceStore defineStore( userPreference, () { const theme reflight | dark(light) const language ref(zh-cn) const pageSize ref(20) function setTheme(val: light | dark) { theme.value val } return { theme, language, pageSize, setTheme } }, { persist: { pick: [theme, language, pageSize], // 只持久化指定字段 }, }, )持久化默认使用 localStoragekey 为 store ID。 使用pick只持久化部分字段避免持久化临时状态。需要特别说明的是持久化插件的接入是全局性的。在 apps/core/src/store/index.ts 中pinia实例被创建后立即pinia.use(piniaPluginPersistedstate)注册插件再在 apps/core/src/main.ts 中通过app.use(pinia)挂载。这意味着任何 Store 只要声明了persist配置即可生效无需额外改动入口文件。值得对比的是框架现有的 useAppAccountStore它采用了手动 localStorage 读写的方式持久化token/account/avatar初始化时localStorage.getItem登录时setItem登出时removeItem。两种方案各有适用场景——模板中的persist.pick适合字段较多、部分需要落盘的场景手动 localStorage 则适合敏感凭证需要精确控制读写时机的场景。业务 Store 默认推荐使用persist.pick方案。5.4 变体三带异步 Action 的 Store对接后端接口的标准模式loading状态包裹请求过程、try/finally保证 loading 复位、computed 派生计数、action 内更新本地状态import { defineStore } from pinia export const useNotificationStore defineStore(notification, () { const list refNotification[]([]) const loading ref(false) const unreadCount computed(() list.value.filter(n !n.read).length) async function fetchList() { loading.value true try { const res await api.notification.list() list.value res.data } finally { loading.value false } } async function markRead(id: string) { await api.notification.markRead(id) const item list.value.find(n n.id id) if (item) { item.read true } } return { list, loading, unreadCount, fetchList, markRead } })这一模式在框架中随处可见。useAppAccountStore 的login、getPermissions、editPassword均为异步 action且login成功后同步写入 localStorage 与响应式状态useAppRouteStore 的generateRoutesAtBack则演示了请求后端路由 → 格式化formatBackRoutes按Layout/ 组件路径映射到import.meta.glob(/views/**/*.vue)→ 排序 → 构建createRouterMatcher的完整异步链路。5.5 变体四带 TypeScript 接口定义的 Store为复杂数据定义接口类型并演示已缓存则跳过请求的典型优化import { defineStore } from pinia interface DictionaryItem { label: string value: string | number } interface DictionaryState { [key: string]: DictionaryItem[] } export const useDictionaryStore defineStore(dictionary, () { const data refDictionaryState({}) function getItems(type: string): DictionaryItem[] { return data.value[type] ?? [] } async function fetchByType(type: string) { if (data.value[type]) return // 已缓存跳过 const res await api.dictionary.getByType(type) data.value[type] res.data } return { data, getItems, fetchByType } })框架级 Store 同样大量使用类型声明。例如 useAppMenuStore 引入MenuRecordMainRaw、MenuRecordRaw、RouteRecordMainRaw等类型约束菜单与路由结构useAppRouteStore 使用RouterMatcher类型保存路由匹配器。可见类型先行是框架 Store 的一致实践。六、自动导入机制无需手动 importStore 文件放入src/store/modules/后unplugin-auto-import会自动扫描并全局注入组件内直接const xxxStore useXxxStore()即可无需手动 import。该机制在 Vite 插件配置中显式声明// apps/core/vite/plugins.ts autoImport({ imports: [ vue, vue-router, pinia, FantasticAdminComponentsAutoImports, FantasticAdminComposablesAutoImports, ], dts: ./src/types/auto-imports.d.ts, dirs: [ ./src/store/modules/**/*, ./src/composables/**/*, ], })关键在dirs: [./src/store/modules/**/*]这一项——它以 glob 形式扫描所有 Store 模块文件并注入导出的useXxxStore函数。这也是Store ID 必须全局唯一camelCase这条注意事项的根源一旦同名自动导入与 Pinia 实例解析都会产生歧义。七、在组件外部使用 Store必须传入 pinia 实例在组件/composable 内可直接使用const xxxStore useXxxStore()但在组件外如路由守卫、路由配置、入口文件调用时由于此时还未建立组件上下文必须显式传入全局 pinia 实例useXxxStore(pinia)框架的 router/extensions.ts 中全部采用这一写法例如const appSettingsStore useAppSettingsStore(pinia) const appTabbarStore useAppTabbarStore(pinia)同样地router/routes.ts 在计算首页标题时使用useAppSettingsStore(pinia).settings.app.home.titlerouter/index.ts 在创建路由历史模式时读取useAppSettingsStore(pinia).settings.app.routeMode。这些例子说明在 Vue 应用正式挂载app.use(pinia)之前只要把pinia实例作为参数传入就能安全地在模块顶层读取 Store 状态。八、生成后的操作指引Store 文件创建完成后向用户交付以下信息无需手动 importunplugin-auto-import已自动处理在任意组件/composable 中直接使用const xxxStore useXxxStore()如需在 store 外部如路由守卫使用需传入 pinia 实例useXxxStore(pinia)。九、项目现有 Store 参考模板文档给出了 4 个框架级 Store 参考从当前仓库源码看apps/core应用的store/modules/app/下实际存在 6 个框架 Store完整清单见 apps/core/src/store/modules/app/Store文件用途useAppAccountStoremodules/app/account.ts登录/登出、token、多账号、权限useAppSettingsStoremodules/app/settings.ts主题、语言、布局配置、显示模式useAppMenuStoremodules/app/menu.ts菜单生成与导航状态useAppTabbarStoremodules/app/tabbar.ts标签栏管理useAppRouteStoremodules/app/route.ts动态路由生成与匹配器useAppKeepAliveStoremodules/app/keepAlive.ts页面保活列表管理这 6 个 Store 是理解复杂 Store 该如何设计的最佳教材useAppSettingsStore通过watch将状态变更实时同步到document.documentElement主题色、圆角、灰度滤镜等副作用useAppMenuStore由路由数据computed派生菜单树并按权限过滤useAppTabbarStore在add/remove时联动useAppKeepAliveStore维护保活列表——即下面要讲的跨 Store 调用。十、跨 Store 调用与注意事项模板文档明确跨 store 调用直接在 setup 函数内调用其他 store例如const authStore useAppAccountStore()框架中的典型示例是 useAppAccountStore它在 setup 顶部一次性获取多个依赖 Storeconst appSettingsStore useAppSettingsStore() const appTabbarStore useAppTabbarStore() const appRouteStore useAppRouteStore() const appMenuStore useAppMenuStore()随后在logoutCleanStatus中联动清理appSettingsStore.updateSettings({}, true)重置设置、appTabbarStore.clean()清空标签页、appRouteStore.removeRoutes()移除动态路由、appMenuStore.setActived(0)复位主菜单。这是登出时全局状态复位的最佳实践范本。最后是模板文档列出的完整注意事项清单Store 文件放在src/store/modules/后unplugin-auto-import会自动扫描并全局注入无需手动 importStore ID 必须全局唯一camelCase避免在 store 中直接引用 DOM 或组件实例但框架的useAppSettingsStore因主题系统需要会操作document与navigator属特例跨 store 调用直接在 setup 函数内调用其他 store如const authStore useAppAccountStore()。结语从交互式需求收集到命名规范、四种模板变体再到自动导入与组件外使用fa-store-generator 提供了一套端到端的 Store 生成方法论而 store-patterns.md 与框架现有 6 个 Store 实现相互印证构成了模板可抄、范例可读、原理可查的完整闭环。开发者在实际落地时只需遵循先确认应用 → 再收集需求 → 套用模板 → 按需持久化 → 组件外传 pinia这条链路即可稳定地产出高质量的状态管理模块。赞分享前端AI 技能【免费下载链接】basic⭐⭐⭐⭐⭐ 面向 AI 编程的管理系统框架兼容PC、移动端。AI-oriented management system framework, compatible with PC and mobile device.项目地址https://gitcode.com/GitHub_Trending/ba/basic点击查看免费下载相关推荐Redwood 框架中的 TypeScript 支持从零接入、自动类型生成到严格模式的完整指南Redwood 框架中的 TypeScript 支持从零接入、自动类型生成到严格模式的完整指南 Redwood 框架内置了完整的 TypeScript 支持后端前端Web框架开发工具Fantastic-admin CRUD 页面生成模板全解析从占位符到完整业务模块的代码生成实践Fantastic admin CRUD 页面生成模板全解析从占位符到完整业务模块的代码生成实践 本文以 Fantastic admin 框架GitHub_前端AI 技能Fantastic-admin CRUD 页面生成器从零生成标准业务模块的完整指南Fantastic admin CRUD 页面生成器从零生成标准业务模块的完整指南 导读 本文围绕 Fantastic admin 框架内置的 fa crud前端AI 技能上一篇Runtipi Docker集成深度剖析容器网络与数据卷管理下一篇Phaser CE入门指南打造你的首款HTML5 2D游戏的完整教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考