关于javascript:F2C能否让前端像运营配置一样开发

作者：狼叔
原文地址：https://www.yuque.com/imove/b…

之前在《2021 前端会有什么新的变动？》一篇 10 万 + 的答复中有提到iMove，大家对这个开源我的项目颇为感兴趣，这里将它背地的设计思路和背景做一下介绍，从概念到实际，各种波折也是颇有思考的。

F2C 即 Flow 2 Code，即通过流程可视化编排来产生代码。这不是一个新的概念，但确确实实是跨界整合的一个经典案例。在做前端智能化的过程中，咱们发现，在 UI 侧有 imgcook 这样的设计稿转代码的工具，应答变动是足够的。但在逻辑畛域，真正能解决问题的又面向开发者的少之又少，iMove 算这个方向的一个摸索。上面，咱们一起来看一下吧。

从 FBP 到 BPM

为了可能让大家更好的了解 F2C 这个概念，咱们须要先交代一下背景，以后业界的做法和钻研。

可视化编程工具

大多数风行的可视化编程工具都只是基于文本代码之上的形象，在实时图像渲染，数据处理，程序架构等方面利用是十分多的，像 UML、ER 图也都属于可视化编程工具领域的。参考 https://nodes.io/story/ 里的文章，咱们能够看一下可视化编程工具由哪些。

Scratch 是一款由麻省理工学院（MIT）设计开发的少儿编程工具，反对多国语言，能够在 Windows 零碎、Mac 零碎和 Linux 零碎环境下完满运行，软件分为网页版和单机版，网页版须要电脑上网才能够运行，单机版不须要上网即可独立运行。其特点是：使用者能够不意识英文单词，能够不会写代码，就能制作出本人的编程作品。因为 Scratch 形成程序的命令和参数都是通过积木形态的模块来实现的，小朋友用鼠标拖动模块到程序编辑栏就能够进行编程了。

https://scratch.mit.edu/projects/411101291/editor/



像上面这种图像纹理解决，就做的十分直观。



人工智能化是另一个计算机图形学畛域，比方神经网络，就十分喜爱应用节点和线框来做可视化。



Nodes 是一个创意工具.



无疑，可视化工具是十分好的形式。这其实也是十分吸引开发者的，开发者习惯性编写代码，但代码如何做可视化呢？一种实现就是 FBP。尽管没有火起来，但的确是很有价值的实际，在某些畛域，比方 iot，是十分具备参考意义的。

FBP

Flow Based Programing 是由 J. Paul Rodker Morrison 在很早以前提出的一种编程范式。

概念

维基百科对 FBP 的定义如下：

In computer programming, flow-based programming (FBP) is a programming paradigm that defines applications as networks of “black box” processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally. FBP is thus naturally component-oriented.

Flow-Based Programming，简称 FBP，是一种数据流编程范式，有着一组独特的个性，同时是基于组件的软件工程办法的一种。FBP 把一个利用看作一组过程（process），过程间通过连贯（connection）进行通信，过程通过端口（port）来拜访连贯（这种形象相似网络编程）。

在 github 的这个 https://github.com/samuell/awesome-fbp 我的项目内列举了很多不同语言对该范式的实现以及一些材料，大家能够参考。

很惋惜，FBP 并没有遍及，感激炽宇老师晓得，让我了解了这写概念。但这不影响咱们能看到一些相似的案例。

社区钻研

前端社区出名大 V，TJ Holowaychuk 曾在一篇《You might not need if statements: a better approach to branching logic》较有争议性的技术文章中评论到：

“I thought about doing similar, I think flow-based programming is really cool, and we’re pretty much the only industry to not adopt it. That said functional languages like Elm pretty much fill this niche just fine, it’s JavaScript that is the problem in general.”



《What the hell is Flow-based-programming?》
https://medium.com/bitspark/what-the-hell-is-flow-based-programming-d9e88a6a7265

Flow-Based Programming 是一种很好的组件编程形式，基本概念就是

1. 把可复用的代码形象成组件，组件有 输出、管制、输入端口。
2. 用 DSL (畛域专用语言)把不同组件的输出、输入端口连起来，组合出简单的性能。管制端口用于初始设置组件的性能。
3. 最初由 Flow - Based runtime（引擎）解析 DSL，让所有组件一起运行实现你所需的性能。

Iot 场景

