本文主要针对于在Vue和React项目中使用esri-loader和@arcgis/cli脚手架进行ArcGIS JS API开发时,比较两种方式的不同,供各位参考。
概述
当我既写了esri-loader方式来进行ArcGIS JS API的开发文章,又写了@arcgis/cli脚手架的方式来进行ArcGIS JS API的开发文章之后,相信很多小伙伴看到后会产生“选择纠结症”,我到底该用哪种方式来进行ArcGIS JS API的开发呢?不要着急,我给你一个可供选择的参考,简单又实用:
- 如果项目已经在进行实施,中途可能需要用到ArcGIS JS API中的相关功能模块,那就选择esri-loader方式;
- 如果项目并未开始实施,但是后期会有ArcGIS JS API中的相关功能需求,推荐使用@arcgis/cli脚手架,当然,你也可以用esri-loader方式。
既然有两种方式可供选择,那我们简单来看下这两种方式的优势与不足。
相关测评内容
实际项目实施方面
根据文章开始所说,如果项目已经在实施,我们只能通过esri-loader方式来进行JS API的开发,因为此时JS API算是后期才引入到项目中的,我们的项目可能并不是一个整体的GIS项目,GIS相关功能模块只是系统中的一小部分,所以我们就没必要用@arcgis/cli脚手架构建一个完整的基于WebGIS框架的项目,这样会影响系统应有的架构,使系统架构的健壮性大大降低。
如果项目并未开始启动实施,并且明确知道此系统后期会有JS API的相关功能需求,而且此项目系统中GIS相关功能模块所占比重较大,那推荐使用@arcgis/cli脚手架来构建项目系统框架,因为我们可以看到,通过脚手架构建的项目应用中代码组织结构非常优秀,并且基于Webpack配备了完整的主流系统构建工具和代码检查工具。
主流技术方面
通过esri-loader方式进行JS API的开发时,其实我们很多情况下还在使用ES6甚至ES5的编码方式进行系统开发,项目系统中所用的各种主流插件是我们主动性地去增加配置的,换句话说,如果你不知道有什么主流技术,那你还是一直在啃技术老本,项目系统中并未引入主流的开发技术。
@arcgis/cli脚手架方式可不一样,它默认在你的项目代码中配置了Eslint、babel等主流插件,并且最重要的是,它的项目代码是用TypeScript来编写的,所以从这几点来看,脚手架方式开发JS API的过程中,所用到的开发技术是比较靠近现阶段主流开发技术的。
编码方式
esri-loader编码方式如前面所说,你可能在用ES6或者ES5在进行系统开发,然后我们JS API中的各个功能模块还是用基于Dojo的AMD方式来加载,并且实现全局引入加载很困难,代码如下:
1 | // 创建二维地图 |
以上代码可看到,我们通过loadModules来引入了JS API中所需的功能模块,而且以上代码是在一个组件中的,可以看到第一个方法中为了创建一个二维地图,我们用loadModules引入了相关的功能模块;第二个方法中为了创建三维场景,我们又用loadModules再次引入了所需的模块,这样在编码方式上就很繁琐。换句话说,如果我们在什么地方要用JS API中的模块,那我们就要在相应的地方用loadModules引入所需的模块。
@arcgis/cli编码方式解决了这一恼火的问题,我们可直接在组件代码顶部引入相应模块,然后在下面的代码任意地方使用它们,示例代码如下:
1 | import ArcGISMap from 'esri/Map'; |
以上代码可看到,我们只需要在组件代码顶部引入此件组所需要的JS API相应的模块,然后在下方的代码任意位置都可以使用此模块,就没有必要每次都通过Dojo的模块化加载机制来加载了。
项目启动运行和打包部署方面
esri-loader方式开发JS API项目系统后,如果我们不对项目进行相应的配置,基于Vue框架的项目和基于React框架的项目启动命令是不同的,它们的打包命令却是相同。
@arcgis/cli脚手架创建的项目应用,不管是基于Vue还是基于React,启动命令相同,打包命令也相同,所以更加的友好。
两种方式创建的项目,打包后部署流程一致,并无相关的差异。
其他方面后续遇到后再更新……
总结
就目前四个方面的简单测评来看,如果是一个还未进行实施的项目,并且其中GIS相关功能模块占比较大的情况下,推荐使用@arcgis/cli脚手架方式搭建项目框架,具体coding感受,只有自己去体会一番了。作者力荐@arcgis/cli脚手架方式。