Vue框架引入JS库的正确姿势

本文介绍了在Vue项目中引入第三方库的最佳方式,包括全局变量法、处处引入法及正确的引入方式,并详细阐述了如何通过Vue原型对象和插件机制来实现高效、简洁的库引入。

原文,作者 @Anthony Gore; 译文,译者 @ 野草 原文有删改


错误示范

  • 全局变量法

最不靠谱的方式就是将导入的库挂在全部变量window 对象下:

// entry.js:
window._ = require('lodash');

// MyComponent.vue:
export default {
  created() {
    console.log(_.isEmpty() ? 'Lodash everywhere!' : 'Uh oh..');
  }
}

这种方式的缺点有很多,我们只说其中一个关键的点:不支持服务端渲染。当应用跑在服务端时,window对象不存在,当然试图去访问window下的属性会抛出错误。

  • 处处引入法

另外一个不太优雅的方式就是在需要的每个文件中都引入对应的库:

// MyComponent.vue:
import _ from 'lodash';

export default {
  created() {
    console.log(_.isEmpty() ? 'Lodash is available here!' : 'Uh oh..');
  }
}

虽然这方法是可行的,但是太不简洁。你必须在每个文件中都记得引入, 而且如果不需要了,又得重新删除。另外,如果打包策略不够明智的话,可能会打包出多份重复的代码。

正确引入方式

  • 最简单靠谱的方式是用库变成Vue的原型对象的属性。下面,我来演示如何将Moment 库引入:
import moment from 'moment';
Object.definePrototype(Vue.prototype, '$moment', { value: moment });

Object.definePrototype 语法参见 MDN

由于所有的组件都会继承Vue原型对象上的方法,因此这些方法在任何组件文件中都能通过this.$moment 访问到:

// MyNewComponent.vue
export default {
  created() {
    console.log('The time is ' . this.$moment().format("HH:mm"));
  }
}

使用 Object.defineProperty 定义对象属性,如果不在属性描述器中额外说明,则该属性就是默认只读的,保护引入的库不被重新赋值。

  • 写成插件

如果你在项目的很多地方都用了某个库,或者你希望全局可用,你可以构建自己的Vue 插件。

插件能化繁为简,能让你像下面这样很简单地引入自己想要的库:

import MyLibraryPlugin from 'my-library-plugin';
Vue.use(MyLibraryPlugin);

就像Vue Route,Vuex等插件一样,我们的库仅仅需要两行,就能在任何地方使用了。

如何写插件

首先,创建一个文件。本例中,我将引入一个Axios库的插件。我们就把这个文件命名为axios.js 吧。

最关键的地方在于,我们需要暴露一个将Vue构造器作为第一个参数的install 方法。

// axios.js:

export default {
  install: function(Vue) {
    // Do stuff
  }
}

然后我们可以用之前的方式将库添加到Vue的原型对象上:

// axios.js
import axios from 'axios';

export default {
  install: function(Vue) {
    Object.defineProperty(Vue.prototype, '$http', { value: axios });
  }
}

接着我们只需要Vue实例的use方法就能将这个库引入整个项目了。我们像下面代码一样简单引入:

// entry.js
import AxiosPlugin from './axios.js';
Vue.use(AxiosPlugin);

new Vue({
  created() {
    console.log(this.$http ? 'Axios works!' : 'Uh oh..');
  }
})

插件参数设置

插件的install方法还可以接受其他的可选参数。有些开发者可能不喜欢Axios实例对象的方法名$http,因为Vue resource插件的方法名也是这个。然后,让我们利用第二个参数来修改它。

// axios.js
import axios from 'axios';

export default {
  install: function(Vue, name = '$http') {
    Object.defineProperty(Vue.prototype, name, { value: axios });
  }
}
// entry.js
import AxiosPlugin from './axios.js';
Vue.use(AxiosPlugin, '$axios');

new Vue({
  created() {
    console.log(this.$axios ? 'Axios works!' : 'Uh oh..');
  }
})

当然上面,我们可以直接在Object.defineProperty的中将name属性写死成$axios。也可以在install方法中引入多个需要的库。

