Skip navigation
All Places > Developer Communities > Web Developers > ArcGIS API for JavaScript > Blog

Today, we released versions 4.11 and 3.28 of the ArcGIS API for JavaScript. 


At 4.11, we added an Editor widget, a new GeoJSONLayer, made some significant enhancements to our 3D capabilities, and redesigned the website. Actually, we did a lot more than that, so please check-out our Release Blog and read the 4.11 Release Notes and the 3.28 What’s New from the links below to learn more.

 

ArcGIS API for JavaScript - 4.11

 

Read more here:

 

Release Blog

https://www.esri.com/arcgis-blog/products/js-api-arcgis/announcements/whats-new-in-arcgis-api-for-javascript-4-11-march-2019/

 

New 4.x Website Blog

https://www.esri.com/arcgis-blog/products/js-api-arcgis/announcements/a-better-experience-with-the-new-arcgis-api-for-javascript-website/

 

4.11 Release Notes

https://developers.arcgis.com/javascript/latest/guide/release-notes/index.html

 

4.11 Samples

https://developers.arcgis.com/javascript/latest/sample-code/index.html?search=4.11

 

3.28 What’s New

https://developers.arcgis.com/javascript/3/jshelp/whats_new.html

Today we released versions 4.10 and 3.27 of the ArcGIS API for JavaScript. Read more about it in:

 

and even more details in

Today we released versions 4.9 and 3.26 of the ArcGIS API for JavaScript. Read more about it in:

 

and even more details in

https://developers.arcgis.com/javascript/3/jshelp/whats_new.html

Support for CORS will be enhanced in 4.9 and will potentially require changes to your code. Read further for the full scoop on this.

 

The ArcGIS API for JavaScript has long supported CORS. CORS allows web applications to bypass a browser's same origin policy and access resources or services on other servers/domains.

When the web server supports CORS, a proxy is not required to do cross-domain requests. Supporting CORS as opposed to using a proxy is helpful as it can:

  • Provide a performance boost since the web application no longer has to send a CORS detection request back to its server, wait for the server to access the desired resource, and interpret the result before sending it back to the client.
  • Simplify development as it is no longer necessary to maintain a proxy on your server. Avoiding the use of a proxy also ensures that web tier authentication (i.e. Active Directory) can be used when accessing secured resources.

 

CORS and WebGL

There are multiple scenarios when either CORS or a proxy is needed due to cross-domain requests for a resource. CORS is more important now than ever before when using the ArcGIS API for JavaScript due to the API’s use of WebGL. Thanks to WebGL, the API can render hundreds of thousands of features with fast performance using the GPU. However, WebGL has different requirements than the traditional method of rendering using SVG. When loading images (such as an image used by PictureMarkerSymbol), SVG simply adds an image in the DOM, while drawing on the WebGL canvas requires access to the raw image data. Since the raw image data is required for rendering, the image must meet one of the following requirements: (1) be on the same domain as the app, (2) be hosted on a server that supports CORS, or (3) a proxy must be used.

 

With WebGL becoming the primary way in which the API renders graphics and its requirement to access raw image data, we’ve optimized the way in which we approach CORS.

 

Changes to how the API will handle CORS, starting at 4.9

The API will assume web servers support CORS. Here are the details behind how the API handled CORS until 4.8, and how it will change starting at 4.9.

 

Previously, the API would handle CORS in the following way:

  • Developers could predefine a list of corsEnabledServers to explicitly indicate whether CORS was setup for a given server.
  • If the service was published with ArcGIS Server, the API would automatically send a request to see if CORS was supported (note: this resulted in an extra request to the server before a resource could be requested).
  • If the server didn’t support CORS, a proxy rule could be configured (note: this resulted in the extra hop and performance hit described above).
  • JSONP was used as a workaround when the server wasn't known to support CORS and the request was a GET request for JSON. An example would be using a FeatureLayer from an ArcGIS Server version 10.0 or earlier.

If none of the above criteria could be met (not listed in corsEnabledServers, not an ArcGIS Server service, and no proxy setup), the API didn’t make the request to the resource and generated a console error.

 

Starting at 4.9, the API will handle CORS in the following way:

If you have configured a proxy rule in your code, the API will continue to use your proxy. Otherwise, requests will always be made with the assumption that CORS is supported.

 

Assuming CORS support is particularly useful when you don’t know what web servers you might be accessing in advance, for example in some scenarios when loading a web map with a mash-up of services. The first request will be sent assuming CORS is supported, and if the request fails due to the lack of support the API will automatically fallback to the configured proxy (via the proxyUrl property in esri/config.request).

 

This change also results in a performance gain when working with ArcGIS Server because it is no longer necessary to send a CORS detection request before accessing a resource (in the case when the server isn’t listed in corsEnabledServers).

 

What do you need to do?

 

  • If it doesn’t already, configure your web server to support CORS (if possible).
  • Another change at 4.9 is support for JSONP is being removed, which will simplify webpack builds. If your server doesn’t support CORS, setup your proxy so that the app would fallback to using the proxy when the CORS request failed. If you have a specific requirement for using JSONP, you can use the dojo request script module as a workaround.
  • If you previously used any of these APIs, they should be removed as they are no longer needed. Your CORS enabled server should “just work” since the API will make the request assuming CORS support.

esri/config.request

corsDetection

corsDetectionTimeout

corsEnabledServers*

forceProxy

useCors

 

esri/request

allowImageDataAccess option

 

* If your app is using corsEnabledServers with objects that have withCredentials: true, you should push the domain to esri/config.request.trustedServers instead.

 

This guide topic will be updated with the latest information about working with CORS after the 4.9 release.

We recently published a series of blogs (with one more to go) aimed at helping JavaScript developers wanting to migrate from Google to ArcGIS come up to speed on the JS API:

 

Have you gone through the experience of migrating from Google or are you considering starting the process? This GeoNet post serves as a way in which you can provide feedback on the above blogs, as well as share your experience coming up to speed on ArcGIS. How can we help?

Today we released versions 4.8 and 3.25 of the ArcGIS API for JavaScript. Read more about it in:

 

and more details in

Today we released versions 4.7 and 3.24 of the ArcGIS API for JavaScript. Read more about it in:

 

and more details in

New ArcGIS API for JavaScript releases are just around the corner! Here is a preview of some of the new capabilities coming in early July. 

(Note: These are some of the highlights; a full list of new capabilities and enhancements will be provided in the release notes.)

 

ArcGIS API 4.4 for JavaScript

New styles for points in city landscapes:

Styling the point data in city scenes can now be done more effectively. Point graphics can be configured to display above buildings with the new relative-to-scene elevation mode. Callout lines can be used to better understand point locations (a callout is essentially extended from the top of the scene).

 

Highlight in 3D:

The ability to highlight features in a 3D scene, with options to configure the color and opacity of the highlight effect.

 

Styling building data:

We added the option to remove building textures to better emphasize thematic mapping of buildings, and also the option to make textures grayscale (one example of when you might want to do this is if you want to draw attention away from the buildings, and highlight a particular set of interest).

 

Smart Mapping

You can now automatically generate renderers for SceneLayers using SmartMapping. Generating type renderers with smart mapping is new to both 2D and 3D views. Note: When we reference smart mapping/generating renderers, we mean that the API creates smart defaults for your map/scene styles on the fly. This capability is typically used in data exploration type apps (as opposed to defining the styling explicitly in code).

 

PointCloudLayer enhancements

Added the ability to add natural lighting conditions to a point cloud layer in order to better distinguish objects.

 

Better web map support

Added support for Map Notes, WMS, and WMTS layers.

 

OGC support

Added support for WMS and WMTS layers.

 

VectorTileLayer printing

This release of the JavaScript API includes a support for vector tile layer printing through client-side image.

 

Arcade support in popups

Arcade expressions can now be applied in the popup’s content. This is useful for situations when you want to display data that isn't present as an attribute value in your FeatureLayer instance. Web maps that have been created in Portal or Online that contain popups with Arcade expressions will be honored in apps built with the JS API, and developers can also write Arcade expressions directly in their code.

 

Widget standardization

In this release, the following widgets have been updated to the widget framework, initially introduced at 4.2: Legend, Popup and Search widgets.

 

