前言

昨日我们看了看项目的路由，store，以及它的登录注册页面的路由和路由守卫

1.今天我们尝试对整个项目结构进行解析，以及思考一个完整详尽项目要制作出来需要从哪一步开始，哪一步结束。

2.今天我们来看看项目的layout布局相关功能，这个功能呢，很重要，因为它是属于一个项目的基本构成组件，没有它，我们也就不能用完善的分类方式来进行我们项目的功能页面展现了，所以这是很重要的
Layout 布局组件是一个前端项目的骨架和门面，它负责构建整个应用的整体结构（如顶部导航、侧边栏、页脚）、处理导航逻辑以及为用户提供一致的交互体验。在 Vue 3 + TypeScript + Vite 的技术栈下，我们可以构建出类型安全、高性能且可维护的布局系统。

本文中所解读的项目代码地址

本文中我们称呼该项目为X
https://github.com/un-pany/v3-admin-vite

layout

layout创建思路

个人创建layout的思路

一个侧边栏组件
一个顶部栏组件
一个AppMain组件用于展示功能页面

目标项目X创建layout的思路

1.区分不同屏幕宽度下使用不同的布局模式mode（左侧布局，左上布局，顶部布局）

layout功能细化分解

个人的layout 功能思路

似乎侧边栏就只有一个收起，打开功能
以及记忆当前的用户的所处页面，在刷新页面后重新回到之前用户打开的页面
以及设计一个顶部标签页列表用于展示用户打开过的标签列表

项目X的功能思路

1.布局模式的选择
获取appStore(‘存储了侧边栏的状态，设备类型，监听了侧边栏打开还是关闭的状态’，有切换、关闭、侧边栏的方法，有切换设备类型的方法)
获取监听路由变化函数
创建判断当前设备是否为移动端方法
… 太多步骤了，
你应该从template开始读
左侧模式：

相关变量：
isLeft, isMobile
接下里我们看isLeft从哪里来的

使用计算属性computed监听了settingsStore.layoutMode === LayoutModeEnum.Left
settingsStore:
/* 类型断言 as */
const state = {} as SettingsStore // 创建一个空对象并且要求这个空对象未来的结构和SettingsStore一样,就是告诉typescript把这个空对象当作SettingsStore类型来处理
type SettingsStore = {
// 使用映射类型来遍历 LayoutsConfig 对象的键
[Key in keyof LayoutsConfig]: Ref<LayoutsConfig[Key]>
}

如上面图片所描述的那样：
const state = {} as SettingsStore
interface LayoutsConfig本质上就是我们的state的创建时的 类型要求了，那我就要问了，为什么要用这么复杂的操作来重新创建一个新的类型作为我们state的类型约束，而不是直接使用LayoutsConfig作为类型约束。
这里我注意到使用LayoutsConfig作为类型约束创建的对象应该是要求该对象的键值不具有vue响应式的特点（ref,reactive）的，
而我们的store的state又是要求要有响应式特点的，而这里我们使用‘复杂操作’所创建的state对象的键值是具有响应式要求（ref,reactive）的,
那我又要问了，为什么定义
interface LayoutsConfig{ showSettins:boolean}
为什么不直接写成
interface LayoutsConfig{ showSettings:Ref}
呢

为创建的state赋值

上面代码中的赋值操作暂且不详解，只需要知道给它赋值了就好，我们要重点看看这个watch()操作[它在此用于获取当前最新的 state 值。]
为什么要watch state的每个键值，state的每个键值本身赋值时不就要求了是响应式变量吗

get CacheData方法：获取当前最新的 state 值。
	创建空对象 settings 并且设置了它的类型要求为Layoutsconfig
	遍历 通过Object.entries()获取state的键值数组（{[key1,value1]},{key2,value2}）
	为settings[key as SettingsStoreKey] 赋值为key对应的value值 
		type SettingsStoreKey = keyof SettingsStore // 定义类型SettingsStoreKey为 由type SettingsStore的键名字符串组成的合集
	返回 settings 

然后使用 setLayoutsConfig将最新的settings值存储到本地

ok，实时更新localstorage中state的目的？

既然要实时更新localstorage的state，那我们只需要看谁在用这个localstorage的state就好了。

项目中只在下图中代码中用到了：
该代码是获取了默认的layoutsConfig对象和localstorage中的layoutsConfig对象，然后合并二者，localstorage中的layoutsConfig值会覆盖前者的值，这样我们就实现了一个用户侧边栏状态的持久化存储。也就解决了pinia状态存储在用户进行页面刷新后的侧边栏状态丢失/重置问题

总结

所以useSettingsStore主要是一个用于
1.持久化存储（通过监听->实时更新本地缓存）用户侧边栏状态
的store

所以接下来我们回去看isLeft的代码：

使用计算属性computed 获取到侧边栏状态的模式是否为枚举LayoutModeEnum的Left（ “left”），计算属性有个优势是能够在计算属性值未改变的情况下重复访问它，会直接返回值，只有当依赖变化时才会重新计算：
优点：

![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/c61fd43fd1b84cc5aa84c4b8e959d330.png)

这样isLeft的来源就搞清楚了，就是一个判断当前模式是否为左侧模式的计算属性
那接下来我们要去探究影响isLeft的因素有哪些吗
那肯定就是绑定在项目的侧边栏的按钮上的呀。这还需要探索吗
我们读代码的目的是为了理解项目的结构构建，以及一些前沿的写代码方式