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

Today, we are pleased to release versions 4.13 and 3.30 of the ArcGIS API for JavaScript. Here are some of the 4.13 highlights (please refer to the 3.30 link at the end for 3.x updates).

 

The Stats

We added 18 new classes, 4 new widgets, and fixed 33 bugs. Also, 96% of the codebase is now written in TypeScript.

 

ArcGIS API for JavaScript - 4.13

 

Attribute driven composite symbols

Wouldn’t it be sweet to symbolize features using a dictionary of symbols configured with multiple attributes? Well, now you can. With the new Dictionary Renderer, we offer a data-driven approach for symbolizing features when there are so many permutations that a UniqueValueRenderer would be inappropriate.

https://developers.arcgis.com/javascript/latest/guide/release-notes/#attribute-driven-composite-symbols

 

Performance

VectorTileLayers? They now draw faster and smoother with fewer network requests.

SceneLayers? Now twice as fast with half the calories.

FeatureLayers? More stable z-ordering and faster rendering of large polyline and polygon features.

https://developers.arcgis.com/javascript/latest/guide/release-notes/#performance-improvements

 

Modernization

We are planning to make the API return native Promises by default at 4.14, then completely remove Dojo promise at 4.15. We are also planning to remove the dependency on Dojo's `declare` module. These are significant changes that will both strengthen the API and make it play nicer with other frameworks. This release took a large step forward laying the foundation for these changes.

https://developers.arcgis.com/javascript/latest/guide/release-notes/#api-modernization

 

ImageryLayer

First, we reduced the number of files requested from CDN. But we didn’t stop there. You can now display images in ImageryLayer in their original coordinate system. And if the format is set to `lerc`, we now offer a client-side renderer.

https:// developers.arcgis.com/javascript/latest/guide/release-notes/#imagerylayer-updates

 

ArcGIS API for JavaScript - 4.13

 

And more...

There’s so much more to cover. Add, edit, delete, and reorder bookmarks with the Bookmark widget. PointCloudLayer now supports popups. One measurement widget to rule them all. Even better smarter mapping!

 

It’s been a fantastic release, and we are excited to share it with you. Please feel free to let us know how we’re doing via email/Slack/GeoNet/Twitter.

https://developers.arcgis.com/javascript/support/index.html

 

Couple more links to share:

 

Release Blog

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

 

Measurement Widget Blog

Measure Once with the new Measurement Widget 

 

4.13 Release Notes

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

 

4.13 Samples

https://developers.arcgis.com/javascript/latest/sample-code/?search=4.13

 

3.30 What’s New

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

Today, we are pleased to release versions 4.12 and 3.29 of the ArcGIS API for JavaScript. Here are some of the 4.12 highlights (please refer to the 3.29 link at the end for 3.x updates).

 

The Stats

We added 42 new classes, 11 new widgets, and fixed 34 bugs. Also, 93% of the codebase is now written in TypeScript.

 

TimeSlider

 

Time

Time is a key component of this release. We added a TimeInterval class to describe a length of time in different temporal units, a TimeSlider widget to simplify time manipulation in your application, and a timeExtent property in 2D MapViews and 3D SceneViews to easily update all time aware layers.

https://developers.arcgis.com/javascript/latest/guide/release-notes/#time

 

Performance

Loading, rendering, fetching, drawing, all these verbal nouns saw significant improvements with this release. Parallelization of requests. Tile processing optimizations. We’re talking revamped tessellators folks. Who wouldn’t want the new I3S specification version 1.7 to make your scene layers load 2x faster? Or how about pure client-side queries in 3D that don't require a round-trip to the server?

https://developers.arcgis.com/javascript/latest/guide/release-notes/#performance-improvements

 

Modernization

We take major strides to modernize our API at every release. This modernization allows our API to play nicer with others (e.g. other frameworks, native browser methods, and 3rd party APIs). This time around we made the BeforeInterceptorCallback function asynchronous, so it can now also return a promise. In fact, most asynchronous methods in the API now support an optional abort signal parameter, so they can be canceled and return a promise that will be rejected with an error. Lastly, there is a new has flag available to enable native JavaScript promises. Look out for an upcoming blog post to discuss this further.

https://developers.arcgis.com/javascript/latest/guide/release-notes/#api-modernization

 

Sliders

Note: we’re talking widgets, not small hamburgers. We added a slew of new slider widgets to help you interact with any kind of user input involving numbers or a range of values. You already met the TimeSlider, but we have several more Slider widgets that might interest you, including a base Slider widget, which is a great starting point if you want to make your own customized slider experience.

https://developers.arcgis.com/javascript/latest/guide/release-notes/#new-widgets

 

And More...

There’s so much more to cover. Realistic water rendering with the new WaterSymbol3DLayer. New 2D WebStyleSymbols (used to be only available in 3D)! Scale-dependent visualizations for smart mapping. Even better labeling options and behaviors??

 

It’s been a great release, and we are excited to share it with you. If we don’t see you at the UC in San Diego next week, please feel free to let us know how we’re doing via email/GeoNet/social media. Couple more links to share:

 

Release Blog

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

 

Video: What's new with the ArcGIS API for JavaScript 4.12

https://www.youtube.com/watch?v=J7LPAQx8IBg

 

4.12 Release Notes

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

 

4.12 Samples

https://developers.arcgis.com/javascript/latest/sample-code/?search=4.12

 

3.29 What’s New

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

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.