是否在开发“陪玩项目”时使用 **若依(RuoYi)框架**,取决于你的具体需求、团队技术栈和项目规模。下面我们从多个维度详细分析: --- ## ✅ 什么是若依(RuoYi)? > **若依(RuoYi)** 是一个基于 Spring Boot + MyBatis Plus 的开源后台管理系统,提供权限管理、代码生成、定时任务等企业级功能,适合快速搭建 **Java 后端管理系统**。 - 官网:https://ruoyi.vip - 技术栈: - 后端:Spring Boot、MyBatis、Shiro/Spring Security - 前端:Vue2/Vue3(RuoYi-Vue)、Thymeleaf(前后端不分离版) - 数据:MySQL - 工具:Redis、Quartz、Swagger、JWT 等 --- ## 🚫 若依的局限性(不适合直接用于“陪玩小程序”的地方) | 需求 | 若依能否满足? | 说明 | |------|----------------|------| | 小程序用户端交互 | ❌ 不擅长 | 若依主要是 **后台管理界面**,不是面向用户的 App 或小程序前端 | | 实时通信(聊天、接单提醒) | ❌ 缺失 | 若依无 WebSocket、IM 支持,陪玩项目通常需要实时消息推送 | | 高并发订单处理 | ⚠️ 可扩展但需改造 | 默认架构偏传统,高并发场景需引入 Redis、MQ、分布式等 | | 微信生态集成(登录、支付) | ⚠️ 需自行开发 | 若依不内置微信小程序授权、支付等功能 | | 地理位置匹配(附近接单员) | ❌ 需额外开发 | 没有地理位置服务支持(如腾讯地图 API 集成) | | 多角色动态切换(用户/陪玩师) | ⚠️ 可做但复杂 | 权限模型适合 RBAC,不适合业务角色动态变化 | --- ## ✅ 若依适合做什么? ✅ **适合做“运营管理后台”** 你可以用若依来构建以下系统: | 功能模块 | 是否适合用若依 | |--------|----------------| | 用户管理(封禁、审核) | ✅ 非常合适 | | 订单管理(查看、导出) | ✅ 内置表格+导出 | | 接单员资质审核 | ✅ 表单+审批流可定制 | | 内容审核(标签、协议) | ✅ 可建内容管理模块 | | 数据统计报表 | ✅ 图表插件支持 | | 运营活动配置 | ✅ 可扩展实现 | 👉 所以:**可以用若依做一个“运营后台”,但不能直接用来做“陪玩小程序后端主服务”** --- ## ✅ 更合理的架构设计(推荐方案) ```text +----------------------------+ | 小程序 / APP | ← 用户 & 陪玩师使用 +------------+---------------+ | HTTPS / WebSocket | +------------v---------------+ | 自研 Spring Boot | ← 核心业务逻辑 | - 登录注册(微信 OAuth) | | - 聊天系统(Netty/WebSocket)| | - 订单流程(状态机) | | - 地理位置匹配 | | - 支付回调处理 | +------------+---------------+ | JDBC / Redis / MQ | +------------v---------------+ | MySQL + Redis | ← 存储数据 +----------------------------+ +----------------------------+ | 若依 RuoYi 管理后台 | ← 运营人员使用 | 查看数据、审核、配置 | | → 调用上面的核心服务API | +----------------------------+ ``` ### 🔧 技术选型建议 | 模块 | 推荐技术 | |------|---------| | 后端核心服务 | Spring Boot + MyBatis Plus + Redis + WebSocket | | 小程序前端 | UniApp / Taro / 原生小程序 | | 实时通信 | WebSocket + Netty 或 第三方 IM(融云、即构) | | 地理位置 | 腾讯地图 JS SDK / WebService API | | 文件存储 | 七牛云 / 腾讯云 COS | | 消息通知 | 微信模板消息 / 订阅消息 | | 运营后台 | 若依(对接自研服务 API)| --- ## ✅ 若依怎么用?—— 正确姿势 1. **作为独立的“运营管理平台”** - 单独部署若依 - 开发 RESTful API 对接你自己的核心服务 - 在若依中展示订单、用户、审核列表等 2. **利用其代码生成功能** - 快速生成基础 CRUD 页面(如:文章管理、公告发布) - 减少重复工作量 3. **权限系统复用** - 使用若依的菜单、角色、部门、岗位管理体系 - 给客服、管理员分配不同权限 --- ## ✅ 替代方案对比 | 方案 | 优点 | 缺点 | 适用场景 | |------|------|------|----------| | 若依(RuoYi) | 快速搭建后台,权限完善 | 不适合用户端,缺少实时能力 | 运营后台 | | 自研 Spring Boot | 完全可控,灵活扩展 | 开发周期长 | 核心业务系统 | | Node.js (Koa/NestJS) | 快速开发,适合 I/O 密集 | Java 生态弱 | 初创团队 | | 低代码平台(如 JeecgBoot) | 拖拽生成页面 | 性能差,难定制 | 简单内部系统 | --- ## ✅ 结论:要不要用若依? ### ❌ 不要这样用: > “我用若依直接开发整个陪玩项目的小程序后端 + 用户端” ❌ 错误!若依不是为这类高互动、实时性强的应用设计的。 ### ✅ 正确做法: > “我用 Spring Boot 自研核心服务,同时用若依搭建一个运营后台来管理数据” ✅ 推荐!发挥各自优势。 --- ## ✅ 最佳实践建议 1. **核心服务自己写**:登录、下单、聊天、支付、匹配算法 2. **运营后台用若依**:让运营人员可以查看和管理数据 3. **前后端分离**:小程序 ↔ 自研后端;若依 ↔ 自研后端(通过 API) 4. **后期可微服务化**:订单服务、用户服务、聊天服务拆分 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值