页面可视化搭建筑工程具前生现代,前端手艺的
分类:前端技术

页面可视化搭建工具前生今世

2018/05/29 · 基础技术 · 工具

原文出处: CntChen   

图片 1

近年来,前端技术的发展迅速,但因为前端知识面庞大,在实际学习当中往往无法理清其中的脉络。下面从各种库、框架、插件的层面上,对前端知识点做一些简单的梳理。从软件工程上,将前端分为四个由浅及深的层面或阶段。

基于AngularJS前端云组件最佳实践,angularjs最佳实践

AngularJS是google设计和开发的一套前端开发框架,他能帮助开发人员更便捷地进行前端开发。AngularJS是为了克服HTML在构建应用上的不足而设计的,它非常全面且简单易学习,因此AngularJS快速的成为了javascript的主流框架。

一、Amazing的Angular

AnguarJS的特性

方便的REST: RESTful逐渐成为了一种标准的服务器和客户端沟通的方式。你只需使用一行javascript代码,就可以快速的从服务器端得到数据。AugularJS将这些变成了JS对象,作为Model,遵循MVVM(modelview view-model)设计模式。

MVVM救星:Model将和ViewModel互动(通过$scope对象),并监听Model的变化。可以通过View来发送和渲染,由HTML来展示代码。View可以通过$routeProvider对象来支配,所以你可以深度的链接和组织你的View和Controller,将他们变成导航URL。AngualrJS同时提供了无状态的Controller,可以用来初始化和控制$scope对象。

数据绑定和依赖注入:在MVVM设计模式中的任何东西无论发生任何事情都自动的和UI通信。这帮助我们去除了wrapper,getter/setter方法或者class定义。AngularJS将帮助我们处理所有的这些内容,你可以处理数据像处理基本javascript数据类型般。当然你也可以通过自定义处理复杂数据。正因为所有事情的发生都是自动的,所以你不必调用一个main()来执行你的代码,而是通过依赖关系来驱动。

可扩展的HTML:大多数网站都是使用非语义的<div>标签来搭建的。你需要自己在CSS的class中定义相关的DOM层次结构。而使用AngularJS,你可以像操作XML一样操作HTML,有无穷的方式来完成标签和属性定义。AngularJS通过自己的编译器和directives来完成相关的设置,而这也是组件实现的基石。

大家接触jQuery的时候发现,要做事先绑定,取回数据要塞回去,塞的过程都是要自己关心的。但是利用Angular,数据取回来只要注入变量自动完成了,包括事件绑定。数据绑定,MVVM、依赖注入让你觉得,原先要关心很多东西,现在都不需要关心了,只需更加关心数据结构和业务层,它把我们从繁琐DOM绑定中解脱出来。

二、组件化之路

组件是对数据和方法的简单封装,在此样式类,指令型等具备UI效果的组件,方法等统称组件。在大型软件中,组件化是一种共识,它一方面提高了开发效率,另一方面降低了维护成本。

组件化及组件展现形式

组件化可以有很多事情可以做,比如模板化,现在模板化重任交到前端。第二个是公共样式库,第三公共函数库,一些业务组件,模块化特殊一点。

组件大概展现形式包括: 统一的样式库,具有一定HTML结构的代码片段,具有一部分JS控制的功能函数,具有一定数据输入和输出的控制。

三、揭开云组件的面纱

云以及云组件概念

云是网络和互联网的一种比喻说法。过去往往用云来表示电信网,后来也用来抽象地表示互联网和底层基础设施。

云服务指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关,也可是其他服务。它意味着计算能力也可作为一种商品通过互联网进行流通。把云和组件二者结合则构成了云组件。说到底是希望通过一个统一的控制的东西,把N个项目全部控制在一起。

个推的组件类型

个推的组件类型包括样式类组件、指令型组件、服务型组件、公共过滤器、公共函数库等。

图片 2

从组件分类里可以发现专属CSS是样式类组件,加上模板就是非常简单的组件,再把加控制器放进去,就是前面讲的具有一定JS和一定逻辑的组件,把link加进去,带了动画,数据层加进去就具备一定的输入输出能力。这个数据层可能包含多种,有可能是跟你的页面控制器交互,也有可能这个组件非常强,自己直接与服务端通信获取数据和传递数据(当然实际实践中可能前者更合适当前我们的环境,后者对统一的接口要求会更高)。

图片 3

上图是个推云组件的技术方案。基于前端三大件和一些其他库比如地理围栏的组件(需要让百度地图给我们整个项目对接起来),还有可视化的项目,比如G20期间杭州某景区人流情况,可视化项目会用到第三方库。个推利用LESS写CSS,基于这些开发云组件。

根据云组件的一些情况个推得出它的最佳实践对象就是从具有一定通用交互的表格表单类的管理型系统出发,逐渐包含复杂交互的系统应用,并对响应式具有一定的支持。个推是从做推送服务开始,之后有很多产品线。推送服务就会有很多2B、2C的平台,这就是管理型的。

图片 4

图片 5

上图是个推云组件采用的目录结构,用的是gulp打包,CSS里面有wd文件夹,主要放了一些第三方的库。更关键主要还是下面,JS也是一样,wd是基础库。第五个是最重要的,所有组件都放在这个文件夹下,每个组件包含自己专属的三大件——模板、逻辑、交互、效果和样式。

基于gulp的打包

图片 6

云组件展示站点

云组件的使用人员主要分为三大类,第一类是前端使用者(包括泛前端人员),他们需要学习如何使用,快速用组件(须知道Angular的一些基本概念和用法)。第二类是UI设计师、项目和产品等,他们需要观察效果是否是适合的,根据库去设计新的此类系统。第三类是游客和其他人员。

关于云组件的新的思考

云组件牵一发会动全身,如果云组件机制运用不好比如一个老的组件更新出了个bug,会产生很多负面影响,这时该怎么办?

回到云的初始之处我们不难发现,当资源隔绝便不会产生这种影响了(云组件正是利用其反向思维达到的便捷),那么我们相对将云组件资源封闭便可以降低这个影响了。这便是版本控制,不同项目引用相应的云,以达到刚才讲的两者之间的平衡,从而成效最优化。

