一、前言

1. 背景

出于为了实现有关厂区的数字孪生项目，断断续续使用ThingJS平台开发一年左右，做一个使用感受的总结。

2. 业务场景

开发一个基于厂区的数字孪生项目，基于ThingJS低代码开发的页面分为div3d、div2d结构；
div3d是3D场景展示的HTML节点，3D场景可以通过动画来模拟现实，并展示对应数据信息；
div2d是2D图层展示的HTML节点，基于业务需要实现的数据和图表展示、功能操作等，其中功能操作可联动3D场景；

二、开发流程

1. 场景建模

使用「森园区」或「模模搭」，具有现成模型，建模需求不大，可以使用内置建模搭建场景；需要还原实际园区场景需要依靠 3D建模师提供模型。

2. 低代码开发

具体可参考官方示例（需结合官方在线开发参考手册）

三、优缺点

优点

整合功能开发；
固定方法便捷引用；
0基础建模人员，可快速搭建简易建模；

缺点（偏开发方面）

a. 文件引入方式

THING.Utils.dynamicLoad([
    '/static/vendor/twitter-bootstrap/3.3.7/css/bootstrap.min.css',
    '/static/vendor/twitter-bootstrap/3.3.7/js/bootstrap.min.js',
    '/static/vendor/moment/moment.js'
    // ......
],
    function () {
        // 加载场景代码 
        var app = new THING.App({
            url: 'https://www.thingjs.com/static/models/factory',  // 场景地址
            background: '#000000',
            env: 'Seaside',
        });
        // 加载场景后执行
        app.on('load', function (ev) {
            // 创建提示
            initThingJsTip(`制作项目过程中，平台支持上传页面资源， js 和 css 可以通过 dynamicLoad 进行引用`);
        });
    })

官网示例给出了上述 引入js和css 的方式，这种方式在具有引入大量文件需求的时候，会增加页面的初始加载时长；

问：这种引入文件的方式为什么会增加页面的初始加载时长？

答：

首先ThingJS低代码项目的运行流程大概是先依次加载文件，在加载3D场景，然后展示出整个项目场景；（THING.Utils.dynamicLoad()方法的参数1是文件地址数组。）
后期的项目业务量会越来越多、越来越复杂，需要加载的JS、CSS文件更多；（笔者所开发的项目按照功能模块来写，至少40个JS文件，每次加载时长在30s～1min多之间。）
开发过程中会有引入第三方插件的需求，随之我们需要加载的文件会越来越多；（dayjs.js、js.cookie.js、bootstrap.min.js......）

b. 2D页面结构添加方式

/**
 * 利用模板字符串 创建页面元素并添加到div2d中
 */
function createButton() {
    // 使用 bootstrap 样式
    var template =
        `<button class="btn btn-default" type="button" style="position:absolute;left:20px;top:20px;z-index:2">当前时间</button>`;
    var btn = $('#div2d').append($(template));

    return btn;
}

上述是ThingJS低代码平台开发2d平面图层添加HTML元素节点的方式（即：模版字符串【``】）

也就是说，你所有的HTML节点都要使用模版字符串进行添加；

举例：导航栏、侧窗、弹窗、按钮等......基本所有图层都需要使用模版字符串进行拼接、添加；

（可以参考低代码平台示例中是如何添加2d图层的。）

（这个博客也有提到这种方式）

c. 无法使用CSS预处理器

因为文件引入方式不支持CSS预处理器相关后缀文件引入，所以笔者一般的开发方式是：在VSCode中新建html文件，写好页面结构，依靠Less/Sass进行写样式，然后分别将html结构通过模版字符串添加到div#div2d的节点中、将解析出的CSS文件导入低代码项目中。

d. 无法很好地使用模块化开发

ThingJS不支持目前主流的JS模块化方案；

该博客中有提到引入js和css 的方式可以作为一个模块化文件引入方案，但是博客中有提到： “如果要实现一个较为庞大复杂的业务场景时，就不太方便了” ，也正是笔者担心的。

因为前期开发获取到ThingJS开发方式的参考极少甚至没有（只能参考ThingJS低代码示例），所以笔者一直在使用的是引入js和css 的方式，算是全局变量了......（因此也引发了后续编译或混淆后的报错问题......）

主流的JS模块化方案无法使用，可以尝试以下方案：（两种方式笔者都未曾验证是否存在其他问题）

1. 命名空间

使用对象来创建命名空间，将相关功能和变量组织在命名空间下，以避免全局变量的冲突。

使用命名空间的方式，你可以在全局范围内只定义一个对象，然后将模块的功能和变量添加为该对象的属性。

var MyNamespace = {
  // 模块1
  module1: { // ... },
  // 模块2
  module2: { // ... },
  // ...
};

2. 模块模式（推荐）

使用函数返回对象的方式创建模块，将模块内部的变量和函数隐藏起来，只暴露需要暴露的接口。

var MyModule = (function() {
  var privateVariable = '私有变量';
  function privateFunction() { // 私有函数 }
  function publicFunction() { // 公有函数 }
  
  return { publicFunction: publicFunction };
})();
MyModule.publicFunction(); // 调用公有函数