「后端小伙伴来学前端了」Vue脚手架中 render 函数

简介: 「后端小伙伴来学前端了」Vue脚手架中 render 函数

微信截图_20220525210339.png


前言


上一篇文章写了:「后端小伙伴来学前端了」分析Vue脚手架结构


简单说明了Vue的脚手架结构,但是上篇文章还欠了个小点没有说完,就在这篇文章中补齐。就是所谓的render函数。


一、main.js中引入的原来是残缺版vue.js


我们来接着看看main.js这个入口文件。


// 引入vue
import Vue from 'vue'
// 引入app组件
import App from './App.vue'
// 关闭生产提示
Vue.config.productionTip = false
// 创建 Vue 实例对象 Vm
new Vue({
  render: h => h(App) // 这里不是一下就能说完的,这里简单说下:
  // App 组件渲染,这里的 h 即是 vm.$createElement ,便是在vm.render这个阶段
  // 最粗略的理解,执行完这里,就是将app 放入了 容器中去了。
}).$mount('#app')
// Vue 的$mount()为手动挂载  这个也不是一下能说清,我也学艺不精,以后再补上 哈哈


这个代码,我想咱们只要创建过vue项目,大家肯定都写过了哈。


但是不知道大家有没有纠结过或者思考过new Vue() 中的 render:h=>h(App)是干什么。


(我是纯属刚学,好奇宝宝😂)


按照我们最开始的学习:


下面这种写法也是可行的吧,组件我们引入了,也注册了。


import Vue from 'vue'
import App from './App.vue'
Vue.config.productionTip = false
new Vue({
  template:'<App></App>'  
  components:{App}
}).$mount('#app')


看页面:


QQ截图20220525210458.png


页面上是空白的,然后有以下报错信息:


//报错
vue.runtime.esm.js?2b0e:619 [Vue warn]: You are using the runtime-only build of Vue where the template compiler is not available.
//提示的解决方式
Either pre-compile the templates into render functions,
   or use the compiler-included build.
(found in <Root>)


这里的报错意思:您正在使用仅运行时版本的Vue


解决方式提示有两种:


可以将模板预编译为呈现函数, 就是我们之前写的 render 函数
也可以使用编译器附带的构建。(换成人话就是使用完整版的vue,包含模板编译器版本的vue)


注意:我们在 main.js 中所引用的import Vue from 'vue',其实是一个运行时版本的vue,并非是完整的。


证明方式:


我们按照ctrl,用鼠标点击我们引入的vue,再点到vue的文件夹下的dist文件下的vue


QQ截图20220525210600.png


在这源码上加上一句话,看看会不会运行。


微信截图_20220525210634.png


虽然还是报错的,但是我们打印的那句话是已经出来了。(虽然有那么多vue...js,但是咋知道是这个呢?测出来的,亲测)


微信截图_20220525210718.png


报错提示中,告诉我们说,如果引入完整版vue也能解决问题,那么我们就引用完整路径,来测试一下,看可以吗?


微信截图_20220525210802.png


当我引入完整版的vue之后,我项目中的内容就已经展示出来了,控制台也不再报错。


到这个时候,大家也会想,我们既然可以通过引入完整的 vue.js 来进行模板的解析,为什么还要写那个 render函数呢?


原因大致如下:


这个模板引擎只是在我们生产的时候能够用到,当我们用 webpack 进行打包的时候,就用不上这个vue这个自带的模板引擎了, webpack已经帮我们把vue文件解析成了浏览器认识的.js、.css、.html文件了,那么vue的引擎也没必要继续存在那啦丫。(你可以把它当做个工具人,用就要,不用就扔掉哈哈)


但是如果我们一定残缺版的vue呢?这个render函数在这里是做什么呢?


二、render函数


我们先看看效果哈,当我们改成残缺版vue.js,写上render函数,是成功可以运行的


QQ截图20220525210840.png


接下来我们一步一步把这个函数解析出来哈:


我们先拆成个普通函数,看看它是什么样的哈


render (h) {
    console.log(h)
    return null
}


我把拆开,输出来是下面这样的:


微信截图_20220525210911.png


这个传进来的参数原来就是个 函数。它的返回值也是函数createElement()

首先说明一下我的demo项目的结构,然后你再思考思考


QQ截图20220525210939.png


我是有一个App组件和四个组件小组件,并且在App中进行了引入,而这上面也正好有四个参数,


createElement()中正好是一个vm,后面跟着这四个参数。


我们简单想一下就是一个App带着四个小弟哈哈.


所以换而言之,如果我们写成普通函数,就是如下状态


render (h) {
    console.log(h)
    return h(App)
}


因为我们的组件全部都在 App 内,所以我们实际只需要渲染 app 即可啦。


但是这里的其实不叫h,它真正的术语叫createElment


render (createElment) {
    return createElment(App)
}


然后再简化成箭头函数就成了脚手架中的 render: h => h(App)


这里 render 其实就是App组件渲染,脚手架方便确实方便了很多,但是真的封装了很多我们看不到的东西.


