devbox
Guff_9hys
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

Vue搭建可视化界面_vue可视化

作者：Guff_9hys | 2024-08-13 09:28:10

赞

踩

vue可视化

最近更新：

收到很多私信，大家都想了解构建的源码和过程，因为之前涉及到很多公司内部业务和隐私，所以不方便放出来。应大家强烈要求，这里我将重写一个活动页构建工具供大家参考，持续更新，欢迎start和关注：

muwoo/rose​github.com图标

线上预览地址：

Rose​muwoo.github.io

 

前言

如果你经常接触一些公司的活动页，可能会经常头疼以下问题：这些项目周期短，需求频繁，迭代快，技术要求不高，成长空间也小。但是我们还是马不停蹄的赶着产品提来的一个个需求，随着公司规模的增加，我们不可能无限制的增加人手不断地重复着这些活动。这里也只是简单的给大家提供一种构建思路，比较笼统。 想要了解更多，也欢迎访问。有问题的地方也欢迎拍正 ：

厌倦了写活动页？快来撸一个页面生成器吧！ · Issue #36 · muwoo/blogs​github.com图标

目标

我们的目标是实现一个页面制作后台，在后台中我们可以对页面进行 组件选择 --> 布局样式调整 --> 发布上线 --> 编辑修改这样的流程操作。

架构设计

首先是要能提供组件给用户进行选择，那么我们需要一个组件库，然后需要对选择的组件进行布局样式调整，所以我们需要一个页面编辑后台接着我们需要将编辑产出的数据渲染成真实的页面，所以我们需要一个node服务和用于填充的template 模板。发布上线，这个直接对接各个公司内部的发布系统就好了，这里我们不做过多阐述。最后的编辑修改功能也就是针对配置的修改，所以我们需要一个数据库，这里我选择的是用了mysql。当然你也可以顺便做做权限管理，页面管理....等等之类的活。 啰嗦了这么长，我们来画个图，了解下大概的流程：

 

 

开撸

组件的实现

首先我们来实现组件这一部分，因为组件关联着后台编辑的预览和最后发布的使用。组件设计我们应该尽量保持组件的对外一致性，这样在进行渲染的时候，我们可以提供一个统一的对外数据接口。这里我们的技术选型是基于 Vue 的，所以下面的代码部分也主要是基于 Vue 的，但是万变不离其宗，其他语言也类似。

根据上图，我们的组件是会被一个个拆分单独发布到 npm仓库的，为什么这么设计呢？其实之前也考虑过设计成一个组件库，所有组件都包含在一个组件库内，这样只需要发布一个组件库包，用的时候按需加载就好了。后来在实践的过程中发现这样并不合适协同开发，其他前端如果想贡献组件，接入的改造成本也很大。

举个 ：小明在业务中写了个Button组件，这个组件经常会被其他项目复用，他想把这个组件贡献到我们的系统中，被模板使用，如果是一个组件库的话，他首先得拉取我们组件库的代码，然后按照组件库的规范格式进行提交。这样一来，偷懒的小明可能就不太愿意这么干，最爽的方法当然是在本地构建一个npm库，开发选用的是用TypeScript还是其他的我们不关心，选用的 Css 预处理器我们也不关心，甚至编码规范的ESLint我们也不关心。最后只需通过编译后的文件即可。这样就避免了一个组件库的约束。依托于NPM完善的发布/拉取，以及版本控制机制，可以让我们少做一些额外的工作，也可以快速的把平台搭建起来。

我们以一个Button为例，我们对外提供这样的形式组件：

  1. <template>
  2.   <div :style="data.style.container" class="w_button_container">
  3.     <button :style="data.style.btn"> {{data.context}}</button>
  4.   </div>
  5. </template>
  6. <script>
  7.  
  8. export default {
  9.   name: 'WButton',
  10.   props: {
  11.     data: {
  12.       type: Object,
  13.       default: () => {}
  14.     }
  15.   }
  16. }
  17. </script>

可以看到我们只对外暴露了一个props，这样做法的好处是可以统一组件对外暴露的数据，组件内部爱怎么玩怎么玩。注意，这里我们也可以引入一些第三方组件库，比如mint-ui之类的。

