6

The ArcGIS JS API (version 4.1) uses Dojo's implementation of the AMD module loader. I think it's simplest to use AMD modules in custom code too for compatibility. I'd love to be wrong but my understanding is that there's no escaping Dojo and AMD when using the ArcGIS JS API.

As an app grows it will typically require a large number of AMD modules in order to keep things organized. Dojo is going to make a separate http request for each module. There's going to be a lot of http requests on page load which the user will have to wait for.

I've tried concatenating multiple AMD modules into a single file using a js build tool (incidentally brunch.io) but it seems to be causing "multipleDefine" errors.

I'm interested in suggestions for organizing JS code in an app that uses ArcGIS JS API without making a large number of http requests. Wondering how others have solved this?

  1. Somehow concatenating a large number of AMD modules into a small number of .js files?
  2. Making their AMD modules very large so they don't need too many modules?
  3. Tolerating a large number of http requests to fetch all their AMD modules?
4

You'll want to use the dojo build system to make a single javascript file from AMD dojo projects. Simply concatenating files is not enough as you found out with the multiple defines.

There are many, many, examples of how to do this with the esri js api.

We use bower to bring in the arcgis-js-api and then we use grunt with the grunt-dojo task to automate the process.

This is a presentation my coworker gave a while back explaining the process. Things are better now since we don't need to slurp the files because esri published to bower.

Good luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.