Custom Layers

The SDK will include documentation and samples for creating your own custom layers. 

 

ArcGIS API 3.21 for JavaScript 

Arcade support in popups

As described above.

 

VectorTileLayer printing

As described above.

 

(...plus minor enhancements and bug fixes)

 

 

When the 4.0 version of the ArcGIS API for JavaScript was released, we also released a Bower compatible minified version of the API for users interested in doing their own custom local builds. This was a big step in our direction to help users integrate the ArcGIS API for JavaScript into their own workflows.

We have since had numerous requests to publish the ArcGIS API for JavaScript to NPM. One of the reasons we have not done this is that Bower provides us with some advantages when it comes to creating custom local builds. Publishing the API to NPM will not automatically make it compatible with build tools like Webpack. It actually adds a couple of steps to the Dojo build needed to compile the ArcGIS API for JavaScript.

With the upcoming release of 4.4 we will publish the ArcGIS API for JavaScript to NPM. We will also be providing some updated resources about how to do a Dojo build with the API.

Start using NPM today

However, you could start using NPM today to install the ArcGIS API for JavaScript locally.

Let's start with the sample application provided in the resources repo on github.

Take a look at the bower.json file provided with the ArcGIS API for JavaScript repo.

...
  "dependencies": {
    "dojo": "Esri/dojo#v1.12.1/esri-3.20.0",
    "dojox": "Esri/dojox#v1.12.1/esri-3.20.0",
    "dijit": "Esri/dijit#v1.12.1/esri-3.20.0",
    "util": "Esri/dojo-util#v1.12.1/esri-3.20.0",
    "dgrid": "Esri/dgrid#v1.1.0/esri-3.20.0",
    "dstore": "1.1.1",     "moment": "2.17.1"
  },
...

We can borrow most of this for our package.json of our custom application.

...
  "dependencies": {
    "dgrid": "Esri/dgrid#v1.1.0/esri-3.20.0",
    "dijit": "Esri/dijit#v1.12.1/esri-3.20.0",
    "dojo": "Esri/dojo#v1.12.1/esri-3.20.0",
    "dojo-dstore": "^1.1.1",
    "dojo-util": "^1.12.2",
    "dojox": "Esri/dojox#v1.12.1/esri-3.20.0",
    "arcgis-js-api": "Esri/arcgis-js-api#4.3.1",
    "moment": "2.17.1"
  },
...

You can see this looks very similar. Main difference is that util is now dojo-util and dstore is now dojo-dstore, because these are the names of the published packages on NPM. You may also notice that we can bring in the arcgis-js-api repo using Esri/arcgis-js-api#4.3.1. This tells NPM too look on github at the Esri org and install the arcgis-js-api repo using the 4.3.1 release.

At this point you can delete the bower.json and .bowerrc files from the project since they are not going to be used.

One disadvantage of using NPM instead of Bower is that NPM does not allow you to change the name of the folder the package is installed. Meaning that the JavaScript API will installed to node_modules/arcgis-js-api instead of node_modules/esri which would be ideal as far as how we typically use the Dojo build system.

Hint: If you use Yarn instead of NPM, it can install to custom named directories.

Once you NPM install these packages you will have a folder structure that should look something like this.

node_modules/
  arcgis-js-api/
  dgrid/
  dijit/
  dojo/
  dojo-dstore/
  dojo-util/
  dojox/
src/
  app/
    main.js

Now you need to tell Dojo where to locate the packages. You can do this by supplying a global dojoConfig object.

<!-- index.html -->
    <script>
      // point to node_modules folder
      window.dojoConfig = {
        baseUrl: '../node_modules/',
        packages: [
          'dijit',
          'dojo',
          'dojox',
          'dgrid',
          'moment',
          {
            name: 'app',
            location: '../src/app'
          },
          // alias for dstore package
          {
            name: 'dstore',
            location: 'dojo-dstore'
          },
          // alias for esri package
          {
            name: 'esri',
            location: 'arcgis-js-api'
          }
        ]
      };
    </script>
    <script src="../node_modules/dojo/dojo.js"></script>
    <script>require(["app/main"]);</script>

