第一生产力
思路
、取舍代码风格
面试加分项
画虎不成反类犬
(强行上马 vue3,自己焦头烂额、项目难以维护、同事苦不堪言)没有可读性
,影响团队协作的奇技淫巧更好的逻辑复用与代码组织
更好的类型推导
使用 proxy 取代 Object.defineProperty
v-model 代替以前的 v-model 和.sync
Template 支持多个根标签
composition API 实现逻辑模块化和复用
尤雨溪
: 不同意这个观点。
Vue 最开始很小,但是现在被广泛应用到不同级别复杂度的业务领域,有些可以基于 option API 很轻松处理,但是有些不可以。例如下面的场景:
对于问题 1,你需要把每个逻辑拆分到不同选项,例如,一段逻辑需要一些响应数据,一个计算属性,一些监听属性还有方法。你去了解这段逻辑时,需要不断上下移动阅读,虽然你知道一些属性是什么类型,但是你并不知道他具体的作用。当一个组件包含多个逻辑,情况就更糟糕了。如果用新的 API,可以将数据和逻辑组合在一起,最重要的是,你可以干净的把这些逻辑提取到一个函数,甚至一个单独的文件中。
尤雨溪
: 这个问题和项目文件组织方式问题类似。我们很多人都同意按文件类型组织(布局放 HTML,样式 CSS,逻辑 JS)并不是正确的方式,因为强制把相关代码分割到三个文件,只是给人一种“关注点分离”的错觉。这里的关键是“关注点”不是由文件类型定义
。相反,我们大多数选择以功能或者职责来组织文件
,这正是人们喜欢 Vue 单文件组件的原因。SFC 就是按功能组织代码的方法,但讽刺的是当首次引入 SFC 时,许多人也是拒绝的,认为它违反了关注点分离。
尤雨溪
: 正好相反,新的 API 就是为了提高项目长期维护性的。如果我们查看任何 javascript 项目,都会从入口文件开始阅读,该文件的本质是你的应用启动时被隐式调用的"main"函数。如果只有一个函数入口,会导致意大利面条代码,那所有的 js 项目都是意大利面条代码。显然不是的,因为开发人员通过代码模块化或者较小的函数来组织代码。另外,我同意新的 API 理论上会降低代码质量的最低门槛
。但是我们可以使用以往防止代码变成意大利面条的手段缓解这种情况。另一方面,新的 API 可以提升代码质量的最高上限
,相比 option api,你可以重构为质量更高的代码。而且,基于 Option api 你还得解决类似 mixins 的问题。很多人认为"Vue 失去简单性",实际上只是失去组件内代码类型检查能力(就是你不知道一个变量时 data、method、还是 computed)。但是用新的 API,实现一个类型检测器也是非常容易实现以前的特性的。也就是说,你不应该被 option api 限制思维,而更多关注逻辑内聚问题
。
git clone https://github.com/vuejs/vue-next.git
yarn install
yarn dev --sourcemap
yarn dev --sourcemap
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<div id="app">
<div>
<div>test demo {{msg}}</div>
<div>test demo {{msgMore}}</div>
</div>
</div>
<script src="../dist/vue.global.js"></script>
<script>
Vue.createApp({ setup() { const msg = Vue.ref('Hello') const msgMore = Vue.computed(()=>msg.value+' world') return { msg, msgMore } } }).mount('#app')
</script>
</body>
</html>
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。