前端框架的图形化探索方向一个尝试, Respo Composer

前端框架的图形化探索方向一个尝试, Respo Composer

之前参加活动的时候想起一个问题, 怎么样才能让设计做出的稿子能更多被前端复用. 特别是在代码方面. 应该说设计工具已经包含了前端界面的大量信息, 编写代码包含相当多的重复劳动的. 但这是一个问题.

包括 React Vue 这些年逐步演进, 最初 React 的 Virtual DOM 能够在 Virtual DOM 的基础上通过热替换大幅提升前端的开发效率, 以及 ClojureScript 工具链进一步优化了热替换的使用体验, 给开发的效率带来提升. 现在, React Vue 本身讲更多的精力投入到性能的优化还有逻辑复用的问题上.

我想问的问题是, 界面和交互的开发效率怎样进一步提升?

提出这个问题同时也意味着另外的问题会暂时被搁置, 比如说框架的代码执行效率和最终体积, 比如说代码的复用和维护性. 对于大公司来说可以用钱弱化的一些问题. 而我的问题侧重点是, 如果界面和交互的规模不是很大, 维护周期也不长的话, 为了提升开发效率, 我们能作出怎样的改进?

Respo Composer 方案介绍

题图当中是我在春节前后进行的尝试, 开发了一个 Respo Composer App, 用来图形化建构 Todolist 的界面. 这个工具的功能非常局限, 但是完整展示了我最初的意图:

  • 有个 DOM 树的编辑工具, 可以设置页面的布局和节点的样式.
  • 工具将 DOM 节点组件化做编辑, 并且提供一些内置的组件, 方便快速编写.
  • 有基本的插入 Mock 数据的方式, 界面能够根据 Mock 数据通过逻辑节点渲染不同的样式.
  • 节点当中支持 Action, 渲染函数能够收集 Action, 可以外部响应 Action 修改数据, 数据再传入函数渲染新版的界面.

基础的界面基于 DOM 树的形态. 对于前端来说不陌生, 对于设计师来说可能不够优化. 最左边的是组件列表,实际上应该是说模板. 中间是树, 右边是选中节点的属性(类型, 布局, 样式..等等).

每个节点实际上对应着一个数据结构. 这些基本上都应该说是模板引擎的范畴. 同时, 也提供了预览区域, 编辑组件的同时, 能看到渲染的效果, 比如上面的 task 渲染出来之后, 是一个简化的任务, 包含卡片, 文字, 图标这些元素:

关于具体的操作, 我简单录制了过相关的视频, 因为没有裁剪所以内容略长,

Composer Todolist 开发版本 Demo (12分钟)v-wb.youku.com图标

这个界面修改之后会保存一份 EDN 格式的一份文件, 相当于 Clojure 的 JSON, 这份数据可以被用在后续的代码操作当中,

https://github.com/Erigeron/composer-todolist/blob/master/src/composed/composer.edngithub.com

关于操作, 我也录制过视频, 大致介绍了步骤,

Composr Todolist 交互部分初步演示(12分钟)v-wb.youku.com图标

更连贯一些的一个基础的 Todolist 添加任务的功能, 通过 Composer 可以实现, 完整的操作有个比较长的录屏做了演示:

Respo Composer 使用演示 (31分钟)v.youku.com图标

前面的操作, 加上 Respo 生态提供的工具链, 最终可以生成一个 Todolist 出来. 虽然功能上是有残缺的, 不过我觉得足够表明这个方案的可行性了.

Todolistrepo.erigeron.org

Respo Composer 实现原理

上面的 Demo 托管在 GitHub 上, 有兴趣的话可以尝试, 私有的一些工具比较多, 不容易上手, 不过按照 README 运行应该不难把 Composer 界面打开,

Erigeron/composer-todolistgithub.com图标

基础工具的 Respo 还有 Composer 的代码, 可以在 Respo 的 GitHub 主页找到. 目前 Composer 支持的节点有限, 首先每一个节点都用这样数据结构表示出来:

