携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第4天，点击查看活动详情
浅聊一下业务层hooks封装，对于什么是hooks及作用，这里不做过多介绍，但是需要讲清楚，对于为什么要封装Hooks，以及业务层封装的目的是什么?
本人的思考过程：
起因独白：
起初对云平台的定位，以及对于hooks的使用挺感兴趣，用起来也挺爽，有种莫名的偏见，因为良好的业务聚焦和代码解耦方面，算是一种优秀的代码实践（不排除我有react的相关经验）。
从平台角度考虑，其实是很想让在平台框架层起到一定的作用，从而为业务友好的服务。而且vue3的api改良，为hooks提供了更良好的发展土壤。
起因思考：
官方和社区现状：
前思后想，社区做了一些调研
- 对于vue的hooks就属于官方的vueuse，进行了深入研究，翻阅大量的掘金文章，不少很多，而且都是入门使用居多，根据行业资深前端进行交流，感觉官方提供的不是很好，主要是满足社区生态，数量非常多，实用性不高，使用时找起来非常麻烦，有点臃肿的味道，如果使用你会有深刻体会，恨不得自己写一套。
- 社区内造轮子的不是很多，有都是入门级别，主要都是参考react的ahooks实现，都是一片较好，和一些简单的功能逻辑复用和实现，深入不多，点评浅薄。说时候，部分的hooks还是比较实用。
业务现状：
其实真正业务中，会用到哪些，手指头都能数的过来，如果需要用
建议还是自建业务hooks库，但是要慎重挑选，别什么都塞进去。
业务作用：
画张图来描述下，hooks在设计中的位置
这一层hooks，放在了业务侧的common目录下，有点业务层和框架层的缓冲、防腐作用，其实业务侧公共层必要时也可以用，主要是聚合、复用逻辑或者提供工具的作用
- 一定要方便业务层使用，业务功能开发过程中，常用的东西非必要情况，不要直接调用框架层的API，但需要根据情况而定
比如我要做权限判断、读取缓存、页内路由跳转、打开新页面、发送请求、预览、下载等等
- 对于框架层封装的API，业务层使用如果有比较麻烦的部分
可以成为一个封装独立逻辑部分， 调用步骤较多、API名称较长
以上情况，可以利用hooks进行聚合封装，方便业务功能开发使用
业务hooks设计：
后记：
这是业务层的hooks设计，当然框架层也会有一层，职责不一样而已。
