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

vue3 相比 vue2 有什么优势的地方呢。
我一个后端 ，想直接学 vue2 不知现在是否是正确的选择。 就是看了 vue2 文档感觉相对简单好入门一点

写习惯了就好，哈哈。 可以去看下 ElementPlus 组件库源码。

@lepig Vue3 + Options API

你写 vue3 用的组合式 API 写法吧？
对于大型复杂项目来说，我觉得组合式 API 写法比较考验编写的个人能力，编写出可读性高的代码，不然很容易就乱了...
但由于团队的人员不同，而且水平不一，我推荐大型多人协作的项目用选项式 API 写法，相对来说可读性高点，便于团队协作维护。
如果是简单的小项目，组合式 API 写法确实快一些，而且方便。

彻底拥抱 Composition API

配一下 https://github.com/antfu/eslint-config 试试看

我也想彻底拥抱 Composition API, 奈何实力不够啊, 一开始用 Cursor AI 帮我提取复用, 结果也是整出来一坨看着就毫无美感的代码, 想想还是得找大佬的例子学习学习

Vue 的正确姿势是 tsx

composition api 唯一的好处就是灵活吧。试下以这样的目标写代码：我这一块功能的代码都放在这里，如果不要这个功能直接把正块代码删除就行。不会影响其他功能。

是的，会有点乱。特别是在大组件的情况下。

其实原本的 options api 也会有这样的问题，只不过在外层用 data ，computed ，methods 之类的包了下可以折叠起来，所以在折叠的情况下，看起来会更 "整洁" 一些。

-----

日常实际开发中逻辑复用的需求下会出现使用 mixins 和 extends 来混合代码的情况。
composition api 的出现就是想要避免原本的隐式缺陷。👉 [#为什么要有组合式 API ？ - 组合式 API 常见问答 | Vue.js]( https://cn.vuejs.org/guide/extras/composition-api-faq.html#why-composition-api)

👇 所谓的整洁度其实也就是下面这样图这样，把相关联的业务逻辑放到一起来维护


那么其实就是靠人的自觉来把相关的逻辑放到一起，如果没有开发规范或者一些约定，胡乱 Coding 就会出现混乱的感觉。
👉 [#约定和最佳实践 - 组合式函数 | Vue.js]( https://cn.vuejs.org/guide/reusability/composables#conventions-and-best-practices)

但其实可以把一些复杂逻辑的业务整理抽象成单独组合式函数，放到单独的 js, ts 文件中，在在业务组件中 import 进来使用。
比如说：
```js
<script setup>
import { useFeatureA } from './featureA.js'
import { useFeatureB } from './featureB.js'
import { useFeatureC } from './featureC.js'

const { foo, bar } = useFeatureA()
const { baz } = useFeatureB(foo)
const { qux } = useFeatureC(baz)
</script>
```

我一般会推荐组员把 SFC 的代码行控制在 400~600 行以内（包含了模板），太过于复杂的就会建议他们按照 **容器组件** 和 **展示组件** 的思想拆分。
👉 [关于 React 的 Container&Presentational Component 模型结构分析 - Clark's Blog - SegmentFault 思否]( https://segmentfault.com/a/1190000007875199)

vue3 我用的挺爽的，比 react 我觉得更自然，除了 slot 这个天生的有点不方便没办法

我个人喜欢用 @tanstack/vue-query
代码基本是这个风格：

const { data, isLoading, refetch, edit } = useCurrentUser()
const { data: options } = useUserOptions()

基本上业务处理逻辑能扔的全扔到 hooks 里面

api 各种接口全都用 openapi-typescript 去生成类型声明，用 useQuery 去封装

常用库：
es-toolkit
@vueuse/core

常用 vite 插件：
unplugin-auto-import
unplugin-vue-components
unplugin-vue-router

乱不乱看个人，更容易封装了是真的

感觉还是 vue2 用着爽一点。。。

@visper 但实际上“一块功能”的代码往往也包含模版和样式，依然是分散的

这张图在所有组合式 API 的布道里都会出现，但我在实际中几乎没见过这种 case ，一个组件复杂到需要这样拆分逻辑，却又不能拆分子组件

其实 vue3 开启 setup 后方便很多，vue2 的 option 写法从别处 import 一个函数还要挂载到 data 里才能在 template 里用，如果后来这个函数不用了，清理冗余代码也是一件头疼的事。

我也是刚刚从 Vue2 切换到 Vue3 ，目前也是一头雾水。我想因为 Vue2 时代按照选项式已经写习惯了，即使换成 3 ，默认排序还是会不自觉按照类型去划分，而不是功能。到这一步，十分想要一个 C#的#region 块功能做代码块的功能注释，IDE 帮忙折叠代码块，这样会更好一些。
话说回来，控件的逻辑多了，即使 js 内部紧密，距离 div 还是十万八千里，个人感觉这种单个“重控件”不是一种很好的实践，不如尝试解耦，就像 16#说的那样。

@shintendo #16 ， 大部分人已经在日常开发中。已经按照自己的整洁偏好去整理了代码或者拆分了组件，所以没有什么感知。

如果你点开 Vue 关于这个图片介绍部分的仓库链接就能看到了。
👉 选项式 [vue-cli/packages/@vue/cli-ui/src/components/folder/FolderExplorer.vue at a09407dd5b9f18ace7501ddb603b95e31d6d93c0 · vuejs/vue-cli]( https://github.com/vuejs/vue-cli/blob/a09407dd5b9f18ace7501ddb603b95e31d6d93c0/packages/@vue/cli-ui/src/components/folder/FolderExplorer.vue#L198-L404)
👉 组合式 [docs-zh-cn/assets/FileExplorer.vue at main · vuejs-translations/docs-zh-cn]( https://github.com/vuejs-translations/docs-zh-cn/blob/main/assets/FileExplorer.vue)

其实和我们日常开发的代码结构没有什么差别。代码量其实也没有很大。
我个人没有什么感觉，但是 Options API 需要在 data ，computed ，methods 来回反复横跳已经被社区诟病很久了。

@dfkjgklfdjg @shintendo 我对组合式这种集中业务逻辑的设计没有任何意见, 对于明显属于复用的代码, 可以分离成一个 Composable, 没有什么心智负担. 但是对于普通的业务组件, 就是一堆面条代码, 重要的不是复用, 而是切分组织不同功能点, 但是我对它的拆分管理的方法有疑问, 如果像图上这样, 一堆一堆的放在一起, 但是实际代码里面可没有这些颜色区分代码, 实际上就是一坨, 写多了自然就乱了. 我很想拆成不同文件, 但是就像前面说的, 之前尝试过有点失败, 分离成 useComposable 之后, 主页面就是一堆的{xxx,xxx,......}=userXXX 的代码, 括号里面可能一下子就是 8/9 个需要导出的参数, 看着就很累, 好像也不优雅.

所以在拆分业务逻辑或者拆分子组件这一块, 到底应该怎么做比较好? 或者说你们真的很喜欢那种 useXXX, 然后导出 8/9 个参数的写法?