后台编辑的实现

在写代码前，我们先考虑一下需要实现哪些功能： 1. 一个属性编辑区，提供给使用者编辑组件内部props的功能 2. 一个组件选择区，提供使用者选择需要的组件 3. 一个组件预览区，提供使用者拖拽排序页面预览的功能

编辑区的实现

按照顺序，我们先来实现组件的属性编辑功能。我们要考虑，一个组件暴露出哪些可配置的信息。这些可配置的信息如何同步到后台编辑区，让使用者进行编辑，一个按钮的可配置信息可能是这样：

 

 

如果把这些配置全部写在后台库里面，根据当前选择的组件加载不同的配置，维护起来会相当麻烦，而且随着组件数量的增加，也会变得臃肿，所以我们可以将这些配置存储在服务端，后台只需要根据存储的规则进行解析便可，举个例子，我们其实可以存储这样的编辑配置：

  1. [
  2.   {
  3.     "blockName": "按钮布局设置", 
  4.     "settings": {
  5.       "src": {
  6.         "type": "input",  
  7.         "require": true,
  8.         "label": "按钮文案"
  9.       }
  10.     }
  11.   }
  12. ]

我们在编辑后台，通过接口请求到这些配置，便可以进行规则渲染：

  1.     /**
  2.      * 根据类型，选择创建对应的组件
  3.      * @param {VNode} vm
  4.      * @returns {any}
  5.      */
  6.     createEditorElement (vm: VNode) {
  7.       let dom = null
  8.       switch (vm.config.type) {
  9.         case 'align':
  10.           dom = this.createAlignElement(vm)
  11.           break;
  12.         case 'select':
  13.           dom = this.createSelectElement(vm)
  14.           break;
  15.         case 'actions':
  16.           dom = this.createActionElement(vm)
  17.           break;
  18.         case 'vue-editor':
  19.           dom = this.createVueEditor(vm)
  20.           break;
  21.         default:
  22.           dom = this.createBasicElement(vm)
  23.       }
  24.       return dom
  25.     }

组件选择区

首先我们需要考虑的是，组件怎么进行注册？因为组件被用户选用的时候，我们是需要渲染该组件的，所以我们可以提供一段 node 脚本来遍历所需组件，进行组件的安装注册：

  1. // 定义渲染模板和路径
  2. var OUTPUT_PATH = path.join(__dirname, '../packages/index.js');
  3. console.log(chalk.yellow('正在生成包引用文件...'))
  4. var INSTALL_COMPONENT_TEMPLATE = '    {{name}}';
  5. var IMPORT_TEMPLATE = 'import {{componentName}} from \'{{name}}\'';
  6. var MAIN_TEMPLATE = `/* Automatic generated by './compiler/build-entry.js' */
  7.  
  8. {{include}}
  9.  
  10. const components = [
  11. {{install}}
  12. ]
  13.  
  14. const install = function(Vue) {
  15.     components.map((component) => {
  16.         Vue.component(component.name, component)
  17.     })
  18. }
  19.  
  20. /* istanbul ignore if */
  21. if (typeof window !== 'undefined' && window.Vue) {
  22.     install(window.Vue)
  23. }
  24.  
  25. export {
  26.     install,
  27.     {{list}}
  28. }
  29. `;
  30. // 渲染引用文件
  31. var template = render(MAIN_TEMPLATE, {
  32.   include: includeComponentTemplate.join(endOfLine),
  33.   install: installTemplate.join(`,${endOfLine}`),
  34.   version: process.env.VERSION || require('../package.json').version,
  35.   list: listTemplate.join(`,${endOfLine}`)
  36. });
  37.  
  38. // 写入引用
  39. fs.writeFileSync(OUTPUT_PATH, template);

