@drymonfidelia #4 ，OP 你是怎么安装的，我怎么安装完默认还都是 VSC ，还得一个一个去改成 Cursor……

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

学好 JavaScript ，以及更基础的计算机科学与技术 /dog

不要局限于某一个框架，和某一个语言上面。

@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)

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

@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 来回反复横跳已经被社区诟病很久了。

企业规模大了必定会爬流程开始邮件扯皮。小而美的公司完全就是看老板性格。

前段时间听播客，感觉 XMind 应该会匹配 OP 你的需求，但是 base 在深圳。

[加入我们 | Xmind 思维导图 | 中文官方网站]( https://xmind.cn/joinus/)
[Vol. 140 Xmind 创始人孙方: 我的烦恼越来越多，但我不烦恼了 - 枫言枫语 | 小宇宙 - 听播客，上小宇宙]( https://www.xiaoyuzhoufm.com/episode/680f52017a449ae85831a854)

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

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

👇 所谓的整洁度其实也就是下面这样图这样，把相关联的业务逻辑放到一起来维护
https://i.imgur.com/xo0IO14.png

那么其实就是靠人的自觉来把相关的逻辑放到一起，如果没有开发规范或者一些约定，胡乱 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)

@haidaomihuan #22 ，我选择不来杭州 /dog

偶尔因为急事，早高峰时间段下了高速直接上东湖高架，还没有被拍被拦停过。
但次数很少一年也就一两回。如果是天天跑，那还是别了。次数多了总归要翻车的。

杭州高架上是真的堵。每次都想我为什么下了高速之后直接上高架……我想走地面。

是的，区分兼职和副业的区别就是 OP 你形容的 "微型 or 低成本创业" 的感觉。

但是按照 OP 的描述，是不是可以理解成另一种形式、但必定有加班费的"加班"。
得想清楚，"副业"为什么是"副业"。如果现在这份所谓的"副业"变成了"主业"，和你现在的工作有什么区别吗？

@klo424 淘宝上有很多现成的小刷子，可以刷耳机接缝和耳机盒腔室的。

@klo424 #20 ，干刷，又不是让你沾水刷……最多蘸着酒精，或者一边刷一遍湿巾擦。

牙刷刷。

每天用完勤擦就好了，一般都是用完不擦才会有污垢

@PEALFK #17 ，你直接走可能就中招了。得赶紧和劳动大腿咨询一下。是否会影响你后续仲裁的结果。