前言
近些年来lowcode、nocode是一个非常火热的话题，各大厂各团队也都开发了很多类似的产品。从可视化搭建到可视化逻辑编排再到前端智能化，这些对前端的研发效率带来了革命性的提升。
很多前端同学一看到前端智能化这类的名词就抱着抵触的心理说：“前端智能化确实是‘革命性’，革了很多前端同学命，让很多前端失业”。其实不然，这类产品的出现本质上和构建工具、CI/CD、自动化测试、组件库一样是为了提升前端的研发效率，减少枯燥重复性的工作。
LowCode、NoCode的轮回
其实lowcode、NoCode是一个历久弥新的话题。前端早在十几年前就有了页面可视化的搭建的工具像Dreamweaver(以下简称DW)，但是到了今天工作中已经没有人去使用它了，其主要原因是因为目前数据和页面的结构已经完全分开了，我们需要发送网络请求后将数据渲染在页面中。由于DW无法承载过多的动态内容，它也成为了历史，但这类想法的延续，各大厂各团队也都开发了很多类似的平台。从而让非技术人员（运营、产品经理）也能参与到应用的研发中。
理想很丰满，现实很骨感。NoCode更加适合比较垂直的场景中，并不像LowCode我们可以通过编码的方式补齐物料、D2C的不足。目前通过NoCode的方式可能只能开发出一个7-8成左右的产品。但是换一个角度去思考，可以让一个非技术人员，只用很低的门槛就完成一个MVP版本产品，可以快速投放到市场验证团队的目标，快速试错。如果验证可行，再通过转成LowCode或者ProCode的方式继续迭代优化。
其实这种方式在游戏开发中早已经落地，各大游戏引擎中都有Visual Scripting(可视化脚本)的编辑方式，像UE中的蓝图，以及Babylonjs新出的Graph Editor（如下图所示，左：Babylonjs 右：UE）。像目前市面上的主流游戏绝地求生、堡垒之夜最开始都是使用Visual Scripting方式进行开发，当证明了方案的可行性之后才会转到代码的方式进行开发。未来部分前端应用的研发节奏可能也会是NoCode => LowCode/ProCode。
D2C
D2C是Design to Code的简称，顾名思义就是从通过设计稿生成代码，在前端智能化中是一个很重要的概念。早在2018年我还没有入行前端的时候就已经听说某宝双十一活动的代码70%+-通过AI生成，显然这也不是多么新鲜的技术了，其实早在十几年前Photoshop就已经支持设计稿导出为HTML代码，但由于不友好的布局方式以及无法承载动态内容，并没有得到广泛的应用。但随着web技术的发展，仅仅生成HTML+CSS的方式已经满足不了我们的需求，更多的是希望生成Vue、React、miniapp这类的DSL，我们可以进行二次编辑。
近年来社区中先后推出了imgcook以及CodeFun这类的工具，可以通过Photoshop、Sketch设计稿以及图片生成主流的DSL的页面部分。我们只需要关注业务逻辑就可以了，也不用和UI们对线了。从而帮我们提高了开发与沟通的效率，我们可以把大部分精力投入到JS逻辑中。但目前各家的D2C工具的还原度以及CSS部分的复用程度都有很大的提升空间，部分情况还需要手动调整样式，期待它们早日成熟。
未来的前端智能化不止是D2C，还会有P2C（Product to code）即产品文档生成代码，产品经理只需要写产品需求文档，就可以基于AI生成代码。目前前端社区中有类似的demo：GPT-3 （需魔法上网），在demo中我们可以看到只需要通过简单的文字描述就可以为我们生成JSX代码。其实国内某些大厂也在探索P2C的应用，期待他们早日成熟，毕竟P2C的使用方式是最简单直观的，当然P2C背后的研发成本也是很高的，我们可以大胆设想一下成熟之时~
API2code
页面的部分我们可以通过D2C去生成，那么我们不禁会思考，那么api部分我们是不是也可以生成呢？我们可以回想下之前做过的项目。我们还需要手写请求方法以及api路径（RESTful API时），尤其是在Typescript的项目中我们的api的接口会有很多的interface，我们在定义文档的时候已经定义了字段的类型，当写代码的时候还是需要一个个的照着API文档去手写字段类型，这未免有些过于... 前端如此，后端也需要手动的去写一套类型。这带来了过多的重复性的工作，我们不防可以去做一个工具去生成代码。于是乎我和大佬们写了个叫fe-code的cli，用于将各个API管理平台的文档生成前端的API crud以及类型代码。
早在今年年初，
尤雨溪在一场直播中说：目前国际环境下很多前端团队在做前后端类型的统一
目前这个CLI支持将OpenAPI的JSON Schema以及自定义的JSON结构转换成JS、TS的 crud代码以及interface。我们还开放了解析器选项。
const parserMap = {
Custom: apiConfig => apiConfig, // 内部自定义的数据结构
OpenAPI: apiConfig => parseOpenapi(apiConfig), // OpenAPI
// 其他api规范...
};
大家可以根据自己团队的API管理工具的JSON Schema来写转换函数，转换成fe-code内部自定义的数据结构，最后会通过这个自定义的结构生成我们需要的代码。
以
Yapi为例（各个api管理平台都提供了导出JSON Schema的方法），我们可以在项目 -> 数据管理-> 数据导出中选择JSON，最后导出JSON，我们就可以通过这个JSON写转换函数转换成fe-code内部自定义的JSON Schema。
fe-code使用
可以通过
npm install fe-code -D进行安装；也可以直接通过npx命令使用
我们可以直接通过npx fe-code api2code去使用API代码生成的部分。假如新项目没有脚手架的话我们也提供了初始化项目脚手架的的命令，可以通过npx fe-code e2c的方式取初始化Vue / React + Webpack / Vite /Snowpack的项目。
使用api2code时我们需要传入两个参分别是-iJSON Schema的路径，-o生成代码的输出路径如下所示：（示例JSON）
npx fe-code api2code -i ./apiConfig.json -o ./api
随后我们选择我们的Schema种类以及需要生成的代码、语言种类，最后会将代码生成到我们需要的目录下并且使用prettier进行代码的格式化，默认会走项目目录下的prettier配置，如果没有配置的话则走默认配置，生成的代码如下如所示。以下代码是TS的crud，我们可以看到再输出的目录中有两个文件夹分别是models和services，分别对应了数据类型和API请求。如果选用JS的话则没有models。
就像上面那样我们只需要通过简单的命令就可以将API生成类型以及crud代码，这给我们的开发体验带来了很大的提升，再也不用照着api文档一个个的抄字段抄类型了，也减少了出错的概率。我们可以有更多的精力投入到复杂的业务逻辑以及代码质量上。
GraphQL
上文只描述了基于RESTful的代码生成生成，下面简单的介绍下GraphQL代码生成的库。其实在GraphQL的社区中已经有了很成熟的产品：graphql-code-generator。我们不仅可以生成类型代码还可以生成React-Query、React-Apollo、Node、Java...的代码，支持几十种语言/框架/库。
可视化搭建
可视化搭建这个话题想必大家都再熟悉不过了吧，我们只需要通过拖拽的方式就可以生成应用或再进行二次编辑(lowcode)。这类的平台早已经普及，在各个前端团队中均有类似的产品。同时还有很多公司提供了对外的服务，让想做官网或者活动页的公司无需前端工程师也可以进行开发。目前fe-code处于1.x版本，我们考虑在2.0版本的时候引入UI界面把上文中的所有命令做成可视化的操作，并且引入可视化搭建，考虑通过storybook+Bit的方式提供并管理业务中常用的物料，并且约定一套规范开放给所有开发者，让其他开发者也可以贡献物料。
考虑通过Electron或Chrome File System Access API的方式开发整体的可视化搭建部分，拖拽组建后可以讲组件代码写入到项目页面关联的目录下并根据用户自定义的配置进行格式化，并且可以与上游的api2code的部分进行关联，可以讲数据直接注入到组件中。这时我们就可以通过工具生成项目的60%-70%的代码，减少重复的工作，告别加班，剩下的时间用来陪npy多好😁。
前端的蓝图
随着大前端时代的到来，前端工程师们也不仅仅是写页面(组件)的了，前端工程师也变成了一个交叉职位。几年过后再回眸等前端智能化完全成熟的时候，一些简单的需求的开发就不需要人为的代码参与了，我们可以把之前用于写重复枯燥的代码的时间完全解放出来，投入到更有意思的领域像XR、图形学、AI、webIDE，5G的到来必将给他们在前端的应用带来无限的可能。
如在文中发现有误之处，欢迎反馈、纠正。
写在最后
开源地址：fe-code，欢迎大家star⭐️、PR。