FBP 还能够利用在嵌入式设施上，尤其是实用于智能家居行业这种需要复杂多变的场景里。如下是管制 AR.Drone 腾飞，起飞的例子

// Start by connecting to drone. We could provide IP here
'' -> IP Connect(ardrone/Connect)
// Tell drone to take off
Connect() CLIENT -> CLIENT Takeoff(ardrone/Takeoff)
// Tell drone to land Takeoff()
CLIENT -> CLIENT Land(ardrone/Land)
// And that is all, folks!
Land() CLIENT -> IN End(core/Drop)

这些传感器只有输出和输入，尤其适宜的 FBP。



相干介绍网址：

1. http://noflojs.org/example/
2. http://www.jpaulmorrison.com/fbp/index.shtml

BPM

BPM 的意思是：即业务流程治理，是一套达成企业各种业务环节整合的全面管理模式。BPM 岂但内涵盖了传统“工容作流”的流程传递、流程监控的领域，而且冲破了传统“工作流”技术的瓶颈。

工作流最早起源于生产组织和办公自动化畛域，它是针对平时工作中的业务流程流动而提出的一个概念，目标是依据将工作分解成定义良好的工作或角色，依据肯定的准则和过程来施行这些工作并加以监控，从而达到提高效率、管制过程、晋升客户服务、加强无效治理业务流程等目标。

工作流治理联盟（WFMC）把工作流定义为：全副或局部由计算机反对或主动解决的业务过程。

工作流管理系统（Workflow Management System，WFMS）用来反对流程定义、治理和执行一批设定好的工作流程。这套零碎的指标是：管理工作流程以确保工作可能在正确的工夫内被所冀望的人执行。在自动化进行的业务过程中“插入”人工的干涉，是工作流零碎开发者的次要工作内容。

做 Java 的同学大抵都相熟 activiti 和 jbpm 这里成熟的 bpm 引擎。



对于常常变更，有明确流程的性能都能够应用 bpm 引擎来实现的，这里就不再赘述。

什么是 F2C？

F2C，全称 Flow 2 Code。即通过流程可视化编排来产生代码。

对于逻辑代码可视化编排，我是十分认可的，对于开发畛域，的确是能够进步研发效率的。在做前端智能化的过程中，咱们发现，在 UI 侧有 imgcook 这样的设计稿转代码的工具，应答变动是足够的。但在逻辑畛域，真正能解决问题的又面向开发者的少之又少。站在前端畛域视角，这可能是一个极好的摸索。

前端痛点



我认为前端，尤其是前端开发中问题很多，尤其是以下 3 点

• UI 老变，导致开发必须跟紧
• 逻辑挑战，开发也必须改代码，很多后端解决逻辑都在外面
• 组合接口，这是历史起因，次要是和后端配合导致的。其实没有 node 层，都由组件来做，会问题十分多。

好在前端发版本比拟容易，但这也加剧了组件的开发难度。

为什么所有的批改都要前端的改呢？这个逻辑不对。最近几年，始终都是流动中前端最累，做各种反复工作，以致于大家的感觉是前端是瓶颈。对此我是十分不认可的。其实咱们能够让经营不找前端开发就能实现这些事儿的。这才是提效要做的事儿。将来前端能够做以下 4 点。

• 逻辑可组装：其实是接口和 UI 在最小粒度上的复用。
• 流程可视化：这些可复用的最小单元，能够通过流程来进行编排，继而达到让经营简化的目标。
• 经营配置收敛：这是因为多套零碎导致经营老本很高导致的，对立放到一起最好。
• 玩法能力积淀：促使产品将玩法进行积淀，变成可复用的能力。并在一年中重复应用，以晋升业务数据为指标，这样能力做出产品化的好货色。

组件形象

对于 Web 前端而言，外围是以组件开发为核心的，组件中可能扭转 UI 的只有 2 个动作：别离是组件生命周期和事件处理。这个是依据各种流动的交互实现推断进去。



个别在 ComponentDidMount 里发动申请，依据申请胜利的数据实现渲染或其余业务逻辑，这种是齐全无 UI 的 Ajax 申请解决。

除了，组件申明周期，就只有各种交互事件里，这外面个别是 UI 和 Ajax 混用的场景。具体看一下利用场景。



举几个例子