最后渲染出来的文件大概是这样：

  1. import WButton from 'w-button'
  2. const components = [
  3.     WButton
  4. ]
  5. const install = function(Vue) {
  6.     components.map((component) => {
  7.         Vue.component(component.name, component)
  8.     })
  9. }
  10. /* istanbul ignore if */
  11. if (typeof window !== 'undefined' && window.Vue) {
  12.     install(window.Vue)
  13. }
  14. export {
  15.     install,
  16.     WButton
  17. }

这个也是组件库的通用写法，所以这里的思想就是把发布到npm上的组件，进行聚合，聚合成一个组件包引用，我们在后台编辑的时候，是需要全量引入的：

  1. import * as W_UI from '../../packages'
  2.  
  3. Vue.use(W_UI)

这样，我们组件便注册完了，组件选择区，主要是提供组件的可选项，我们可以遍历组件，提供一个个 List 让用户选择，当然如果我们每个组件如果只提供一个组件名，用户可能并不知道组件长什么样，所以我们最好可以提供一下组件长什么样的缩略图。这里我们可以在组件发布的时候，也通过 node 脚本进行。这里要实现的代码比较多，我就大致说一下过程，因为也不是核心逻辑，可有可无，只能说有了体验上会好一点：

  1. 用户启用 dev-server 进行代码编写测试
  2. server 脚本使用 Chrome 工具 puppeteer，调整页面到手机端模式， 进行当前 dev-server 截图。
  3. 生成截图文件，上传到node服务，关联组件

这样，就可以在加载组件选择区的时候，为组件附上缩略图。

组件预览区

当用户在选择区选择了组件，我们需要展示在预览区域，那么我们怎么知道用户选择了哪些组件呢？总不能提前全部把组件写入渲染区域，通过 v-if来判断选择吧？当然没有这么蠢，Vue 已经提供了动态组件的功能了：

  1. <div 
  2.    :class="[index===currentEditor ? 'active' : '']" 
  3.    :is="select.name" 
  4.    :data="select.data">
  5. </div>

为什么我们不用缩略图代替真实组件？一方面生成的缩略图尺寸存在问题，另一方面，我们需要编辑的联动性，就是编辑区的编辑需要及时的反馈给用户。

额外的问题

说了这么多，貌似一切都很顺利，但是这样在实践的时候，发现了存在一个明显的问题就是：我们中间的预览区域其实就是为了尽可能模拟移动端页面效果。但是如果我们加入了一些包含类似 position: fixed 样式的组件，会发现样式上就出现了明显的问题。典型的比如Dialog Loading 等。 所以我们参考了 m-ui组件库的设计，将中间预览操作容器展示为一个iframe。将iframe大小调整为375 * 667，模拟 iPhone 6 的手机端。这样就不会存在样式问题了。可是这样又出现了另一个难点，那就是左侧的编辑数据如何及时的反应到iframe中？没错，就是postMessgae，大致思路如下：

 

 

利用 vuex 做数据存储池，所有的变化，通过 postMessgae进行同步，这样我们只用确保数据池中的数据变化，便可以映射到渲染层的变化。比如，我们在预览区进行了组件选择和拖拽排序，那么我们只需通过vuex出发同步信息便可：

  1. // action.ts
  2. const action = {
  3.   setCurrentPage ({commit, state}, page: number) {
  4.       // 更新当前store
  5.       commit('setCurrentPage',page)
  6.       // 对应postMessage
  7.       helper.postMsgToChild({type: 'syncState', value: state})
  8.     },
  9.   // ...
  10. }


Template 模板的实现


