VUE3.0项目实战（序言）--认识VUE3

 

VUE是什么

        是用来做视图渲染的工具，做视图渲染的框架

vue3中我们要告别

• v-bind
• v-model
• v-slots
• @input
• sfc

        告别你所学过的vue知识，拥抱函数式简约设计，更符合人类直觉的设计。到了vue3设计思想和react开始合并，开始朝着专注视图渲染的框架去发展

 

MVVM框架？

• Model: 模型（领域模型）
• view：视图
• view Model：视图模型(展示性数据)

view = f(data)

        视图对于一段函数去计算一段数据，但是这不是全部，因为这解释不了页面是怎么跳转的，交互是怎么进行的，请求是如何发送的，深挖还要加上特定条件，但是这是vue的大体功能。

  这里vue的视图渲染可以当一个纯函数，我们给他一个数据就可以渲染视图。

 

纯函数

        当一个函数输出只取决于他的输入时，这个函数就是纯函数。而一个函数在他的函数当中他的输出和输入之外，还做了其他的行为，就不是一个纯函数。

         输入和输出是不会发生变化，所以非常符合测试，为纯函数写一个测试用例，这个测试用例是非常稳定的，你只要给他正确的输入或错误的输入他就会产生你期待的结果，无论正确还是错误的，如果没有产生你期待的结果，你就可以去修改这个问题，而一个不纯的函数行为是很难预测的，一个函数中程序的行为可以预测，那么这个程序就是健壮的。

        函数纯粹计算职能之外的东西，我们统一称为副作用，前端必须要有副作用，否则是没有办法去跳转页面，或者发起请求。

副作用（effect)

 计算和副作用

UI = f(data) with effect[ ]

        这个时候vue将计算和副作用做了区分，对于纯函数部分，输入的是数据，返回的是视图。然后在加上副作用，这就是现在的UI.

        所以说UI就是一个将数据渲染成视图的函数加上副作用，就是今天我们所说的UI。这就是vue3最核心的内容。
        重新定义vue产品边界，从一个尽量为用户解决更多问题的mvvm框架，去改变，变成一个专注于数据到视图的映射，以及副作用封装的框架，专注视图渲染的框架。

 

VUE3.0

希望自己更快更小，在这方面做出自己的努力，但是不是特别的引人注目，不是这一次的核心内容

