Vue3 编写的最佳实践是怎样的?

@dfkjgklfdjg #19 ，其实 composition api 的优势并不是在于上面逻辑关注点导致的**整洁度**上面。而是在把逻辑关注点相关的代码被归为了一块完整的业务逻辑代码，可以很容易地将这一组代码抽象到外部 JS 文件中，来实现逻辑复用和拆分。以及函数组织代码所提供的更好的类型推导。

我的感觉是即使不考虑复用，只要内容稍多且能拆分就要尽量拆组件，控制单组件大小，组件稍稍一大，代码想不乱都难，只要组件小，不管怎么写始终都是比较可控的，无论是 vue2 vue3 还是 react 或者纯 js 都是，唯一的问题是目录结构就比较多了

@shintendo 是的，最后最矛盾的就在这里，模板还是在外面了。所以也只是相对灵活。这种灵活程度还是不如 react.

@yesterdaysun #20 ，面条代码之间可以用空行或者注释行来区分。但是如果是很复杂了的情况， 可以继续拆组件（比如说我在 #10 中提到的容器、展示组件的思想），或者单纯只是把业务逻辑提取出来，然后通过函数返回值的形式来调用就可以了，并不一定要改成 useXXX 这样的形式。
就是简单的函数返回：
```js
async fcuntion fnA (X) {
const valueB = fnB(XX)
const fetchData = await fetchXXX()
}

function fnB(XXX) {
....
return XXX
}
```

按照指责单一、关注点分离的思想去拆就可以了。至于是要在一个文件里面，还是拆分成多个文件就是看你自己的喜好。


-----



一些需要改造成 useXXX 的，常用的其实基本上都可以在 [VueUse]( https://vueuse.org/) 这个库里面找到。
一些业务逻辑相关的，比如说 CURD 的管理页面就会抽象一个 useTable() 的 hooks 来使用。但是返回出来的变量也不一定都要使用，具体用到哪些就解构出来哪些就好了。如果按照你说的需要同时解出来 8 、9 个变量了。是不是应该考虑一下逻辑再拆分。

不确定是否是最优解的场景，我的想法是找比较大的开源项目是怎么设计的，比如说我提到的 useTable ，社区的解决方案中就是再组装之后返回的，把相关的一些属性用一个属性包起来

```js
export const useTable = (config: UseTableConfig) => {
....
return {
tableRegister: register,
tableMethods: methods,
tableState: {
currentPage,
pageSize,
total,
dataList,
loading
}
}
}
```
[vue-element-plus-admin/src/hooks/web/useTable.ts at v2.10.0 · kailong321200875/vue-element-plus-admin]( https://github.com/kailong321200875/vue-element-plus-admin/blob/v2.10.0/src/hooks/web/useTable.ts#L184)

优点是比较出来的，vue3 优点在于更灵活，具体怎么做取决于开发者，vue2 时代 options API 很多地方是强耦合的，响应系统严重依赖于组件实例，this here this there ，vue3 我都几乎没见过 this 了

迷茫时可以看看 VueUse ，Composable 的标杆

#20
> 或者说你们真的很喜欢那种 useXXX, 然后导出 8/9 个参数的写法?
先不说有没有必要都放在同一个 composable 里，觉得返回值用解构式声明太多你可以不写解构声明，就用 reactive 包起来，例如`const mouse = reactive(useMouse())`，也是官方推荐的写法

你这种问题是 composition api 的书写模式的问题吧，跟 vue 版本倒是关系不大，毕竟 vue3 也可以使用类组件书写

看了上面几位大佬的讲解稍微有点感觉了, 不过回到最开始的主题, 有没有那种可以学习的开源库? 最好是那种业务逻辑面条代码一堆的, 学习一下别人是怎么处理这种代码耦合分离的问题的, 上面列出的几个库主要是组件库之类的

@yesterdaysun #27 ，我贴的是 Admin 框架，并不是 UI 库。里面有一些基础的通用页面，比如说用户管理、角色管理、菜单管理这种的，对于管理后台来说已经足够参考了。
如果要复杂的具体业务逻辑那么多半不会开源出来，如果是非管理后台的需求，可以直接在 Github 中用关键词 + Vue 的组合去检索，按照 star 数量来排序慢慢找就好了。

vue3 写到最后肯定是 tsx 呀.

你仍然可以沿用部分 Options API 的思维来写 Composition API

具体来说，你可以：

把 props 都写在一起（ Options API 中的 data ）
把 ref 都写一起（ Options API 中的 data ）
把 computed 都写在一起（ Options API 中的 computed ）
把生命周期都写在一起（ Options API 中的生命周期）
把 watch 都写在一起（ Options API 中的 watch ）
把函数都写在一起（ Options API 中的 methods ）
以此类推...

这样子在代码组织上，部分保留了 Options API 的思想，但是当你需要对一些逻辑进行封装时，又可以享受到 Composition API 的优越性（业务逻辑易抽象封装是 Vue3 相比 2 最大的提升，不需要再去写恶心的 mixin ）

可以参考我的项目： https://github.com/pipipi-pikachu/PPTist

一个文件的代码行数尽量不要超过 150 行

@Cbdy #31 真逗

现在写 vue3 的姿势是用 Nuxt3 框架，可以自动导入 Vue 函数/组件/路由等，专注写页面代码就行

我也有这种感觉，所以，现在写 vue3 我还是用 options 的写法。不过页面太大时，options 写法也不好。

@ylsAGI tov template

@TimG 佬想找的是否是这个,这种注释方式在 vsc 和 webstorm 目前应该都是支持的

```js

//#region
if (useArraySome([])){

} else{

}
//#endregion
```

@Cbdy 非常赞同

@sakitamFDD 确实是这种，没想到竟然真的有，太感谢了，明天就试试看。

@GuXianWn 那 Nuxt 还能服务端渲染

可以试试看我的这个插件

https://github.com/zcf0508/vue-hook-optimizer