虽然有手就能用,但是就因为简单,我想我们对于它的理解,在很长很长的一段时间内都会处于表面上吧.


后语


大家一起加油!!!如若文章中有不足之处,请大家及时指出,在此郑重感谢。


纸上得来终觉浅,绝知此事要躬行。

大家好,我是博主宁在春主页

一名喜欢文艺却踏上编程这条道路的小青年。

希望:我们,待别日相见时,都已有所成


目录
相关文章
|
21天前
|
前端开发 JavaScript 开发者
React与Vue:前端框架的巅峰对决与选择策略
【10月更文挑战第23天】React与Vue:前端框架的巅峰对决与选择策略
|
21天前
|
前端开发 JavaScript 数据管理
React与Vue:两大前端框架的较量与选择策略
【10月更文挑战第23天】React与Vue:两大前端框架的较量与选择策略
|
26天前
|
JavaScript 前端开发 算法
前端优化之超大数组更新:深入分析Vue/React/Svelte的更新渲染策略
本文对比了 Vue、React 和 Svelte 在数组渲染方面的实现方式和优缺点,探讨了它们与直接操作 DOM 的差异及 Web Components 的实现方式。Vue 通过响应式系统自动管理数据变化,React 利用虚拟 DOM 和 `diffing` 算法优化更新,Svelte 通过编译时优化提升性能。文章还介绍了数组更新的优化策略,如使用 `key`、分片渲染、虚拟滚动等,帮助开发者在处理大型数组时提升性能。总结指出,选择合适的框架应根据项目复杂度和性能需求来决定。
|
21天前
|
前端开发 JavaScript 开发者
React与Vue:前端框架的巅峰对决与选择策略
【10月更文挑战第23天】 React与Vue:前端框架的巅峰对决与选择策略
|
1月前
|
存储 人工智能 前端开发
前端大模型应用笔记(三):Vue3+Antdv+transformers+本地模型实现浏览器端侧增强搜索
本文介绍了一个纯前端实现的增强列表搜索应用,通过使用Transformer模型,实现了更智能的搜索功能,如使用“番茄”可以搜索到“西红柿”。项目基于Vue3和Ant Design Vue,使用了Xenova的bge-base-zh-v1.5模型。文章详细介绍了从环境搭建、数据准备到具体实现的全过程,并展示了实际效果和待改进点。
133 2
|
1月前
|
JavaScript 前端开发 程序员
前端学习笔记——node.js
前端学习笔记——node.js
41 0
|
1月前
|
人工智能 自然语言处理 运维
前端大模型应用笔记(一):两个指令反过来说大模型就理解不了啦?或许该让第三者插足啦 -通过引入中间LLM预处理用户输入以提高多任务处理能力
本文探讨了在多任务处理场景下,自然语言指令解析的困境及解决方案。通过增加一个LLM解析层,将复杂的指令拆解为多个明确的步骤,明确操作类型与对象识别,处理任务依赖关系,并将自然语言转化为具体的工具命令,从而提高指令解析的准确性和执行效率。
|
1月前
|
存储 弹性计算 算法
前端大模型应用笔记(四):如何在资源受限例如1核和1G内存的端侧或ECS上运行一个合适的向量存储库及如何优化
本文探讨了在资源受限的嵌入式设备(如1核处理器和1GB内存)上实现高效向量存储和检索的方法,旨在支持端侧大模型应用。文章分析了Annoy、HNSWLib、NMSLib、FLANN、VP-Trees和Lshbox等向量存储库的特点与适用场景,推荐Annoy作为多数情况下的首选方案,并提出了数据预处理、索引优化、查询优化等策略以提升性能。通过这些方法,即使在资源受限的环境中也能实现高效的向量检索。
|
1月前
|
机器学习/深度学习 弹性计算 自然语言处理
前端大模型应用笔记(二):最新llama3.2小参数版本1B的古董机测试 - 支持128K上下文,表现优异,和移动端更配
llama3.1支持128K上下文,6万字+输入,适用于多种场景。模型能力超出预期,但处理中文时需加中英翻译。测试显示,其英文支持较好,中文则需改进。llama3.2 1B参数量小,适合移动端和资源受限环境,可在阿里云2vCPU和4G ECS上运行。
|
1月前
|
前端开发 算法 测试技术
前端大模型应用笔记(五):大模型基础能力大比拼-计数篇-通义千文 vs 文心一言 vs 智谱 vs 讯飞vsGPT
本文对比测试了通义千文、文心一言、智谱和讯飞等多个国产大模型在处理基础计数问题上的表现,特别是通过链式推理(COT)提示的效果。结果显示,GPTo1-mini、文心一言3.5和讯飞4.0Ultra在首轮测试中表现优秀,而其他模型在COT提示后也能显著提升正确率,唯有讯飞4.0-Lite表现不佳。测试强调了COT在提升模型逻辑推理能力中的重要性,并指出免费版本中智谱GLM较为可靠。
前端大模型应用笔记(五):大模型基础能力大比拼-计数篇-通义千文 vs 文心一言 vs 智谱 vs 讯飞vsGPT