前端可视化搭建二三事 #26
Comments
可视化搭建的前世今生页面可视化搭建,最早可以追溯很远，耳熟能详的就是Dreamweaver，以及后来基于jquery等前端搭建的项目，随着web开发的发展，前后端分离与数据驱动DOM动态页面，逐渐成为历史。 页面构成我们认为一个页面简单的说是由HTML结构与数据组成静态页面，配合一些逻辑变成为动态页面。（css样式，在这里我们归入Data一类中） 页面组件化
落地页开发痛点活动页面特点前端业务中, 经常需要开发产品介绍页/营销页/活动页/图片展示页等页面. 这类需求有以下几个特点: 常规开发流程流程：
痛点：
高效率的流程
|
关于搭建框架目前一些旧的搭建平台，组件、搭建器、配置项，这三个耦合度非常高，导致后期拓展性很差。举例：当要添加一个例如视频之类的简单组件，如果需要动组件列表、搭建器、配置项这三个地方的代码，则可以断定耦合度非常高了。
在文章页面可视化搭建工具技术要点中提到框架要解耦是最优解，而大部分搭建项目其实确实是服务于业务线，而导致react的落地页，搭建平台也是react语言，如果要实现框架与组件的解耦可行性也是有的，因为我们不管渲染层面是什么语言其实搭建器产生的都是一段段json数据，所以关注点又回到了搭建器的操作台的组件预览，是否需要用搭建器的语言再实现一遍，而且配置区域的数据变化就不能为redux或vuex的语法，从这两点考虑，框架与组件解耦就需要值得商榷了。但是后面随着微前端等前景的发展，未来还是可以完美实现的。 可视化工具结构我们以一个开源的工具为例：
组件列表组件列表中的组件主要分为三类：
关于组件市场的思想如下图： {
"type": "comp-feed",
"version": "0.0.22",
"properties": {
"title": {
"type": "String",
"name": "用户名",
"value": "测试一版"
},
"avator": {
"type": "Image",
"name": "头像显示",
"value": "https://s.gravatar.com/avatar/518515a45a5c15165f559857c3d60a95?size=100&default=retro",
"canDelete": true
}
},
"event": {
"qrShow": 453849
}
}loadResources(docData) {
let head = document.getElementsByTagName("head")[0];
let promiseList = [];
docData.pages.forEach(item => {
(item.children || []).forEach(val => {
// 异步组件
if (val.compType !== 1 && val.type) {
promiseList.push(
new Promise(resolve => {
let tmpSrc =`https://unpkg.com/ ${val.type}${
val.version ? `@${val.version}` : ""
}/dist/js/index.js`;
let script = document.createElement("script");
script.type = "text/javascript";
script.src = tmpSrc;
script.onload = () => {
resolve();
};
head.appendChild(script);
})
);
promiseList.push(
new Promise(resolve => {
let tmpSrc = `https://unpkg.com/ ${val.type}${
val.version ? `@${val.version}` : ""
}/dist/css/index.css`;
let link = document.createElement("link");
link.href = tmpSrc;
link.setAttribute("rel", "stylesheet");
link.setAttribute("type", "text/css");
link.onload = () => {
resolve();
};
head.appendChild(link);
})
)
}
});
});
Promise.all(promiseList).then(() => {
this.pages = docData.pages || [];
});
}操作台/画布这里主要集中以下操作技术：
多是基于组件data中top、left、height、width属性的对数据结构的遍历、计算与揉合，这里不多做赘述。 配置区域整体思路就是配置区域对配置区域读/写，组件对配置数据读取，如下图：
如果为每个组件都编写一个表单页面，工作量较大；对于复杂的配置项，表单页面的编写工作量可能会大于页面组件的开发工作量。我们将配置项的颗粒度细化出来，比如配置项是"Text"，我们就渲染出一个Input框，如果配置项是“Color”，我们则渲染出一个"Colorpicker"，这个思想在JsonEditor和云凤蝶项目中得到体现。
复杂数据类型和简单数据类型嵌套，基本可以满足大部分组件的配置。当然在实际的业务中可能出现一些特殊的要求或者UI设计师设计出特殊的配置项样式，我们可以将这一类归为业务数据类型，比如字体配置：Font，开发者单独开发，由于组件和配置项借助schema.json配置项解耦，独立开发Font的配置即可，配置项可插拔状态，拓展性很好，完全不依赖组件。 实时预览（兼容手机端）现在预览状态兼容手机端展示主要是两种： //fix模块css的left计算
getLeft() {
if (document.body.offsetWidth > 750) {
return this.data.css.left + (document.body.offsetWidth - 750) / 4;
} else {
return this.data.css.left;
}
},
//fix模块计算上or下fix位置
getTopOrBottom(data) {
if (data.properties.fixPos == "top") {
return `${data.css.top / 50}rem`;
} else {
return `${-data.css.top / 50}rem`;
}
}同理在搭建操作台渲染fix类型的组件时，也需要特殊处理。 |
相似项目汇总行业竞品（排名不分先后）
开源系列：
form表单开源系列： |
补充-关于联动{
tmpSelect:{
type:'SelectRadio',
config:{
options:[{
id:'1',
name:'aaa'
},{
id:'2',
name:'bbb'
}]
},
value:'1'
},
form1:{
type: 'Input',
config:{
name:'表单1'
},
value:'表单value值',
dev:{//联动控制
show:{//控制是否展示 也可以为disabled等控制
param1:{//变量
filed:'tmpSelect',
eval:'===',
value:'1'
},
param2:{
filed:'tmpSelect',
eval:'!==',
value:'2'
},
logic:' %{param1}% || %{param2}%' //条件：tmpSelect === 1 || tmpSelect !==2才展示
}
}
}
}如上示例，我们有一个tmpSelect的组件，组件表现形式是SelectRadio，有aaa和bbb两个选项，如果想通过tmpSelect来控制form1是否展示，则给form1添加控制属性dev，dev中有show/disabled等组件状态控制。 |
先说下大前端与前端赋能，这里有一篇winter的文章，里面有一个观点很有趣，就是大前端并不是抢其他工种业务，而是一种赋能，那我们总结下前端赋能的案例，进行理解：
市面上有效赋能的产品或工具：
The text was updated successfully, but these errors were encountered: