经过实践的一款能够提效 2000% 的低代码（前端中后台）开发工具设计与功能介绍

最新推荐文章于 2024-05-28 11:18:45 发布

迷路的蝙蝠

最新推荐文章于 2024-05-28 11:18:45 发布

阅读量150

点赞数

文章标签：低代码前端 java

本文链接：https://blog.csdn.net/mryaj/article/details/132859425

版权

前言

请先停一下发散的对低代码的唾弃思维才能去寻求创新之路

目前大部份都是表单设计设计器，真正可以开发系统的开放型的可以说少之又少，甚至国内顶尖公司阿里开源的低代码引擎 lowcode-engine 也不可以。
能够开发自定义项目的更是没有，能完成全系统并上线的更是不必多说。下面真诚的介绍一下真的可以非常快速，又能开发自定义项目的工具（中后台前端方向）的功能与提效设计思路。
真正能够提升 20 倍的效率的设计，听到 20 倍大家可能会嗤之以鼻（这狗东西真能吹）。不过我觉得也是，因为熟练工肯定不只 20 倍啊（手动狗头），测试方式就是找了一些开源的
中后台管理类的项目然后对其功能进行模仿，比如商城后台、园区管理（70+ 页面）轻轻松松一天都能搞定。

我们一天就能上线的有一些小游戏后台、员工分享平台、内容管理平台、面试系统后台等等，助力开发达到质的提升。

设计思路

那么为什么可以这么快呢？那来谈一下设计思路（这里我只谈中后台类），主要为：抽象（结构）、提取（功能）、组合（元素）

抽象

比如我们有一个后台，页面有首页、三个页面管理是以查询、表格展示、弹窗编辑为主要结构（当然可能一个页面有导入导入或其它，这里说的是主功能的交集）、三个页面以查询、卡片列表为主要结构展示、
另外两个页面就是一个表单用于编辑数据。

首页为独立的先不谈，那么我们想一下，前三个页面看似查询的字段名称、组件、接口，显示的字段、编辑或者新增的字段、组件等等都不一样，但是其逻辑都是一样的。就是将查询的组件的数据合并、调用查询接口
将接口的数据放到表格中或调用失败的处理、点击添加按钮打开弹窗校验提交调用保存接口、点击表格中编辑将行数据传入弹窗的表格中校验提交调用更新接口。由此可见，其逻辑结构是不是都相同的呢，是不是可以抽象出来呢？
这里可能有小伙伴会想这不就是组件么，可以但不建议封装，如后期迭代功能不断增加、各个页面又各略有差异，那么这里参数会不断变多，组件的 if 代码量不断变大直到无法维护。而写好一个页面后复制修改又非常容易漏改且不容易被发现，就会造成反复上线，另人崩溃。另外的页面结构也是同理。所以我在工具中设计了页面母版用来做第一步的抽象。

页面母版
比如我们可以将上面三种类型页面制作成页面母版，只设计结构与操作逻辑而其中变化的组件空着，而且还可以定制不同风格让每个系统开发出来的样式都能定制，实际页面开发的时候添加组件，又可规避重复测试。

实际过程中还遇到个问题，比如我们几个系统查询的时候都有分页参数，但 A 系统参数为 page_no, page_size, B 系统参数为 pageNo, pageSize 之类，A 系统数据查询成功的判定条件为 response.code === 0
B 系统判定条件为 response.success，A 与 B 系统返回的数据结构如下(response A, response B)。而这些又是都存在的固定逻辑，而我们设计是通过工具就不可能去限制服务端的结构，所以这里我处理的方法是模版变量来统一处理，比如我们定义 success = 'res.code === 0', tableData = 'response.data.records' 等等，在制作母版是使用 key 实际生成为对应 value，那么就可以在不同项目中修改一次对应 value 即可。

//response A
{
    code: 0,
    message: '成功',
    data: [{...}],
    page_no: 1,
    page_size: 15,
    total: 9527,
    ...
}
//response B
{
    success: true,
    message: '调用成功',
    data: {
        records: [{...}],
        pageNo: 1,
        pageSize: 15,
        total: 1024,
        ... 
    }
}

而且调用的接口也不是固定的，比如 A 页面的查询为 user/search, 删除为 user/delete 等等， B 页面查询为 order/search, 删除为 order/delete，一般同系统 CRUD 后缀固定而前路径则是变的，
那么就需要在创建页面的时候才能定下来，比如和创建页面时的某个属性（页面文件名如 user）有关，那么我们定义接口时就可以 ${fileName}/search，那么使用此母版创建页面是即会将 ${fileName} 替换为
user，即 user/search 那么便处理了这些变化性问题了。