• 更快(Time slice去掉了：Https://github.com/vuejs/rfc/issues/89）
  本来是要加入time slice的技术，因为前端渲染比较快，不需要时间切片，就删除了，个人认为vue3这个版本的迭代周期没有那么长，或者说vue的设计本身就是简单分隔的设计，并不是用于非常大型的项目去做的，如果花大量时间人力开发这个技术是不划算的，而且这个技术不太好开发
• 更小（Treeshakable）
  因为vue从出现开始到今天，他很多时候都在负责一些中等的，中等偏小的。一些小微型或中型的项目，大家呢很愿意去用vue，因为vue一个平缓的学习曲线，和提供功能的广度，这是个人认为vue在中国最受欢迎的原因，但是大型项目，真的非常追求性能的情况，可能需要react中fiber那样的机制
• 最重要就是更好用、更好维护
  • Composition API
  • reactivity
  • JSX/Typescript

到了vue这个时代，就很少去写单文件组件了，我的选择更愿意用jsx去架构我们的系统。

JSX成为行业标准

        在前端发展当中，有一件事情，在近些年，typescript出现之后，jsx逐渐成为我们前端行业的标准。无论是webpack，rulop这样知名的前端工具链，还是react这种重量级的对script优化，他们都原生的支持jsx，他们都有在最核心的部分进行了支持，特别是ts，在tsconfig中就可以去配置解析jsx文件

 
        因为jsx非常好用，因为他非常符合w3c的标准，从有w3c以来，html一直都是描述界面的标准，所以直接这么使用，而且js和html混合的模式，更能够提高我们设计复杂组件的抽象能力，因为模板的语法，在一个模板上再去嵌套一个模板，和这些东西作为一个程序，是两个概念，模板在好，终究替代不了程序，描述业务逻辑，描述组件交互，最好的方式就是procedure 程序本身，没有之一，以后推荐大家去写jsx。

 

VUE2 > VUE3

composition API & Reactivity

• 简化状态设计，更符合人的直觉
  这一部分的地位是为了简化状态设计，让状态管理更符合人的直觉，因为每一个组件是一个状态机，状态越好，就越好管理。
• 拥抱函数式
  用函数去解决问题
• 简化API
  • 让api更简单（setup，箭头函数）
  • 减少学习成本：v-model，v-bind。。。
• 更好的封装和最小粒度复用

Composition API

是vue3非常重要的一部分，提供了很多种的能力，这些API发生了些变化

• 定义组件
  • setup 初始化组件
  • defineComponent 定义组件的
• Reactivity
  对响应式发生了变化
  • ref
  • reactive
  • toRefs
  • computed
  • watch/watchEffect
    • 生命周期的钩子发生了变化

 其实在写vue3的用户不在那么注意生命周期了，我们做一个渲染引擎的最高境界，就让用户接触到一个概念模型，就像react，vue，我们所有的渲染，最终的产出是一个jsx对应的元素，而这个元素不是真的dom元素，我们将所有的问题集中在虚拟的概念模型上，那请问我知道他什么时候绘制到dom上还有意义吗？

VUE_NEXT（代号）

下一代，vue团队对vue3是跨着时代的，

安装vue3

npm installl vue@next

VUE-NEXT最核心的变更

无论何时我们都需要拥抱标准，无论了现在还是未来，我们都需要拥抱标准，因为这是程序员交流的工具，不要造太多违反标准的轮子，造轮子需要在标准之上

• Typescript
  vue加ts结合非常紧密，用起来非常的方便，这个是他的特点，他对ts支持并不是体现在vue3做了多少努力支持ts，恰恰相反，vue3将自己简化，而让ts在vue这个舞台拥有了很强的生命力，
• Composition API
  让我们系统可以有更好方式组合，写程序就是搭积木的过程，

这里有一个非常非常典型的例子，你拿杯子喝水是不是要东西装水，你拿茶壶喝水是不是也要拿容器装水，容器这个概念就是我们抽象出来的一种架构，我们无论是杯子还是茶壶，我们都需要容器，那么我们延展一下，游泳池很大，他也需要容器，在容器这个设计上，或者以容器这个结构而言，游泳池，杯子，茶壶有区别嘛，在抽象层面上没有区别，这个就是典型的架构，一种组合的思想，组合是我们在复用程序中最常见的手段，他们叫Composition API，虽然本质上他们是相似的，

• Reactivity
  对于响应式支持

什么是响应式（Reactivity）

• 类型响应环境变化
• 发生变化，类型不关心谁响应，只是向外暴露自己的变化(事件)

        响应当中一个对象一个类型，响应环境的变化，他不像以前我们做设计，一个类型去指挥其他类型干事，而是所有类型将自己状态告诉外部，他发生变化的时候并不是直接，通知另一个类型发生变化，他只是告诉中间人，我这里发生了什么变化在由中间人告诉所有和这个有关系的组件，从设计模式上讲，这非常像一个观察者模式，但他的本质也是一个观察者模式，当他一个组件发生变化的时候，他是告诉外界自己发生了变化，他并不关心这个变化会触发什么，这样每一个组件，每一个对象都会只专注在自己的工作上，这就是响应式，每一个组件不关心别人做什么，而是把自己事情都做好。

这就好像设计一个操作系统一样，每一个应用都focus us在自己在自己工作上，应用和应用，他们之间并不进行交互，并不由一个应用向另一个应用下达指令，诚然一个应用可以去发送一个消息去告诉另一个应用自己的状态发生了变化，但是怎么响应这个变化应用并不负责，

举个例子，当应用想要关闭时，是发一个关闭的事件告诉操作系统，操作系统在做后面的工作，他不能说一个应用控制操作系统去完成一步一步，第一没有权限，第二如果让应用控制操作系统的内核，那么这个应用和操作系统之间就耦合了，所以我们设计响应式各个元素之间是没有耦合的，之间不需要引用的关系。这也是vue提供给大家的设计模式理念。

Reactive值

• 响应式(Reactive)值专注计算逻辑的表达,不关心渲染细节
• 响应式大大降低了程序的耦合

 

Proactive vs Reactive

• 主动(proactive）关系中，A必须拥有B的实例
• 响应(reactive)关系中，A、B可以不必知道对方存在

        他们是不一样的，第一种A向b下命令，你a必须有b的实例才能下命令，如果说是b响应了a，那么b不需要拥有a的实例，a也不需要b的实例，因为b只需要去订阅a发布的事件，而a发布的事件是向公众的，大家都可以去看，如果b挂了不影响a，但是第一个设计b挂了，a也挂了。

引言

Why not SFC

• 理由1： SFC经过了努力但是没能成为标准（JSX已经成为标准）
  虽然是使用sfc时，我们需要使用一段typescript去定义类型，因为ts比如说.vue的文件。
   
  这一个，ts不理解，但是会认为.vue文件export是一个component组件，但是没有必要在做这件事情了，因为我们不会再用sfc

• 理由2：SFC不符合关注点分离原则
  作为一个关注点，你应该集中，作为两个关注点那就需要进行分离，

  • 逻辑集中管理
    html css 逻辑是集中管理的，
  • 封装（密封性）
  • 减少记忆

接下来就是正式开始走进vue的世界，我选择先用常规的SFC去书写我们的代码和项目，然后在带入我跟为推荐的JSX，我更推荐如何在VUE里面写JSX。

Why not SFC

• 理由1： SFC经过了努力但是没能成为标准（JSX已经成为标准）
  虽然是使用sfc时，我们需要使用一段typescript去定义类型，因为ts比如说.vue的文件。

  declare module ".vue"{
      import {Definecomponont} from"vue";
      const Component:DefineComponent;
      export default Component;
  }
  template>

  
  这一个，ts不理解，但是会认为.vue文件export是一个component组件，但是没有必要在做这件事情了，因为我们不会再用sfc

• 理由2：SFC不符合关注点分离原则
  作为一个关注点，你应该集中，作为两个关注点那就需要进行分离，

  • 逻辑集中管理
    html css 逻辑是集中管理的，
  • 封装（密封性）
  • 减少记忆

        接下来就是正式开始走进vue的世界，我选择先用常规的SFC去书写我们的代码和项目熟悉VUE3，然后在带入JSX在VUE开发实践，然而我更推荐如何在VUE里面写JSX。