• 比方点击事件，比方图中的用户领券流程，发送 Ajax 申请之后，通过 toast 弹出支付后果。
• 领券流程，首先须要对用户进行鉴权，确保用户是曾经登录的。这个在 App 里须要应用 JS Bridge 来做，这个也是 JavaScript 编写的，所以也可能以 JavaScript 函数来调用。但用户鉴权和领券是 2 个行为，它们之间须要通过参数传递来连接起来。
• UI + API 混用：比方前端点击事件，Ajax 申请和后端 API 是能够编排进去的。仍然以领券逻辑为例，先做用户鉴权，如果用户已登录，进行发券，如果用户未登录，跳转到登录页面。这里须要阐明的是发券分 2 个步骤，1 个是 Ajax 调用，1 个是具体服务端 API 实现，如果服务端 API 应用 Node.js 或 Node FaaS 进行透传，是能够建设 2 个流程，别离部署的。

对于服务，其实有很多思考，比方分类为端渲染和业务服务。这样就服务进行狭义化，无论前端，后端，API 代理都是服务，只有波及了 Server 端提供的服务都算的。



从前端视角看，服务能够做的事件更多，CDN 是 Server 端的，Node FaaS 也是 Server 端的，这才是围绕 JavaScript 能够做的广大空间。



其实，这些都是 iMove 要能做的事儿，也是 iMove 设计之初要实现的利用场景。如果通过结构化业务逻辑编排，同时生成放到 CDN 上的代码和 FaaS 上的代码，是不是一举二得，能够将前端的复杂度升高，甚至说在 Lowcode 畛域，再夺一城。

是否像经营配置一样开发？

我的好基友侯策曾在知乎上发表一篇文章《「可视化搭建零碎」——从设计到架构，摸索前端畛域技术和业务价值》https://zhuanlan.zhihu.com/p/164558106

侯策说“简直每一个前端团队，都会有一个页面搭建零碎”。页面搭建技术是一个陈词滥调的话题，可这个话题随同着前端技术的倒退，历久弥新。究其原因，包含但不限于：

• 经营流动页面对于产品业务至关重要，是吸引流量、进步留存的要害伎俩
• 高频且反复度较高的流动页面开发，对于前端意味着大量的工夫和人力老本耗费

在此背景下，疾速页面搭建技术就显得尤为重要。其特点和技术方向能够各有特点，但技术原理总体能够演绎为以下图示：



简略讲，搭建就是在强经营体系下的必然产物：开发模块，便于经营配置应用。



这种搭建是对经营极其敌对的，从经营同学作为搭建次要用户的角度来思考，以及无线化场景下，手机屏幕的特色，一维存储的模块列表是比拟敌对的。这个设计也对搭建服务自身带来了很大的简化，整个页面构造就是一维数组，每次操作都能够转变成一次简略的数组操作。当然，一维的存储不代表一维的展现，开发者仍然能够在展现的时候，通过一些父子关系，来把一维的存储构造转变为树状构造。目前咱们是判断把复杂度给开发者，简略的操作给到非技术同学，还是一个比拟适合的形式。

再来回忆一下咱们开篇讲的命题，前端在逻辑解决侧的代码，是否也这样实现呢？

大家的逻辑其实也就是一个流程图。很多人在开发之前是有画流程图，ER 图，UML 图习惯的，其实就是想梳理分明，通过设计形象，做出能应答变动的好软件。



咱们不能假设业务变化无穷，所以在变动的时候，可能疾速应答变动是十分重要的。经营搭建零碎的益处是，页面由模块组成，模块是开发提前开发好的，拖进去配置一下就能够发布页面了。咱们的写的代码其实也是有一样诉求的。

大部分函数里的代码都是面向过程的，组装判断是十分随便的，也未必能做到繁多职责。

如果可能可视化编排这些性能，双击节点编写代码，选中节点左边能够配置参数，是不是很有想象力呢？

Flow

可视化编排其实有很多年的工夫，以工作流治理 BPM 最为成熟，相似于 xstate 这种先定义状态机，而后再可视化也是一种思路。其实，无论哪种，都是围绕 Flow 来进行的。

Flow 的基本概念很简略，就是一个有向无环图（DAG），数据在节点间流动。



• 节点 Node

  • 节点是组成流的次要单元，负责对流入节点的数据进行解决，并输入到后续节点进行进一步的解决。

• 端口 Port

  • 每个节点领有输出和输入端口，输出端口负责数据流入节点，输入端口负责数据流出节点。每个节点都可能领有一个或者多个输出和输入端口。