There is one more thing you will need to do your own code in order for this to work. The ArcGIS API for JavaScript uses Web Workers for Vector Tiles. You will need to let the workers know where the esri package is located in order for them to function. You can do this in the following manner using esri/config and dojo/has.

//app/main.js
if (!has("dojo-built")) {
  esriConfig.workers.loaderConfig = {
    paths: {
      "esri": "../arcgis-js-api"
    }
  };
}

The reason we use dojo/has is that once the application is built, the Dojo build system will install the esri package into an esri folder and not arcgis-js-api. So we only need this configuration during the development process.

Now you can develop your application using the JavaScript API installed in node_modules.

When you do your Dojo build, you will need to do something similar. However, the Dojo build is expecting the build tools to be located in a folder called util, but they are in fact installed in a folder called dojo-util. This requires you to create a dojoConfig for the build system in the root of your project.

// dojoconfig.js
dojoConfig = {
  baseUrl: './node_modules/',
  packages: [
    {
      name: 'dojo',
      location: 'dojo'
    },
    {
      name: 'build',
      location: 'dojo-util/build'
    }
  ]
};
require('./node_modules/dojo/dojo.js');

Then to run your Dojo build from the command line you can use node dojoconfig.js load=build --profile build.profile.js --releaseDir ../dist.

This will now tell Dojo where to find the build tools needed.

You will also need to update the build.profile.js to reflect the new locations of the packages.

// build.profile.js
  packages: [
    // "app" is a sample path for your application
    // set this accordingly
    "app",
     {
       name: 'dijit',
       location: '../node_modules/dijit',
       trees: [
           // don"t bother with .hidden, tests, min, src, and templates
          [".", ".", /(\/\.)|(~$)|(test|node_modules)/]
       ]
     },
     {
       name: 'dojo',
       location: '../node_modules/dojo',
       trees: [
           // don"t bother with .hidden, tests, min, src, and templates
          [".", ".", /(\/\.)|(~$)|(test|node_modules)/]
       ]
     },
     {
       name: 'dojox',
       location: '../node_modules/dojox'
     },
     {
       name: 'dstore',
       location: '../node_modules/dojo-dstore',
       trees: [
           // don"t bother with .hidden, tests, min, src, and templates
          [".", ".", /(\/\.)|(~$)|(test|txt|src|min|templates|node_modules)/]
       ]
     },
     {
       name: 'dgrid',
       location: '../node_modules/dgrid',
       trees: [
           // don"t bother with .hidden, tests, min, src, and templates
          [".", ".", /(\/\.)|(~$)|(test|node_modules)/]
       ]
     },
     {
       name: 'esri',
       location: '../node_modules/arcgis-js-api'
    },
     {
       name: "moment",
       location: "../node_modules/moment",
       main: "moment",
       trees: [
           // don"t bother with .hidden, tests, min, src, and templates
          [".", ".", /(\/\.)|(~$)|(test|txt|src|min|templates)/]       ],
       resourceTags: {
         amd: function(filename, mid){
           return /\.js$/.test(filename);
         }
       }
     }
   ],

Notice the addition of the trees array for each package. This lets the Dojo compiler know which files and folders to ignore so it doesn't try to include tests and documentation in the build process.

Summary

So if you are interested in using NPM to install the ArcGIS API for JavaScript locally today, these are the steps you would need to take. All this is still valid once we publish the JavaScript API to NPM, except you will only need to install the arcgis-js-api package by name and not need to install the other dependencies yourself. Bower does provide us with a distinct advantage when it comes naming the folders and locations that packages are installed, but NPM allows to keep all dependency code in a single location.

Please note, that if you want to use RequireJS and the RequireJS Optimizer to build the ArcGIS API for JavaScript, you should continue to use Bower as some of the required build tools cannot be installed via NPM.

Even once the API is published to NPM, we will continue to provide the Bower release for as long as it's sustainable since it's all the same codebase.

 

 

Contributed by Rene Rubalcava !

Jerome Yang of the JavaScript team has written some great blog posts on data visualization with the ArcGIS API for JavaScript.  Post one in the series is an introduction to the topic. Post two covers unique value renderers and Post 3 discusses adding support for popups and legends.