{
  :id "r", :type :button, :layout nil
  :props {"text" "Archive", "action" "~:archive"}
  :attrs {}
  :presets #{}
  :style {}
  :children {}
 }

这些属性跟 DOM 自带的属性有不小的差异,

  • type - 节点的类型, 包含下面一些组件.
  • props - 节点支持的属性, 每个类型的节点有各自的属性:
Type       props              Action
----

box                           action, data
space      width, height
divider    kind, color
text       value
some       value, kind
button     text               action, data
link       text, href         action, data
icon       name               action, data
template   name, data
list       value
input      value, textarea    action, data
slot       dom
inspect    title
popup      visible
case       value(?)
element    name
  • attrs - DOM 属性
  • presets - 一些内置样式, 目前主要是 flexbox 属性还有字体样式,
  • style - CSS 样式
  • children - 子节点.

熟悉前端开发的应该不难联想到这样的设计, 对应的是模板引擎和样式, 比如前面的图片当中 task 就是一个模板, 定义了 DOM 结构, 定义了样式. 代码当中提到的 action 和 data 类似于事件绑定, 当然这里是写不了业务逻辑的, 只能用来定义 Action 和参数.

内置的组件主要是布局和界面组件, 除此之外, 还有在比较重要的判断逻辑,

这些判断逻辑基本上对应的是模板引擎的功能:

  • Some - 对应 if, 判断数据是否存在, 或者数组是否为空.
  • Template - 进行模板的嵌套.
  • List - 生成数组.
  • Slot - 直接插入 Virtual DOM.

至于属性部分, 主要是 props 和 style. props 当中由于要进行数据的传递, 使用了 Clojure 配合表达式用. 目前的版本仅仅是试验性的, @ 表示从作用域当中取值, ~ 表示解析字符串的值.. 很奇怪的写法, 后续要调整.

Mock 数据部分做得比较简单, 只是提供了切换多个版本的数据的入口. 提供了数据之后, 就可以模拟不同的状态, 快速调试界面. 这一点在真实的开发当中, 为了调整界面而操作界面状态来模拟数据, 应该是有帮助的.

有了模板引擎, 有了 Mock 数据, 再进行排列组合, 就能够预览所有的界面的样子了.

延伸的思考

大概 iOS 开发, 或者 Flash 的开发, 以及 3D 游戏的开发当中, 相关的开发工具图形化已经用不少了. 我没有相关经验不好评论, 但是对于前端来说, 这一步应该也值得去做试验.

目前 Composer 提供的主要是演示的目的, 后续能不能变成实用, 还需要再思考和改进. 而且适用的界面也仅限于 Store Action View 这样简单的分层和极为简单的交互. 只是说理论上有着扩展的可能性. 同时在组件化, 在复杂交互放方面, 没有清晰的方案.

但是从试用当中印证了一些想法.

我认为前端开发是可以再进行细化和分工的. 制作界面和编写逻辑, 可以分为两个流程, 甚至界面这个流程, 就应该跟界面设计合并在一起. 比如说界面部分提供好上面界面当中的组件形态, 然后再由开发人员介入, 优化组件结构, 增加 Action, 编写配套的逻辑, 编译代码.

其次, 以往那么多前端框架, 试验了模板引擎的多种语法, 试验了 JSX 的语法. 诚然 JSX 有着强大的表达能力, 但是出于开发效率的考虑, 我们还是要有一个图形化的工具, 才能在开发速度上有进一步的提升. 而且图形界面可以延伸到 Pad 上进行多指触摸的操作, 比起敲键盘是要快的.

这样一套方案我是基于 ClojureScript Respo 试验的. 道理讲 React 或者 Vue 当中依然可以实现一遍, EDN 可是也是通用的. 我觉得基于这样的方案可以绕过很多文本语法的限制, 并且做一些之前可能并不方便做的优化. 值得继续尝试.

发布于 2019-03-09

文章被以下专栏收录