所以,只有合理控制住才能真正发挥云组件的优势。

多个版本下,我们的开发模式便是就某个项目的云组件升级由该项目决定。因为如果云组件一发版,所有的项目都升级云组件那这个回测的代价就很高了,况且原有的云组件版本也是够之前已经上线的项目的当前版本用了。

个推的项目体系图

图片 7

实际使用中的问题

云组件的发版有一定的周期性,但实际项目中的需求要快速响应,这时需要采用云组件扩展模块(模式)开发:基于云组件开发本项目的组件级别的模块,对云组件进行扩展或者项目化定制。

四、关于AngularJS的经验与总结

第一、模块化:随时准备模块化抽象,这是一个动态的过程。

第二、多想想周边的,超过所止的部分 —— 换位思考,方便下游,倒推上游。

第三、没有实现不了的效果,只有承受不了的代价。

第四、方法有很多,时间允许的话都可以试试。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持帮客之家。

AngularJS是google设计和开发的一套前端开发框架,他能帮助开发人员更便捷地进行前端开发...

背景

规模化的组织,经常要面临这样的挑战:每个应用的基础设施是相同的,部分的代码也是相同的,甚至于它们可能只是数据模型不同而已。结果却导致了,他/她们要一次又一次地重新编写一个应用。对于一个新的应用而言,它需要对接大量的三方服务。服务之间的不断变化 ,导致了对应的使用方也需要发生变化。不断变化的业务,导致了前台的设计不断变化。为了应对快速谈的的前台服务,后台便诞生了中台,以提供快速的响应能力。而随着中台进一步沉淀,从某种形式上趋于稳定,而前台仍然需要快速地响应能力。

 

引子

页面可视化搭建, 是一个历久弥新的话题. 更广义上讲, 页面是 GUI 的一部分, GUI 的拖拉生成在各种开发工具上很常见, 如 Android Studio, Xcode, Visual Studio 等. 前端页面早在十几年前就能用 Dreamweaver, Frontpage 等工具可视化搭建出来.

Dreamweaver 操作页面示例:

图片 8

但是现在已经很少人使用 Dreamweaver 了, 其主要原因是页面承载的内容已经和页面源码分离, 由后端接口返回再渲染到页面, 静态页面网站无法承载大量的动态内容.

Dreamweaver 死了, 但是页面可视化搭建工具依然广泛需要和使用, 所以这个话题依然值得探讨.

于是乎,作为一个前端开发人员,我们不断提炼和复用代码,想着的模式在之前的文章已提到了:

一、基础层(浏览器原生支持html/css/js

文章内容

  • 页面构成和页面组件化.
  • 页面可视化搭建工具的必要性.
  • 页面可视化搭建工具的区分维度.
  • 业界的实践实例.

脚手架

  • HTML超文本标记语言,用标签构建网页的内容。HTML5扩展了标签及其功能。
  • CSS层叠样式表,控制页面内容的表现。CSS3增加了更多的特效,比如文本效果和2D/3D转换,以及动画。
  • JavaScript的原生API(包括DOM、BOM、Style样式、Canvas、SVG、WebGL等)

页面

组件库

有了这些以后,我们已经可以开发基本的网络应用了,但是会发现它们并不好用,或者说存在一些缺陷,有优化的余地。

页面是 HTML / DOM

页面可视化搭建的操作对象是页面. 页面是一份 HTML 文档, 不管是静态页面还是动态渲染出来的页面, 在页面上看到的内容, 都是 HTML 文档的一部分.

对 HTML 文档的实例化和操作, 通过文档对象模型(DOM)来实现, 也可以说页面是一个 DOM. 本文没有严格区分 HTML 和 DOM 这两个概念, 以下行文都用 HTML 这个概念.

HTML 使用一种树形结构来表示页面, 树的每个节点为一个页面元素或文本节点, 一个页面元素可以包含多个页面元素节点或文本节点. 页面元素通常称为标签, 页面元素类型由 HTML 规范定义.

HTML 结构示例:

图片 9

模式库

  • 当前后端分离后,通过API获取到的数据,需要填充到页面中,原生DOM操作非常消耗性能,且传统JS使用字符串拼接的方式不太好用
  • CSS不能像其他程序语言一样,通过变量、计算、继承等方式很好的管理。
  • JS原生API不好用,还存在浏览器兼容等问题。

页面是 HTML Tree   Data

从前端开发的角度, 可以认为页面是由 HTML Tree 和 Data 组成, HTML Tree 是页面元素的树形结构, Data 是页面元素的属性或文本节点. 下图中蓝色框所示的节点可以认为是数据.

图片 10

为什么从前端开发角度会说页面是 HTML Tree   Data? 举一个常见场景来说明: 在开发新页面时, 我们是可以复制已有页面(好吧, 我就是这样的前端工程师), 然后只修改页面 HTML, 或者只修改数据, 或同时修改 HTML 和数据, 从而完成新页面的开发.

模板和模板应用

  这些问题,前端开发者通过多年的填坑,花费巨大的精力封装了各种框架层,用来减少开发工作量。

静态页面和动态逻辑页面

上一节说页面的由 HTML Tree 和 Data 组成, 讨论的是静态页面.

图片 11

浏览器请求静态页面, 网络返回的 HTML 源码就是页面渲染完成后的 HTML. 静态页面的源码和页面渲染结果一致:

图片 12

当下, 前端页面更多的是有动态逻辑的页面, 在页面中引入和使用动态脚本(Javascript)对页面进行修改和控制.

图片 13

浏览器请求动态逻辑页面, 网络返回的 HTML 源码与页面渲染完成后的 HTML 有差异. 动态逻辑页面的源码和渲染结果有差异:

图片 14

对应的,我们还创建了一系列的 CLI、工具集、编程器插件以及设计系统,以完成整个系统的快速开发。然而,我们还缺少一套有效的工具,来统一化的管理这些工具。

 

页面组件化

页面渲染后是一棵 HTML 元素构成的树, 页面的可编辑粒度为 HTML 规范定义的 HTML 元素.
使用 Web Components 组合 HTML 元素, 实现了功能封装和可复用的页面组件. 在流行的前端框架中, 都提供了组件化的功能, 从前端框架的视角看, 页面是由组件树组成. 这些组件内部维护自身的 HTML 元素结构、样式和功能逻辑, 并通过组件的 props 获取外部传入的数据, 实现了功能封装和复用.

Vue 组件树示例:

图片 15

换句话来说,就是:我们需要一个前端的中台,它便是无代码/低代码编程。

二、框架层(各类前端库)

并没有讨论 CSS

在以上的章节中, 我们并没有讨论决定页面样式的 CSS. 因为借助 Javascript 的动态逻辑, CSS 可以归入到 Data 的范围: 通过对页面元素 style attribute 的修改, 或将 CSS 属性动态添加到<style>标签中,可以实现对页面元素样式的修改。

无代码/低代码是一种创建应用的方法,它可以让开发人员使用最少的编码知识,来快速开发应用程序。它可以在图形界面中,使用可视化建模的方式,来组装和配置应用程序。开发人员可以直接跳过所有的基础架构,只关注于使用代码来实现业务逻辑。

JQuery、YUI、Zepto、以及针对H5中canvas的游戏库Lufylegend等等,主要为了解决浏览器原生API不好用和兼容问题,即对原型API做了二次封装,使其更易于开发和掌握,本质上等于依靠框架层间接操作原生浏览器的基础API。在此基础上,又针对一些常用的页面组件,扩展了为插件,即组件或插件层。

页面可视化搭建

有了对页面组成的认知基础,可以对页面可视化搭建有更多的讨论: 页面可视化搭建是什么? 为什么需要?

当然,从开发人员的角度来看,降低代码量,可能是:

 

是什么

如前文所阐述, 动态逻辑页面分解为 HTML TreeData 和 Dynamic Logic. 前端开发工程师开发前端页面的过程, 本质上是用编程工具(IDE)对页面的 HTML TreeData 和 Dynamic Logic 进行增删和修改.

页面可视化搭建, 是用可视化交互的方式对页面的 HTML TreeData 和 Dynamic Logic 进行增删和修改, 从而实现页面的生成. 页面可视化搭建工具是实现页面可视化编辑的软件工具.

用页面可视化搭建工具来搭建页面与前端工程师在页面上搬砖, 都是搭建页面, 区别在于实现页面搭建的方式. 做个简单对比:

差异点 编程开发页面 可视化搭建页面
技能要求 需要编程基础 可以没有编程基础
操作方式 在代码编辑器中编写代码 在可视化搭建工具中拖拉/填表/编写代码

框架本身处理了复杂性。毕竟 “复杂度同力一样不会消失,也不会凭空产生,它总是从一个物体转移到另一个物体或一种形式转为另一种形式。”

三、组件层(或插件)

为什么需要

任何工具的存在都是更高效地解决问题. 页面可视化搭建工具, 用于解决页面生成的效率问题.
可能前端工程师会觉得最有效率的页面生成方式是打代码, 但有搭建页面需求的不只是前端工程师. 而可视化页面搭建工具, 恰恰是面向”就缺一个前端工程师”的人员, 用于提升他们生成页面的效率.
我们可以从一些使用场景来窥探页面可视化搭建工具的应用场合.

代码生成减少了工作量。大量的复制、粘贴需要更多的时间。

常用的如:日历选择器、富文本编辑器、图片轮播等等。这些仅仅是对WEB应用中,比较常用或通用的部分进行了再次封装。除此之外,那些平台特有的业务逻辑属于应用层。

页面小白做 H5

页面小白不需要任何页面相关的知识, 不需要了解 HTML/JS/CSS 这些概念, 只要像使用 Word 一样在 H5 制作工具上操作, 就可以做出一个挺漂亮的页面. H5 制作工具很多, 其中 百度H5 做很好不错.

如: 小陈女票要生日了, 小陈为女票做了一个有创意的生日祝福页面:

图片 16

流程

 

营销活动页面搭建

大多数互联网公司需要做许多的活动页面来承载运营业务. 运营活动页面的特点是: 页面功能大同小异、需求急、时间紧、下线快、研发性很比低. 前端工程师无法持续开发无穷无尽的活动页面, 需要采用活动页面可视化搭建工具, 由运营人员/产品人员直接生成活动页面. 研发人员的工作转变为提供满足活动页面业务需要的活动模板.

如: 抽奖活动页面的可视化搭建:

图片 17

只是凭借这个概念,我们是无法理解无代码编程的。于是,我画了一张图来展示相应的架构和流程:

四、应用层(业务层)

中后台系统开发

在公司内部, 需要做许多的中后台支持系统, 这些系统的管理端一般用 web 页面承载. 那么问题来了, 中后台系统的前端工程, 怎么保障可用性、可维护性和页面呈现一致性? 这些系统与后台逻辑强关联, 一般由后台开发人员开发; 后台开发人员写代码逻辑是没有问题的, 但是其前端开发能力相对较弱. 所以需要增强他们开发前端页面的能力, 前端开发能力由前端服务化提供.

前端服务化的第一种方式是提供一套组件库, 如 饿了么的 Element.
组件库一般由前端开发人员封装成模板工程, 模板工程提供公共样式和函数库, 并对编写的代码做校验和约束, 一定程度上降低了前端开发难度, 统一后台人员代码风格. 此时后台开发人员的开发方式为: 在代码中用组件拼凑页面, 然后写代码逻辑.

前端服务化的第二种方式, 是提供页面可视化组装系统, 这个系统输出组装后的前端工程源码. 这样的系统比提供组件库和模板工程的方式走得更远: 通过可视化生成模板工程, 后台开发人员不需要在代码中拼凑前端页面, 不需要关注前端组件, 只需要编写代码逻辑.
这种方式可以参考阿里的 ice.

阿里 ice 示例:

图片 18

前端服务化的终极方式, 是直接提供一个开发的 IDE, 将动态逻辑的书写也在 IDE 中完成.
如 美团外卖前端可视化界面组装平台 —— 乐高, 前端服务化——页面搭建工具的死与生.

美团乐高示例:

图片 19

图片 20

如购物车,权限管理等等,应用层的业务逻辑通常随WEB应用的场景有关。

前端服务化

更加广泛来说, 为页面小白/运营人员/产品人员提供的页面可视化生成工具, 也是赋予以上人员前端开发的能力. 所以页面可视化搭建, 本质上是前端服务化的一部分. 前端服务化总结, 可以看百度的 前端即服务-通向零成本开发之路.

低代码编程流

 

页面可视化搭建工具区分维度

有了前文对页面的基础认知, 终于进入了本文的正题 — 页面可视化搭建工具.
前面已经零星讨论过页面可视化搭建工具的定义, 再总结一下: 页面可视化搭建, 是指用可视化交互的方式(对比编写代码的方式), 实现页面的修改或生成; 页面可视化搭建工具, 增强了使用者的前端开发能力, 提升了使用者修改或生成页面的效率.

思考一个更具体的问题: 当我们讨论页面可视化搭建工具时, 怎么进行描述和讨论? 换个角度提问题: 可以从什么维度对页面可视化搭建工具进行描述和区分?

页面可视化搭建工具的区分维度包括:

  • 系统功能
  • 面向客群
  • 编辑自由度

下文会对页面可视化搭建工具的区分维度做介绍, 并会对每个区分维度提供示例(这些示例不会展开讨论, 且在不同维度下会多次使用同个示例).

依照我的观点来看,我将无代码编程分为了两部分:

  如上只是传统的开发模式,随着前后端的分离,前端开发分担了越来越多业务逻辑。通过HTTPrequest与后台交互数据,然后通过拼接字符串的方式,生成浏览器识别的DOM结构与样式。这些都让前端开发越来越重,但js本身不能很好的实现模块化管理,所以出现了require、sea等AMD和CMD的模块加载框架。

系统功能

页面可视化搭建工具的系统功能是指该工具在解决特定页面可视化搭建问题上提供的核心能力.
页面是由HTML TreeData 和 Dynamic Logic 三部分组成, 一个页面可视化搭建工具提供的能力是编辑页面组成部分之一或多部分. 对基于组件的页面, 其可编辑单元为组件, 此时采用 Component Tree 概念取代 HTML Tree.

图片 21

用于构建 UI 的编辑器——一种在线的拖拽式 UI 设计和页面构建工具

 

HTML Tree 编辑

这类页面搭建工具专注于可视化地编辑页面 HTML Tree 部分, 一般可以对页面做自由度较高的编辑.
其关键功能在于高自由度: 几乎可以编辑页面可见的所有元素, 能自由修改页面结构、页面元素样式和页面数据, 采用类似 Word, Photoshop 的可视化编辑方式.
这类工具一般只适用于生成逻辑比较简单的页面, 其中原因后续会讲.
常说的 H5 制作工具就是指这类工具.

如: 百度H5、iH5

用于编写业务逻辑的流编辑器——通过流编程的方式来编写业务代码(多数是对于数据的处理)

前端的革命

Node的出现,让前端领域发生了巨大的改变,前端开发者终于可以自己开发工具了(如同猿人学会了制造工具,前端脱离了刀耕火种的年代)。随着自动化工具glup、webpack的火热,多种多样的预编译程序(如HTML模板引擎jade、Ejs等,CSS预处理器Sass、Less等),以及前端MVC、MVVM框架angular、react、vue等如雨后春笋般蜂拥出现,前端开发进入一次全面封装的时代,组件化开发模式在一定程度上,利用JS的可编程性管理html和css,最后通过编译,再生成浏览器识别的HTML/CSS/JS。

  

  移动端的出现,在一定程度上,也对前端技术提出了更高的要求,基于移动端的网络环境,需要用更少的资源实现最大化的效果。

  

  最后小程序的推出,进一步拓展了前端开发的应用领域,将应用程序存储到云端的嵌入式开发,或许是未来应用的新方向。

Component Tree 编辑

这类页面搭建工具针对组件化的页面, 主要实现 Component Tree 的可视化编辑. 其核心功能在于页面布局设计: 在 UI 组件列表中选择合适的组件, 通过拖拉的方式将组件嵌入到页面中, 生成带布局和样式的页面.

如: ice 阿里飞冰、vue-layout

vue-layout 示例:

图片 22

UI 编程器

页面 Data 编辑

这类页面搭建工具专注于可视化地编辑页面的 Data 部分, 如图片URL、按钮文本、按钮跳转链接等.
这类搭建工具主要针对 HTML Tree 比较固定、能承载复杂业务逻辑的页面. HTML Tree 固定的常见方式是页面组件化, 只需修改页面组件的 Data 就能快速地生成页面.
其核心功能在于快速搭建承载业务逻辑的页面.
通常营销活动页面就采用这种方式来可视化搭建.

如: 阿里云凤蝶、开源的 pipeline

阿里云凤蝶示例:

图片 23

为了设计出我们的 UI 构建器,我们需要准备好一系列的基础设施:

Dynamic Logic 编辑

这类页面搭建工具支持在界面上输入逻辑代码, 实现页面 Dynamic Logic 编辑, 如后台接口请求逻辑, 业务判断逻辑等.
这些逻辑代码需要有合适的插入点, 一般在事件钩子中提供插入点, 如页面 onload、网络请求状态变更、按钮事件、数据变更等.
做到可以支持编辑 Dynamic Logic 是超牛逼的事情, 这类工具对页面的理解最深入, 对开发者的技术能力、前端架构能力和开发能力都要求很高.

如: 前端服务化——页面搭建工具的死与生

UI 编程器。用于拖拽式设计 UI。

系统功能组合

还有其他系统功能的组合, 可以综合上面的典型类别来做讨论.

空白脚手架。一个带有完整的应用生命周期的项目,但是它是一个空白的项目——用于我们在构建 UI 的过程中,随时随地的添加组件和代码。

面向客群

页面可视化搭建工具的面向客群是指工具的使用客群. 不同的使用客群, 其对页面技术的认知程度、搭建页面的诉求有所不同, 所以可以从工具的面向客群来区分不同工具.

图片 24

设计系统。我们需要一个完整的组件库,大量的页面模板,以及一定数量的模板应用,减少相应的开发工具量。

前端小白

前端小白是不具有前端知识的人群, 他们对页面可视化搭建工具的诉求是交互性越高越好. 最适合他们的工具是像 Word, Powerpoint, Photoshop 等具有丰富交互功能, 且所见即所得的页面搭建工具.
同时他们也不关心页面最后用什么方式托管到互联网上, 页面编辑完成后要帮他们在公网上托管页面, 并提供页面链接, 方便前端小白将页面发给自己的女朋友.

如页面界的 Photoshop:

图片 25

https://www.ih5.cn

代码片段集。它将设计系统中的组件库进一步实例化成代码段,在完成编辑后通过 CLI 来动态编辑代码。

运营/产品

运营、产品人员没有开发人员页面开发、逻辑编程的能力, 他们的诉求是可以快速搭建活动、产品页面. 活动、产品页面是承载着业务逻辑的: 如包含领取优惠券功能、背景音乐播放功能、产品购买功能等. 运营、产品对页面可视化搭建的另一个诉求是“快速”: 一天好几个活动, 怎么快怎么来.
面向运营、产品的可视化搭建工具, 需要将页面的逻辑功能封装在页面区块内, 支持通过点击来选择区块, 然后在表单中编辑区块所需数据, 只对页面进行少量编辑就完成业务页面搭建.
如领取优惠券的页面, 运营、产品只要在表单中填入优惠券的 ID, 然后就快速生成领取该优惠券的页面, 不需要关心优惠券在页面上如何展示和被领取的具体逻辑.

如, 开源项目 pipeline:

图片 26

DSL(领域特定语言,可选)。中间生成物,用于隔离框架与设计。

中后台开发人员

中后台开发人员具有逻辑编程能力, 但其前端开发能力比较弱. 中后台开发人员的诉求是, 在开发中后台系统的 Web 管理端时, 不需要进行重度的前端页面结构和样式开发, 可以专注在逻辑和数据处理上.
这要求页面可视化搭建工具提供页面搭建的区块, 对区块进行可视化组合来输出一个基本的前端页面; 并在页面搭建工具上提供业务逻辑编写的输入点, 或将基本前端页面源码导出到 IDE 中供中后台开发人员进行业务逻辑的开发.

如: ice 阿里飞冰

流编程器

前端工程师

要啥页面可视化搭建工具, 抓起键盘就开始干.

图片 27

流编程器。用于拖拽式、输入编写业务代码。

编辑自由度

页面可视化搭建工具的编辑自由度, 是指页面可编辑单元的粒度. 前端页面的可编辑单元为 HTML 元素; 从前端页面组件化的角度, 页面可编辑单元为组件.
不同的编辑自由度的选择, 是可视化搭建工具在不同业务场景下编辑自由度与编辑效率的平衡.

图片 28

编辑自由度为 HTML 元素(左)与自由度为组件(右)的示例:

图片 29

后端服务。如果不能提供现成的后端服务,则需要拥有一个标准的 API 规范,以及相应的 mock server。

编辑自由度为 HTML 元素

编辑自由度为 HTML 元素的页面搭建工具有以下特点: 可编辑的元素丰富、页面结构灵活、可视化编辑效率较低、业务逻辑封装度较低.
这类工具的可编辑单元为 HTML 元素, 可以编辑元素的文本、样式和行为, 可编辑的元素较丰富; 并且可以组合各种 HTML 元素到页面中, 生成的页面结构灵活; 从生成页面的角度, 编辑出一个页面需要从基本的 HTML 元素开始搭建, 可视化编辑的工作量较大; 一个业务功能的实现, 通常需要渲染多个 HTML 元素, 而这类工具可以自由增删业务所需的 HTML 元素, 这导致无法固定地承载业务功能, 所以这类编辑工具生成的页面, 业务逻辑封装程度较低.

如: iH5、vvveb

vvveb 示例:
图片 30

模式库。包含相应的业务处理代码,如通用的登录、数据获取、UI 交互等。

编辑自由度为前端框架组件

编辑自由度为前端框架组件的页面搭建工具有以下特点: 可编辑的元素依赖搭建工具提供的组件, 可视化编辑效率较高、业务逻辑封装度较高.
这类工具的可编辑单元为前端框架的组件, 这些组件需要开发并导入到页面可视化搭建工具中; 组件的渲染结果包含了多个 HTML 元素, 所以从生成页面的角度, 编辑出一个页面只需要组合组件, 可以较快速完成页面生成; 组件本身承载了特定的业务功能, 所以这类编辑器生成的页面, 业务逻辑封装程度较高.
对于嵌套的组件, 需要重点解决组件数据流和组件布局适配.

如: Vue-Layout

vue-layout 示例:

图片 31

DSL(领域特定语言,可选)。同上

不嵌套的前端框架组件

移动端的页面, 常用的布局策略是: 宽度铺满, 高度滚动. 如果前端框架组件都设置为铺满宽度, 页面展示时组件只需在浏览器垂直方向上顺序排列, 则组件组合时候不需要嵌套, 所有组件互为兄弟节点. 这种铺满宽度的组件, 非常适合搭建移动端页面的场景: 在承载页面逻辑的同时, 使得页面的编辑更加简单, 使用者只需要处理组件的顺序, 不需要处理组件的嵌套.

如: 阿里云凤蝶、pipeline

pipeline 示例:
图片 32

当然了,我们还需要能实时预览构建出来的应用。随后,我们执行了构建,而后构建出了一个半成品应用。开发人员只需要在它的基础上开发应用即可。而在开发人员开发的过程中,我们可以设计一系列的工具,来帮助开发人员更快速地构建应用。

理想的页面可视化搭建框架

页面可视化搭建工具, 需要对页面做一些约定和约束, 在可视化搭建时遵循工具约定和约束来编辑页面. 更全面讨论页面可视化搭建工具时, 不只是关注工具本身的功能, 还需要关注工具的依赖和约束, 如页面可视化搭建工具的组件化方式、模板组织方式、编辑功能实现方式等. 从工具开发的角度说, 页面可视化搭建工具是需要架构设计的, 不同工具的区分, 其实是不同的页面可视化搭建框架间的差异.

在互联网公司中, 广泛运用页面可视化搭建工具来支持运营活动页面的生成, 本章我们只探讨运营页面搭建工具的理想框架.

页面可视化搭建框架的核心是实现页面的可视化编辑. 运营页面搭建工具, 声明页面配置数据并提供配置表单, 通过对配置表单的数据填充, 实现基于模板的页面生成. 如图所示:

图片 33

编辑器插件。包含设计系统、模式库等的自动完成代码,以及组织内部常用的代码库。

可视化编辑

调试工具。对于混合类型的应用而言,我们还需要一个开发工具来快速构建应用。

配置数据

对页面的可编辑部分, 需要准确描述可编辑部分所需的配置数据; 配置数据是异构的, 不同页面、不同区块的配置数据各不相同. 所以需要对不同页面、不同区块定义各自配置数据的数据结构和字段类型.
理想的配置数据格式为 JSON, 因为其格式灵活, 前端友好; 理想的配置数据描述格式为 JSON Schema, 因为其支持表单动态生成和数据校验.

从上述的流程上来看,无代码编程还具有以下的特点

配置表单生成

采用 JSON Schema, 容易生成配置表单, 只要按照 JSON Schema 对 JSON 数据的描述, 可以动态渲染出配置表单. 并且可以采用 JSON Schema 对编辑后的数据做格式校验, 避免编辑错误.

如配置表单自动生成工具 json-editor:

图片 34

拖放式界面。又或者是可视化模型——基于节点和箭头。

组件化

组件是对 HTML 元素、元素布局和样式、业务逻辑的封装, 通过组件化的方式, 将页面的搭建转化为对组件的组合, 大大减低了运营页面生成的编辑工作量, 实现快速搭建承载业务逻辑的运营页面.

如 pipeline 的页面组件化:

图片 35

基于视觉的设计

模板

模板是带有默认数据的页面; 对于组件化的页面, 模板是从组件库中选取部分组件, 并带有各个组件的默认数据.
采用模板生成页面, 只需对模板进行少量编辑即可实现页面快速生成.

可扩展的设计。如对于插件、插件商店,社区等一系列的支持。

与编辑系统解偶

编辑系统和组件解偶,组件只需要遵循编辑系统的组织约定, 其具体开发过程和承载的逻辑与编辑系统无关, 支持自由拓展页面组件.
编辑系统与模板采用的前端框架解偶, 在遵循编辑系统约定下, 可以选择不同的前端框架.

跨平台功能。支持 PC Web 应用开发,支持移动应用构架等。

理想的运营页面可视化搭建框架

  • 采用 JSON Schema 声明配置数据, 配置表单自动生成.
  • 采用组件化和页面模板实现页面生成效率的提升.
  • 编辑系统与组件、前端框架、模板解耦.
  • 在遵循编辑系统约定下, 组件可以自由拓展, 前端框架可以自由选择.

强大的部署后。即平台包含着整个应用的生命周期。

页面可视化搭建工具举例

列举一些页面可视化搭工具, 并附带少量点评.

拥有丰富的集成支持。可以随意的找到需要的组件,以及对应的后台服务。

阿里云凤蝶

移动建站平台

  • 支持页面 Data 编辑, 面向运营、产品人员, 编辑自由度为无嵌套的组件.
  • 目前制作运营、活动页面功能上最好的工具.
  • 提供页面搭建的模板, 并支持自定义模板.
  • 配置表单基于 Schema 生成, 配置表单操作功能完善.

配置化。它也意味着大量的自定义配置。

ice 阿里飞冰

飞冰 – 让前端开发简单而友好

  • 支持 Component Tree 编辑, 面向中后台开发人员, 编辑自由度为无嵌套的组件.
  • 使用”物料-区块”, 非前端开发人员可以快速搭建出可用、符合规范的页面.
  • 页面以源码方式输出.
  • 前端服务化的一种方式.

自制的领域特定语言。用于构建时优化。

百度H5

创意,绝不雷同

  • 支持 HTML Tree 编辑, 面向前端小白, 编辑自由度为 HTML 元素.
  • 做 H5 的好工具, 功能上很强大, 对动画的编辑功能做到细致.

优缺点

美团外卖前端可视化界面组装平台 —— 乐高

  • 支持 Dynamic Logic 编辑, 面向中后台开发人员, 编辑自由度为可嵌套的组件.
  • 前端服务化的一种方式.
  • 在美团内部支持了许多业务页面, 没有公网服务, 了解该系统只能通过其介绍文章.

相应的,它具有以下的一些优点:

esview

Drag vue dynamic components to build your page,generate vue code.

开源项目, 模仿美团点评的乐高.

  • 完整的可视化页面搭建框架, 面向中后台开发人员.
  • 页面布局结果看起来比较乱, 自定义组件写法比较诡异; 没有融合业务逻辑, 不支持在框架中写页面的代码逻辑.

高效。不用多说,节省时间和开发成本。

gaea-editor

Design websites in your browser

开源项目.

  • 支持 Component Tree 编辑, 面向中后台开发人员, 编辑自由度为可嵌套的组件.
  • 页面的拖拉生成, 实现得很完整.
  • 用于页面设计, 所以偏向页面元素的样式控制.
  • 技术文章对可视化搭建工具数据流有深刻理解: 可视化在线编辑器架构设计.

有限的 Bug,安全性。

Vue-Layout

基于UI组件的Vue可视化布局、生成.vue代码的工具。

开源项目.

  • 支持 Component Tree 编辑, 面向中后台开发人员, 编辑自由度为可嵌套的组件.
  • 工具的使用体验效果不错.

低成本。其所需的预算非常有限。

gen

根据接口生成页面,减少重复性工作

  • 开源项目, 用起来感觉不错.
  • 系统中有好几个概念, 开始比较难上手.

易用。

其他

  • 请使用关键字 website-builder, site-builder 等关键字进行搜索.
  • VvvebJs
  • grapesjs
  • Maha
  • 有赞微页面
  • X-Page-Editor-Vue

开发速度更快。

业界实践

列举一些业界在页面可视化搭工具上的实践, 并附带少量点评.

开发过程中的 AI 。

前端服务化——页面搭建工具的死与生

  • 支持 Dynamic Logic 的页面可视化搭建 IDE.
  • 讲解了页面可视化搭建框架支持 Dynamic Logic 的可行性和设计架构.
  • 作者在前端框架和 IDE 方面写了好几篇文章, 很深刻.

维护成本低。

腾讯IMWeb: 积木系统,将运营系统做到极致

2015年的文章! 完全说到点上.

  • 简单易用的、可视化的可编辑页面.
  • 通用的、简便地组件接入机制.
  • 组件: 开发过程和系统无关, 逻辑和系统无关.

对应的相应的缺点有:

美团外卖前端可视化界面组装平台 —— 乐高

  • 把系统架构将得很清楚, 有借鉴意义.
  • 对页面组成做了分析, 阐述了可视化配置的原理.

仍然需要编程技能。

前端即服务-通向零成本开发之路

百度的前端服务化实践, 都在这一篇.

受限的自定义能力。

可视化在线编辑器架构设计

  • 可视化在线编辑器属于前端开发引擎, 前端进入了前端工业时代.
  • 深入讨论了组件数据流.

可扩展性成了新的问题。

百度外卖如何做到前端开发配置化

  • PPT 将原理和架构讲得很清楚.
  • 使用流程图很清晰.
  • 项目开源了 — block, 试用起来功能比较简陋.

集成受限。

转转运营活动高效开发有哪些秘诀

基于组件的页面生成系统-魔方, 采用 npm 管理组件.

就当前而言,低代码开发平台通常分为两大类:

QQ会员: 如何保证H5页面高质量低成本快速生成

内部 ET 平台, 包含活动管理的其他功能.

对于外部:制作简单的产品,如网络移动应用程序

vue-design 桌面端页面可视化构建程序

对于内部:为您的团队或企业创建业务应用程序

esview — 这可能是目前最好的vue代码生成工具

诸如只使用 CRUD、表单、验证、简单聚合、分页等简易的服务。最常见的例子就是表单构建了,诸如金数据这样的应用,便是可以直接通过拖拽元素来生成,相应的开源实现有 jQuery Form Builder。

总结

  • 页面由 HTML TreeDataDynamic Login 组成.
  • 页面可视化搭建工具用于提升各类人员的页面搭建效率.
  • 页面可视化搭建其实是前端服务化的方式.
  • 页面可视化搭建工具需要平衡自由度和效率.
  • 组件和模板是页面可视化搭建框架的核心.

全文结束, 本文对页面可视化搭建思考和讨论可能还不够完整, 欢迎讨论和补充.

后记: 终于写完了, 历时估计一个月! 写这篇文章的初衷是给我造的页面可视化搭建框架 — pipeline 写背景, 但思考的点比较多, 所以就独立写了一篇文章. Pipeline 基本对标阿里的云凤蝶, 已经开源, 相关文章还在撰写中. 赶紧点击 Demo 体验吧.

1 赞 3 收藏 评论

图片 36

对于开发人员来说,我们只需要定义好数据模型,再通过拖拽来决定元素的位置即可。从这种角度来看,只要能使用 Serverless 构建的应用和服务,都可以直接使用低代码开发模式。

从我们的理解来看,传统应用的开发流程是:

分析、设计、确认、规划需求。

设计系统架构。

搭建前后端项目。选择技术栈、从零开始搭建或者从脚手架中创建。

搭建持续集成。

创建线框图和高保真原型。

设计数据模型,定义前后端契约,即 API URI、方法、字段等。

前后端实现业务逻辑。

前端实现 UI 页面。

集成第三方后端服务。

功能需求测试(DEV、QA、ST、UAT)

跨功能需求测试

部署到生产环境。

低代码开发流程:

分析、设计、确认、规划需求

选择需要的第三方 API

在可视 IDE 中绘制应用程序的工作流程、数据模型和用户界面。

连接 API——通常使用服务、函数发现。

编写业务逻辑。手动代码添加到前端或者自定义自动生成的 SQL 查询。

用户验收测试。

部署到生产环境。

从步骤上来看,无代码编程少了几个步骤。这些步骤都因为大量丰富的内部系统集成,而变得非常简单。

就当前而言,无代码编程实际上是一种高度的场景预设的模式。因此,它存在一定的适用场景:

模型驱动开发。

快速 UI 构建。

极简的业务功能。

IT 资源受限。在资源受限的情况下,能快速开发出符合业务需求的应用最重要。

而从流程上来看,对于一部分的应用来说,我们并不能实现无代码编程——存在一些业务上的不同之处。因此,多数场景之下,只是实现了低代码编程。

若是想真实的无代码编程,则需要一些更特定的场景:

设计表格

创建报告

常规调度和自动化过程

更多的场景正在探索中。

无代码编程,除了需要准备好上述的一系列基础设施,还不可避免地会遇到一系列挑战。

谁来写这部分代码?

客户端的基础设施准备。

服务端的服务平台搭建。

统一用户体验设计。设计出一系列能便利组合的组件,及对应的模板页面。与此同时,它们还能适应于不同的风格,即有多样性的主题支持。

DevOps 流水线设计。低代码编程,依赖于一系列的自动化工具,以实现构建、调试、部署以及维护,同时还包含应用的测试。

领域语言设计。

自动化测试。如果我们的前端代码是自动生成的,那么我们还需要对它们进行测试吗?这是一个好问题,而如果代码是自动生成的,那么测试也应该是自动生成的。毕竟要在平台上,编写大量的自动化测试,以保证平台的质量。

其中,有一些部分略微复杂一些,我们大概可以探索一下。

在我们创建这样一个平台和工具时,我们要考虑的第一个问题是,这个工具是为谁写的?

没有编程经验的人。如业务人员,他/她们对于业务系统有着非常丰富的经验。

有编程知识,但是没有经验的人。

有一定经验的开发人员。

有丰富经验的开发人员。对于专业的人来说,自动化就意味着缺少灵活度。甚至与自己编写相比,他们要花费更多的时间来修复生成的代码。

显然,对于相当有经验的开发人员而言,这个工具并不一定是他们所需要的。

从我的理解来看,它适合于快速的 MVP 构建,并且生成的代码还应该方便修改,而不是诸如早期的 DreamWeaver 或者 FrontPage 这样的工具。

而与此同时,由于面向的开发人员水平不同,我们所需要做的工具也不同:

支持云构建和调试。

GUI 编程应用。

代码生成。

设计系统体系构建。组件库搭建,模板应用创建等。

更难的是,容易让开发人员能接受代码生成。

对于一个低代码平台而言,它对应的后端应该:

大量可用的现有服务。身份验证、安全性、推送能力、地图等等。

快速构建出后端服务。若是有内部 Serverless 或者 FaaS 方案,可以说是再好不过了。

方便与第三方服务集成。

灵活性。支持多语言等。

统一的后端服务 API,对于后端服务来说,我们需要一个通用的范式。所有的 API 应该按照这样的范式来设计。不过,作为一个 API 的消费方,我们可能没有这么大的权力,但是我们可以采用装饰器模式,即封装第三方 API 成统一的方式。为此,我们采用的方式,仍然是:

契约。诸如 Swagger UI,它可以直接创建一个简易可用的服务。

BFF。即我们一一去按我们的需要,去封装这些第三方应用。

查询语言。与自己编写 BFF 相比,更简单的方式是采用:GraphQL 这样的后端查询语言,便捷性更高、模式更加灵活。

在开发前的设计期里,我们需要首先设计出对应的领域模型。

低代码环境使用建模语言来指定整个系统、产品的行为。它意味着:

将数据结构、领域模式应用到程序的各个层级中。

将业务规则、决策融入到应用中。

这也就意味着,我们需要设计一个模型语言。而它对于我们而言,实际上是领域特定语言。如下是一个简单的 DSL 示例,用于描述使用到的组件:

{'style':'','id': 2,'blocks':

[{'content': {'content':'content','title':'hello'},'type':'card'}]

}

除此,我们还需要设计对应的布局 DSL,诸如于:

H:[circle1(circle1.height)] // set aspect-ratio for circle1

HV:[circle2..5] // use same width/height for other circles

H:|[circle1]-[circle2]-[circle3]-[circle4]-[circle5]|

V:|~[circle1..5]~| // center all circles vertically

最后,我们还需要将流代码,转换为真实的项目代码。三种类型的 DSL 结合下来,都不是一个轻松的工具。

写好现有的组件,通用型接口。如常见的登录接口,对于使用登录接口的业务来说,它们只关心三部分的内容:

成功登录。

取消登录。

登录失败。对于客户端而言,可以视为取消登录。对于服务端来说,则可能是密码错误、用户名不存在、账号被锁定等。

对应于以上情景,又有一些通用的逻辑处理:

登录成功。保存 Token,并返回历史页面。

登录失败。弹出一个自定义内容的提示框。

这些代码是相似的。

前端原型

在一些简单的前端应用里:

模板。只是在使用这些模板,再为这些模板设置相应的属性,绑定对应的值。

数据。其过程都只是在各种保存变量的值,并 CRUD 这些变量的路上。为此,我们需要一个数据处理的管道架构设计,用于处理这些值。

函数。事实上,我们的所有函数都只是一些管理函数,只用于处理这些对应的逻辑。

这些常见的功能都可以做成一些组件,它们对于某些应用来说,代码相应的重复。

无限加载页面。只需要绑定上 API,再控制一下元素的显示与隐藏即可。

表单。定义好字段即类型,对应的前后台逻辑都有了。除此,我们还需要为它们自定义好常见的规则,如正则表达式。而一旦表单之间有联动,那么这个组件的设计就更加麻烦了。

卡片式元素。

表单和表格展示。

常见图表。事实上,已经有一系列的图表工具了,我们只是在它们在基础上,进行了二次封装而已——使得它们可以变成领域语言的形式。

高级的响应式布局。与每个应用独立开发布局不同的是,低代码平台需要提供一套强大的自定义、响应式布局设计——即要满足移动端的通用模式,还要满足桌面版的通用模式。如对于大量数据来说,桌面端使用的是 Pagination,移动端使用的是无限滚动。

后端原型

事实上,对于后端来说,低成本平台意味着,代码生成及服务生成。而服务本身是有限的,既然是业务上发生了一些变化,后端服务也可能并不会发生变化。

它也意味着:

微服务化。每个后端服务要尽可能的小。

API 规范化。即采用统一的 API 格式,接受统一的权限管理

大量的 API 服务。

快速集成第三方服务方案。集成第三方服务是开发应用不可避免的情况。为了应对这个问题,我们需要做准备好对应的创建服务逻辑,传入第三方服务所需要的参数,便可以直接生成我们的转发服务。

那么,问题来了,既然如此,我们是否能提供一个定制的工具呢?让每个人可以创建自己的组件流?

答案,显然是可以的。

于是乎,在我最近设计的 PoC 里,采用的是 Anguar 框架。相应的基本思想如下:

使用 Material Design 作为组件库,使用 CDK 的 Drag 来实现拖拽功能。每个拖拽的组件,称为 Element,由 ElementDispatcher 由根据数据生成对应的组件。可拖拽的部分由两部分组成:布局 元素。

UI 构建完后,生成对应的 DSL,目前采用的是 JSON。毕竟数据结构是最简单的领域特定语言。

借由 Angular Schematics 解析这部分的 DSL,来生成相应的项目代码。

觉得不错请点赞支持,欢迎留言或进我的个人群855801563领取【架构资料专题目合集90期】、【BATJTMD大厂JAVA面试真题1000 】,本群专用于学习交流技术、分享面试机会,拒绝广告,我也会在群内不定期答题、探讨。

本文由pc28.am发布于前端技术,转载请注明出处:页面可视化搭建筑工程具前生现代,前端手艺的

上一篇:落到实处粘性布局 下一篇:前端是不是相应将CSS和JS分开设置七个分歧职分,
猜你喜欢
热门排行
精彩图文