那么对于上面的系统我们就可以先制作三个母版，一个增删改查、一个查询卡片、一个表单（空表单中有个提交按钮，并调用一个接口）。

项目母版
事前准备好后我们就可以创建一个项目了，而从正常开发者角度来看是不是先选一个合适的脚手架然后在此基础上进行开发呢？没错，所以我们在创建项目的时候也需要先选个脚手架，暂且叫项目母版，即用来做为初始化配置
比如 http 库 axios 的 baseUrl、令牌名、页面的总样式（比如每个页面的布局结构）、组件库（比如表格内容居中、输入框带自动清除、上传的缺省路径）等等。为什么不创建项目时直接配置呢？因为多个项目这些配置很多都是共通的，提取出项目母版是方便我们进行复制后在创建另一个项目时直接修改后使用。

自动生成
有一种是以大量通用的 CRUD 为主的项目，那么这类标准功能我们自然不能还要手动每个页面去添加组件又要配置属性，所以自然而然是应该去自动生成，可以节约大量配置时间。一般页面的功能都是和数据库结构息息相关，所以我们还是从数据库结构入手。

一、直接连接数据库读取结构、二、导入数据库结构。

取出所有的表对应我们所有的页面（如果页面有多张表，需手动修已选择），表注释 || 表名为页面名，列名为字段名、字段注释 || 字段名为标签名，数据类型对应相关组件，非空为校验方案等，即可以生成相应页面的设计结构，这样我们还可以在此基础上进行后续的完善。

提取

比如我们项目中有多个 Select 的选项是通过接口查询而来的租户信息，又比如多个连续相同组件等等，以正常开发的思路就是提取为组件。同理我们就需要将此功能一键提取到模块中，即可在其它页面中直接使用，以达到不做一点重复的功能。设计就是提取此间的数据结构以及其它使用到的接口、函数、变量等等，在使用的时候去创建相关。

组合

比如我们表单中有一个表格来动态添加数组类数据，那么如何设计这样一个功能呢，一般常用的做法自然是封装一个表格组件给这表格组件绑定添加与删除等功能，可是如果B系统需要的不是此风格的操作方式，那么就需要再开发另一个组件，即以穷举的方式来实现系统，这样可操作空间就会大大降低

那么通过提供的元素去组合成相应的功能就非常有必要了，核心就是数据驱动。即先排列好需要的组件，然后去控制数据以达到相应的功能，比如我们表单对应如下一组数据，那么我们对应的是不是一个表单中一个输入、一个表格（两个输入），那我们就可以在任意可执行方法内去修改 tableData 来控制表格的展示，如添加一条数据，那么表格就会展示出两条。当然每个常用功能都去组件自然会降低效率，解决方案就是系统中先组合出相关较多的模块可以直接使用，也可以自由定义一个后提取为模块。

{
    class: '',
    tableData: [
        {name: '', age: ''}
    ]
}

扩展与维护

系统功能层出不穷，组件的扩展与项目的后期维护就相当关键了，若只能开发只有系统提供的组件的功能并且维护的成功比开发来的还要高，那么任何工具只能说到此为止了。

自定义组件
如何扩展？自定义组件自然是不能少的，那如何让自定义的组件和系统结合呢？核心就是两个重要的参数：组件对应的数据 value, 数据改变的回调事件 onChange, 任意组件无非就是对数据的处理与返回处理后的结果。value 则是任意对象， onChange 则是组件内部发生了处理并出现了新的 value 对象，甚至只做静态的展示 onChange 事件都没有。基本不需要约束，只要将组件编译后上传时添加自定义的属性即可

//以 react 代码为列，这样一个自定义组件就完成了
import React from 'react'
import { QRCodeSVG } from 'qrcode.react';

export default function Component({
    value, className, style, config = {}
}) {
    return <QRCodeSVG
        value={value}
        style={style}
        className={className}
        {...config}
    />
}

维护
为何不以 JSON 协议去完成页面？而是以 react 的 useState, useEffect, useCallback, 组件等方式。就是因为 JSON 对象为静态数据，而每一个配置项就内部封装了固定的实现方法，维护就需要去理解对应参数效果，而遇到功能无法参数无法解决就很难解决这一小块的功能。即大大的扩大了维护成本，甚至为此小功能要重新开发这相关的整个功能块，想死的心都有

而以组件的方式好处就是不需要去理解上下文，可以找到任意切入点修改到点的功能

<Form 
    columns={[
        {type: 'input'},
        { 
            render({data, value: $base: {onChange, ...rst}}) {
                //react code
                return <div> </div>
            }
        }
    ]}
/>