模板的设计实现，我参考了 Vue-cli 2.x 版本的思想，把这里的模板，存在了对应的 git 仓库中。当用户需要进行页面构建的时候，直接从 git 仓库中拉取对应的模板即可。当然拉取完，也会缓存一份在本地，以后渲染，直接从本地缓存中读取即可。我们现在把中心放在模板的格式和规范上。模板我们采用什么样的语法无所谓，这里我才用了和 Vue-cli 一样的Handlerbars 引擎。这里直接上我们模板的设计：

  1. <template>
  2.   <div class="pg-index" :style="{backgroundColor: '{{bgColor}}'}">
  3.       <div class="main-container" :style="{
  4.         backgroundColor: '{{bgColor}}',
  5.         backgroundImage: '{{bgImage}}' ? 'url({{bgImage}})' : null,
  6.         backgroundSize: '{{bgSize}}',
  7.         backgroundRepeat: 'no-repeat'
  8.       }">
  9.         {{#components}}
  10.           <div class="cp-module-editor {{className}} {{data.className}}">
  11.             <{{name}} class="temp-component" :data="{{tostring data}}" data-type="{{upcasefirst name}}"></{{name}}>
  12.           </div>
  13.         {{/components}}
  14.       </div>
  15.   </div>
  16. </template>
  17.  
  18. <script>
  19.     {{#noRepeatCpsName}}
  20.   import {{upcasefirst this}} from '{{this}}'
  21.     {{/noRepeatCpsName}}
  22. export default {
  23.   name: '{{upcasefirst repoName}}',
  24.   components: {
  25.     {{#noRepeatCpsName}}
  26.       {{upcasefirst this}},
  27.     {{/noRepeatCpsName}}
  28.   }
  29. }
  30. </script>

为了简化逻辑，我们把模板都设计成流式布局，所有组件一个个堆叠往下顺序排列。这个文件便是我们vue-webpack-simple的模板中的App.vue。我们对其进行了改写。这样在数据填充万，便可以渲染出一个 Vue 单文件。这里我只举着一个例子，我们还可以实现多页模板等等复杂的模板，根据需求拉取不同的模板即可。

Node 渲染服务

当后台提交渲染请求的时候，我们的 node 服务所做的工作主要是：

1. 拉取对应模板

2. 渲染数据

3. 编译

拉取也就是去指定仓库中通过download-git-repo插件进行拉取模板。编译其实也就是通过metalsmith静态模板生成器把模板作为输入，数据作为填充，按照handlebars的语法进行规则渲染。最后产出build构建好的目录。在这一步，我们之前所需的组件，会被渲染进package.json文件。我们来看一下核心代码：

  1. // 这里就像一个管道，以数据入口为生成源，通过renderTemplateFiles编译产出到目标目录
  2. function build(data, temp_dest, source, dest, cb) {
  3.   let metalsmith = Metalsmith(temp_dest)
  4.     .use(renderTemplateFiles(data))
  5.     .source(source)
  6.     .destination(dest)
  7.     .clean(false)
  8.  
  9.   return metalsmith.build((error, files) => {
  10.     if (error) console.log(error);
  11.     let f = Object.keys(files)
  12.       .filter(o => fs.existsSync(path.join(dest, o)))
  13.       .map(o => path.join(dest, o))
  14.     cb(error, f)
  15.   })
  16. }
  17.  
  18.  
  19. function renderTemplateFiles(data) {
  20.   return function (files) {
  21.     Object.keys(files).forEach((fileName) => {
  22.       let file = files[fileName]
  23.       // 渲染方法
  24.       file.contents = Handlebars.compile(file.contents.toString())(data)
  25.     })
  26.   }
  27. }

最后我们得到的是一个 Vue 项目，此时还不能直接跑在浏览器端，这里就涉及到当前发布系统所支持的形式了。怎么说？如果你的公司发布系统需要在线编译，那么你可以把源文件直接上传到git仓库，触发仓库的 WebHook 让发布系统替你发掉这个项目即可。如果你们的发布系统是需要你编译后提交编译文件进行发布的，那么你可以通过 node 命令，进行本地构建，产出 HTML，CSS，JS。直接提交给发布系统即可。 到这里，我们的任务就差不多了~具体的核心实心大多已经阐述清楚，如果实现当中有什么问题和不妥，也欢迎一起探讨交流！！

题外话

实现这样一套页面构建系统，其实我这里简化了很多东西，旨在给大家提供一种思路。另外，其实我们的页面全部在服务端构建的时候产出，我们可以再服务端这一层做很多工作，比如页面的性能优化，因为页面数据我们全部都有，我们也可以做页面的预渲染，骨架屏，ssr，编译时优化等等。而且我们也可以对产出的活动页做数据分析~有很多想象的空间。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/Guff_9hys/article/detail/974224
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号