• 连贯 Link

  • 一个节点的输入端口连贯到另一个节点的输出端口，节点解决好的数据通过连贯流入其后的节点。

Flow 的实现基本思路就是用一个函数 function 实现一个节点，输出端口映射为函数的输出参数。输入端口映射为函数的返回值。



流中有一个节点被设置为起点节点（End Node），通过节点间的连贯关系，以起点节点开始通过连贯搜寻所有的依赖关系（树形查找），失去一个节点运行的栈。例如上图，咱们就能够失去一个 [node1，node2, node3] 这样的栈。按程序出栈的形式执行每一个节点的性能就能够运行整个流。（留神，这是一个简略版本的 Flow 的实现，依然是一个批处理，不是 streaming）

须要假设每一个节点的性能是无状态的，这样就能够利用输入输出端口对计算结果进行缓存，但输出值是曾经运算过的值的时候，不须要运算，间接返回曾经计算过的值。

iMove

iMove 是基于 F2C 思维进行设计的开源我的项目。一天就涨了 280+ star，一举登上了 github 趋势榜第 1 名，获得的问题还是不错的，阐明这个我的项目定位精确，确确实实解决了开发者问题。

那么，什么是 iMove?

iMove 是一个逻辑可复用的，面向函数的，流程可视化的 JavaScript 工具库。

1. 它是个工具，无侵入性。
2. 双击编写函数，编排后的流程能够导出可执行代码，便于在具体我的项目里做集成。
3. 测试不便，右键间接执行，此处有翻新。
4. 让开发像经营配置一样实现性能开发，做到复用和 Lowcode。



界面如下。



简略讲，其实咱们现实的前端能够做以下 4 点。

• 逻辑可组装：其实是接口和 UI 在最小粒度上的复用。
• 流程可视化：这些可复用的最小单元，能够通过流程来进行编排，继而达到让经营简化的目标。
• 经营配置收敛：这是因为多套零碎导致经营老本很高导致的，对立放到一起最好。
• 玩法能力积淀：促使产品将玩法进行积淀，变成可复用的能力。

对开发者而言，iMove 恰好是能够实现这些指标的现实工具。动动鼠标，写一下节点函数，代码导出，放到具体工程里就能够间接应用，是不是很不便？

iMove 的口号是Move your mouse, generate code from flow chart，即动动鼠标，写一下节点函数，代码导出，放到具体工程里就能够间接应用。像经营配置一样开发，这曾经不是欲望，而是曾经实现了的。如果大家对 iMove 感兴趣，也能够一起参加开源我的项目中。

总结

我置信 iMove 只是 F2C 的一个开始，将来应该有更多 F2C 实现。做 iMove 的时候咱们其实也谨慎的思考 roi 的，事实上，定位对了，站在用户视角解决问题，它就应该是一个好计划。

当然除了这些事项，还有很多思考。

• F2C 基于流程图，就意味着节点和边等元数据，能够采纳。图将实体体现为节点，实体与其余实体连贯的形式体现为分割。咱们能够用这个通用的、富裕表现力的构造来建模各种场景，从宇宙火箭的建造到路线零碎，从食物的供应链及原产地追踪到人们的病历，甚至更多其余的场景。比方从 Apahce TinkerPop 对属性图模型（Property Graph Model）的治理，检索是十分有可能的摸索。
• F2C 基于流程图，让函数和函数之间进行编排，结构化。这些就为 AI 做好了出码筹备。目前 nl2code 的准确率有余，如果有了这些结构化的样本，通过 AI 组装还会远吗？
• 产研问题求解，找到 PD 和开发之间的映射关系，其实在出码中也是可能更好的解决的。把视角放大了看，PD 的流程是一个节点，那么开发流程就是这个节点的子流程。

F2C 目前还是一个摸索，真的将经营配置的形式引入到前端开发中，让开发流程可视化，可编排，能够摸索的形式除了 iMove 外还应该有很多。心愿有更多同路人，方向对了，路还怕远吗？

iMove 系列举荐浏览

1. 《2021 年前端趋势预测》
2. 《F2C 是否让前端像经营配置一样开发？》
3. 《登上 Github 趋势榜，iMove 原理技术大揭秘!》
4. 《iMove 基于 X6 + form-render 背地的思考》
5. 《所见即所得! iMove 在线执行代码摸索》