前言
不知道什么时候兴起的低代码风潮，我们公司也搭起来了一套自己的低代码平台，我不是低代码开发团队的，有幸参与到低代码体验当中。当时组长让我写一个远程组件，那时我很慌，因为我没接触过低代码，不知道这个组件要怎么开发。后来问了一圈才知道，这个远程组件其实就是低代码没法实现的个性化组件，我在特定脚手架上面开发完组件后，直接打包成js上传到低代码平台上使用。
远程组件用的基础框架就是react，最后用命令打包成单独的js文件资源。 脚手组建目录结构：
├──build // 远程组件打包目录
│ ├──remoteComponents
│ │ └──componnets
│ │ │ └──componnet.js // js打包文件
├──src
│ ├──componnets // 远程组件代码
│ └──pages // 测试页面
├──fishx.config.ts
...
配置文件fishx.config.ts：
const config = {
title: 'fishx',
plugins: [],
proxy: {},
remoteComponents: {
// 需要打包的远程组件,注意打包的远程组件必须要放在 src/components 目录下，或者可以使用@别名来指代src目录
entry: [
'example', // 或者 '@/components/example', 这两个路径等效
],
externals: {
react: 'react',
classnames: 'classnames',
},
outputDir: 'remoteComponents', // 文件输出位置
devtool: 'source-map',
},
};
低代码的优缺点
不可否认，这种组件确实能解决一些问题。我当时做的组件也比较复杂，一方面要根据接口获取的数据渲染成流程图信息，一方面还要有流程图交互的操作，低代码也不支持画流程图。远程组件算是一种兜底的解决方案，如果有低代码不能解决的需求还能通过我们这些程序员来解决。
但同样这样做也有缺点，就是源代码没有和文件资源关联，怎么维护是一个问题。目前的维护方式就是我自己管理好组件的源代码，每次需求出现改动，由我修改之后重新打包上传。如果少量的个性化需求，可能还看不出来问题，但是如果后期累积的多起来，或者开发的人多起来，到时候改组件知道去找谁谁谁么，我肯定会推脱：跟我没关系了啊，这个代码我已经传给某某某了，是不是某某某在开发我就不知道了。我的建议是把这种线下的远程组件开发能改成线上开发，类似云函数，我们仅解决开发的问题，不需要去关注如何打包和使用的问题，不管谁改代码仅在原来基础上修改即可。
后来，公司为了推广低代码组织了一次低代码开发竞赛，奖金还算丰厚，年少无知的我以为有了上次组件的开发，参加这个低代码不是简简单单的事。我跟组长说想参加这个，组长就动员了部门里两个实习生，还有一个老牌后端程序员跟我组队去参加。因为开发时间包括在上班日里面，我们不仅要上班，还要找时间去做这个项目，有段时间还很忙根本没空做，最后是加班肝了好几天才给它做完ORZ。当然后面也没有获奖，参赛的基本是做低代码开发的，但是因为我们组做的功能比较完善，特例给了我们四个一千块的鼓励奖（250？）。
总结
低代码看似简单，其实坑还是蛮多的，真的用起来其实不比写代码简单啊哇。
总体来说，1、低代码一点都不智能，没法做到通用，很多重复操作重复性配置，无法像写代码那样可以灵活复用； 2、低代码只能做简单的功能，不支持的东西还很多； 3、低代码样式偏简单，花里胡哨的样式没法玩； 4、远程组件很坑，源代码不知道怎么维护；
