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

其实原本的 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)

我个人喜欢用 @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

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

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

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

@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())`，也是官方推荐的写法

你仍然可以沿用部分 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

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

```js

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

} else{

}
//#endregion
```

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

@zcf0508 是 vue 核心成员做的

发错了🤦‍♂️

@yesterdaysun 你可以讓 composable 返回一個 reactive object ，例如

```
function useComposable() {
const r = ref()
const c = computed(() => xxx)
return reactive({
r,
c
})
}

const composable = useComposable()
composable.c // 模板裏
```

@jenhe #49
<template>
<div class="fullscreen bg-blue text-white text-center q-pa-md flex flex-center">
<div>
<div style="font-size: 30vh">404</div>
<div class="text-h2" style="opacity: 0.4">Oops. Nothing here...</div>
<q-btn class="q-mt-xl" color="white" text-color="blue" unelevated to="/dashboard" label="Go Home" />
</div>
</div>
</template>

<script lang="ts">
import { Component, Vue } from 'vue-facing-decorator';

@Component({
name: 'myComponents404',
})
export default class myComponents404 extends Vue {
mounted() {
this.$router.push('/dashboard');
}
}
</script>

自我感觉 class 方式写起来很舒服

最郁闷的是 vue3 和 vue2 完全就是 2 个不同的东西，没法相互兼容，很多老项目还在用 vue2 ，根本无法升级。

就因为这样弃掉 vue 的，新项目完全用 reactjs 了，毕竟到时候又弄个 vue4 不兼容 3 和 2 咋办。

@pakholeung372 #56 ，并不是说完全按照这个标准去实施，按照容器和展示组件的理念在大组件的场景下作为拆分组件的指导。复杂的业务逻辑依旧可以把他们提取成单独的 TS 函数或者 Hooks 。
但是作为渲染的叶子节点组件，我觉得不要业务太多强相关逻辑是正确的，在容器组件把数据处理好传递下来就行了，我们需要确定数据会在哪些部分做哪些修改。如果是视图层的交互逻辑，没有必要区分的太清楚，我觉得主要是数据的组装和接口交互。

过度拆分和封装的问题，不一定是容器和展示组件导致的。这个是经验问题，在职业生涯的起步阶段必定会经历的过程。需要开发者自己知道为什么拆分会带来什么好处，而不是按部就班。

写状态不是跟写变量一样吗？怎么把相关的逻辑/状态/变量一起抽象封装掉才是编程能力的体现，只知道复制粘贴，不会抽象/封装的话，写啥都一样的，最后都是一地鸡毛。甚至你用别人封装好的也是一种进步。

另外，Composition API 对标 React Hooks ，明明让“封装”这件事更极致了，从组件层面进一步细化到逻辑层面。而且还改进了不少：没有闭包问题，可以在判断条件下执行...