本文主要针对于在Vue和React项目中使用esri-loader和@arcgis/cli脚手架进行ArcGIS JS API开发时,比较两种方式的不同,供各位参考。
当我既写了esri-loader方式来进行ArcGIS JS API的开发文章,又写了@arcgis/cli脚手架的方式来进行ArcGIS JS API的开发文章之后,相信很多小伙伴看到后会产生“选择纠结症”,我到底该用哪种方式来进行ArcGIS JS API的开发呢?不要着急,我给你一个可供选择的参考,简单又实用:
既然有两种方式可供选择,那我们简单来看下这两种方式的优势与不足。
根据文章开始所说,如果项目已经在实施,我们只能通过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方式来加载,并且实现全局引入加载很困难,代码如下:
// 创建二维地图
_createMapView: function() {
const _self = this;
const option = {
url: gConfig.arcgis_jsapi_hosturl + 'init.js',
css: gConfig.arcgis_jsapi_hosturl + 'esri/themes/light/main.css',
};
loadModules(['esri/WebMap',
'esri/views/MapView',
], option)
.then(([WebMap, MapView]) => {
// 实例化地图
const webmap = new WebMap({
portalItem: {
// autocasts as new PortalItem()
id: gConfig.largeScreenWebMapID,
},
});
const view = new MapView({
container: 'mapViewContent',
map: webmap,
zoom: _self.mapviewLevel,
center: [102.714408, 25.043706],
});
}).catch((err) => {
_self.$message('底图创建失败,' + err);
});
},
// 创建三维地图
_createSceneView: function() {
const _self = this;
const option = {
url: gConfig.arcgis_jsapi_hosturl + 'init.js',
css: gConfig.arcgis_jsapi_hosturl + 'esri/themes/dark/main.css',
};
loadModules(['esri/Map',
'esri/views/SceneView',
], option)
.then(([Map, SceneView]) => {
const map = new Map({
basemap: {
baseLayers: [tiledLayer],
},
});
const view = new SceneView({
container: 'mapViewContent',
map: map,
camera: {
position: [102.492874, 25.236805, 500000],
heading: 0,
},
zoom: 7,
});
}).catch((err) => {
_self.$message('底图创建失败,' + err);
});
},
以上代码可看到,我们通过loadModules来引入了JS API中所需的功能模块,而且以上代码是在一个组件中的,可以看到第一个方法中为了创建一个二维地图,我们用loadModules引入了相关的功能模块;第二个方法中为了创建三维场景,我们又用loadModules再次引入了所需的模块,这样在编码方式上就很繁琐。换句话说,如果我们在什么地方要用JS API中的模块,那我们就要在相应的地方用loadModules引入所需的模块。 @arcgis/cli编码方式解决了这一恼火的问题,我们可直接在组件代码顶部引入相应模块,然后在下面的代码任意地方使用它们,示例代码如下:
import ArcGISMap from 'esri/Map';
import MapView from 'esri/views/MapView';
export default {
name: 'web-map',
mounted() {
const map = new ArcGISMap({
basemap: 'topo-vector'
});
this.view = new MapView({
container: this.$el,
map: map,
center: [-118, 34],
zoom: 8
});
},
beforeDestroy() {
// destroy the map view
if (this.view) {
this.view.container = null;
}
}
};
以上代码可看到,我们只需要在组件代码顶部引入此件组所需要的JS API相应的模块,然后在下方的代码任意位置都可以使用此模块,就没有必要每次都通过Dojo的模块化加载机制来加载了。
esri-loader方式开发JS API项目系统后,如果我们不对项目进行相应的配置,基于Vue框架的项目和基于React框架的项目启动命令是不同的,它们的打包命令却是相同。 @arcgis/cli脚手架创建的项目应用,不管是基于Vue还是基于React,启动命令相同,打包命令也相同,所以更加的友好。 两种方式创建的项目,打包后部署流程一致,并无相关的差异。
就目前四个方面的简单测评来看,如果是一个还未进行实施的项目,并且其中GIS相关功能模块占比较大的情况下,推荐使用@arcgis/cli脚手架方式搭建项目框架,具体coding感受,只有自己去体会一番了。作者力荐@arcgis/cli脚手架方式。