[Evaluation] using @ arcgis / cli scaffolding and esri-loader mode for evaluation ArcGIS JS API development

Outline

Later when I wrote esri-loader only way to ArcGIS JS API development article, wrote @ arcgis / cli scaffolding way to ArcGIS JS API development article, I believe that many small partners will have after seeing the "Select tangle disease ", in the end I what way to develop ArcGIS JS API it? Do not worry, I'll give you a reference for selection, simple and practical:

  • If the project is already under implementation, the middle may need to use ArcGIS JS API relevant functional modules, then select esri-loader mode;
  • If the project has not started, but later there will be demand for ArcGIS-related functions in the JS API recommended @ arcgis / cli scaffolding, of course, you can also use esri-loader mode.

Since there are two ways to choose, then we simply look at the advantages and disadvantages of these two methods.

 

Assessment related content

1, the actual project implementation

According to the article said at the beginning, if the project has been implemented, we can only be developed by JS API esri-loader manner, because the JS API only be introduced into the latter part of the project, our project may not be a whole GIS projects, GIS-related functional modules is only a small part of the system, so we have no need to build a complete WebGIS-based framework of the project with @ arcgis / cli scaffolding, it will affect the system architecture should make the system robust architecture greatly reduced.

If the project has not started implementation, and clearly knows this system will be functional requirements related to the late JS API, and this project GIS system related functional modules larger proportion, it is recommended to use @ arcgis / cli scaffolding to build the project system framework, because we can see the scaffolding built by the project application code organization is very good, and based on Webpack equipped with a complete mainstream system building tools and code checking tool.

2, mainstream technology

When the JS API developed by esri-loader mode, in fact, in many cases we are still using encoding ES6 even ES5 of system development, all major plug-in project system is used to increase the allocation to our initiative, in other words, if you do not know what is the mainstream technology, you have been eating or technology savings, the system does not project into the mainstream of development technology.

@ Arcgis / cli scaffolding not the same way, it is the default in your project code configured Eslint, babel and other mainstream plug-ins, and most importantly, its project code is TypeScript to write, so these points of view scaffolding way to develop JS API in the process of developing the technology used is relatively close to the stage of development of mainstream technology.

3, encoding

esri-loader encoding As previously mentioned, you may use ES6 or ES5 during system development, then we JS API in various functional modules based on AMD or use Dojo way to load, and it is difficult to achieve the global introduction of loaded code as follows:

		// 创建二维地图
        _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);
                });
        },

The above code you can see, we have to introduce the required functional modules by JS API loadModules, and the above code is in one component, you can see the first method in order to create a two-dimensional map, we introduce a loadModules the relevant functional modules; the second method for creating three-dimensional scenes, we use loadModules reintroduced the required modules, so it is cumbersome in the encoding. In other words, if we are somewhere in the API module to use JS, then we have the required modules introduced by loadModules in the appropriate place.

@ Arcgis / cli coding annoyed solve this problem, we may be introduced directly on top of the respective module assembly code, and then use them anywhere in the code below, the following sample code:

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;
      }
    }
};

This code can be seen, we just need to set the appropriate module required for this member JS API component code introduced at the top, then this module can be used anywhere in the code below, it is not necessary in every modular Dojo loading mechanism to load up.

4, the project up and running and package deployment

After esri-loader way to develop JS API project system, if we do not project the appropriate configuration, start a command based on project-based React Vue framework and the framework of the project is different, their packaging is the same command.

Project applications @ arcgis / cli scaffolding created, or whether it is based on Vue React, the same start command, packaging commands are the same, so the more friendly.

Project created in two ways, consistent with the package deployment process, there is no relevant differences.

5, other aspects of the follow-up encounter after the update is ......

 

to sum up

Simple evaluation of the current four point of view, if a project has not been implemented, and in which the proportion of GIS-related functional modules is large, it is recommended to use @ arcgis / cli way to build a scaffolding framework of the project, specific coding experience, only themselves to experience some of the. Authors strongly recommend @ arcgis / cli scaffolding manner.

Published 138 original articles · won praise 201 · views 280 000 +

Guess you like

Origin blog.csdn.net/qq_35117024/article/details/104616723