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

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

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

没体会到 vue3 ，总觉得写起来很别扭。
项目不大，我又回退到 vue2 了。
管他呢， 写着爽才是真的爽。
vue2 也可以写的很有条理啊。

@lepig 原生 ts 的支持+摆脱 this.data 的限制，写法更灵活。

最佳实践不好说，但是好实践肯定是 vibe 出来的预制菜，让他给你写页面写组件，跟着预制菜写写法就行了

@coolcoolxk 根据后端接口文档生成 Typescript 类型声明文件的
后端接口文档一般都是 Swagger 这种遵循 OpenAPI 规范的，用这个就不用自己定义数据类型，跟后端接口数据格式保持同步
这样你在开发的时候因为有类型声明，写起来更容易
用这个的前提是你们后端 API 文档写的规范，并且前端项目也是 TypeScript 规范，不是到处用 any

我写组合式 api 是先按最小化原则和功能场景来写的，比如表单这块就定义一个 compositionFormBase ，弹窗就是 compositionDialogBase ，表单+弹窗就把他们组合起来构成 compositionDialogForm ，每个场景块拆到最小，然后根据日常场景组合，用的时候就比较灵活

@coolcoolxk 简单一句话，用了这玩意儿，你调用接口，接口 URL 会有提示，传参会有提示，返回值有提示，啥都有提示

vue 的 composable 和 react 的 hook 一样，都能用于实现 headless component ，将 state 和 logic 与 UI 解耦

我感觉主要是拆分模块封装，vue3 看着文档写着改着写了项目：

https://github.com/bojue/lemon-form

但是一般会把组件封装起来

1. 项目 [组件] ： https://github.com/bojue/lemon-form/tree/master/src/components
2. Form 表单 [元素组件] ： https://github.com/bojue/lemon-form/tree/master/src/components-form
3. Form 表单 [设置组件] ： https://github.com/bojue/lemon-form/tree/master/src/components-form-setting

每行代码不代表最佳实践，整体感觉维护成本很低

你说的大部分问题并不是 vue3 独有的，任何 ui 开发都会有你说的这些问题，vue3 的好处就是你可以精细化的控制粒度，每一个函数每一个组件都单独引入导出，也可以啥都一把梭，混到一起也没关系，就我个人而言，业务逻辑不用太在意，保持一个最低水平的控制就好了，如果要开发基础类库，再去考虑最佳实践之类的

@RogerL #67 感谢大佬

最佳实践? 就是换成 React

https://juejin.cn/post/7139497477086019621 已经落地了多个项目的实践

@BeijingBaby vue2.7 可以兼容两种写法，虽然会让项目看起来更💩了，但如果你只用组合 API 就可以了。

所以我还是喜欢 vue2 的写法，vue3 被 react 带偏了。这么一大堆东西，是逼着你往外拆分，拆费时间，不拆就乱。

react 写个子组件导出出去，vue3 写个子组件等别处引入，我用 react 点击函数名就能直接查看当前的函数组件谁在用，vue3 有这个吗？我有时就觉得，固定的 template ，script ，style 区域跟 optionsAPI 也没区别，还拉长格式化后的行数

个人感觉 vue3 对比 vue2 最大的爽点就是可以在 vue 文件之外定义响应式变量，按照逻辑拆分代码，封装 hooks ，hooks 里面 ref 数据源->computed 显示数据->watch 数据源做相关逻辑，这样一条数据链路写下来代码逻辑就很清晰了，然后在 vue 文件里面引入和组合 hooks ，这样单个 vue 文件就很整洁，要做修改就只需跳转到对应的 hooks 里面改就可以了，比起 vue2 那种在一个文件里疯狂滚动找逻辑要舒服多了

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

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

我感觉 options api 会给人一种自己已经整理了代码的错觉。因为它的分类依据完全是根据数据类型来的，强制你以一种没有负担的方式“分类”了。compose api 确实能做到更好的整洁性，但是代价是需要额外耗费心智来想怎么分类、抽离逻辑，这样开发在对于不熟悉或者没有这方面经验的人来说写着可能有些痛苦。毕竟之前自己只需要根据下意识的数据流逻辑顺着写下去就好了，现在没了 options api 的“整理结构”，即使写一些不大的组件自己也会很容易的察觉到代码乱需要整理，而这时候只能自己想办法整理了。

没办法，vue3 的写法就是一堆 const ，一堆 ref ，一堆 return 。