Can I use the esri api with require.js?

[DonnieHolmes]

I need to use the esri API within a JavaScript app that is built using require.js + backbone + others (all are a part of a standard internal company toolkit). Does anyone have any examples of how this can be done? I have done some searching on this forum and the internet in general and can't seem to find any concrete examples of how to make this happen.

I should clarify that I have tried to make this happen and can't seem to prevent the AMD loaders from stepping on each other.

Thanks.

Donnie Holmes

[DonnieHolmes]

Have you looked at using Dojo's loader to load your require plug-ins? I'm not sure if they're compatible but it's worth trying:  http://livedocs.dojotoolkit.org/loader/amd#plugins

What do your current requirejs plug-ins do?

Okay, it turns out that those plugins were compatible with the dojo loader. I just needed to create a dojoconfig that pointed to the plugins in the paths property. It seems to be working for me now. Thanks for your help.

[derekswingley1]

Okay, it turns out that those plugins were compatible with the dojo loader. I just needed to create a dojoconfig that pointed to the plugins in the paths property. It seems to be working for me now. Thanks for your help.

That's awesome! Glad you're up and running.

[DonnieHolmes]

Update on my progress:

While I was able to make some pieces of our internal toolkit work reasonably well with the ESRI API (and Dojo loader), I'm going to have to perform some serious surgery on many other pieces. I basically have a scenario where our entire framework (core sdk, ui widget system, unit testing, application loading/management) has a dependancy on our AMD loader (because many components of our framework are built with rjs). It seems like the inverse of this situation (ESRI API being a Dojo "build" and thus having a dependancy on the Dojo loader) is why I'm having trouble loading our internal modules using the ESRI loader... In other words, we have internal "optimized" modules that the Dojo loader doesn't know how to find and the ESRI API has "built" modules that we don't know how to find.

We are a very large organization that has an internal framework and library in place so that everyone is building client apps in a common, consistent manner, and it seems that I'm going to have to deviate greatly from this in order to accommodate the ESRI API. It seems unlikely to me that I would be the only one to ever run across this scenario, so I think it would be a great idea for ESRI to consider providing an "unoptimized"/unbuilt version of the API for greater ease of integration with existing JavaScript apps. At the very least, I think that it's an invalid assumption that forcing consumers of the ESRI API to use the Dojo AMD loader is inconsequential. For my situation, it's obviously causing huge headaches.

I apologize if there are any inaccurate assumptions about optimized AMD module loading in this post. In fact, if there are, please straighten me out. 🙂

[derekswingley1]

Using custom modules with our API is definitely possible, the key is to tell Dojo where to find your stuff, which you do via dojoConfig.packages (or dojoConfig.paths, slightly simpler syntax).

What does your dojoConfig look like? Can you provide an example of a url for your app, where the JS API lives and where your custom modules live?

[DonnieHolmes]

Using custom modules with our API is definitely possible, the key is to tell Dojo where to find your stuff, which you do via dojoConfig.packages (or dojoConfig.paths, slightly simpler syntax).

What does your dojoConfig look like? Can you provide an example of a url for your app, where the JS API lives and where your custom modules live?

So, that part seems to be working fine. I have the packages/paths defined in the dojoConfig. The problem seems to be in that if the modules that are referenced in the dojoConfig have been "optimized" using rjs, there are bits that don't get picked up by the Dojo loader. The inverse is true when trying to load the "built" ESRI modules with the requirejs loader. I think that the problem is that each framework takes a different approach to optimization (i.e. how they combine, consolidate, and reference modules that have been optimized). Please correct me if I'm mistaken about any of this. There doesn't seem to be a lot of info out there about this specific issue - this link is about all I've been able to find.  I'm working on getting access to "unoptimized" code for some of my internal libraries which should allow me to use them w/ the Dojo loader. I think it would be nice if ESRI did the same... gave access to "un-built" versions of the API for scenarios like this. There are bound to be plenty of people that are going to want to integrate the ESRI API into an existing application/process that is already leveraging another AMD loader.

I can't provide a link to any examples that are using our internal toolset. I'll see if I can put together a trivial example of this and post a link at some point soon.

The other part of my problem is that we have an internal build automation tool that automates JavaScript optimization, testing, and many other things. All of these steps are currently dependent on requirejs, so it's looking like I'm now going to have to tear apart our standard builder and create a special build process specifically to accomodate the ESRI API... not exactly ideal. Again, I think that if I had access to an "un-built" version of the ESRI API, none of these problems would exist.

Thanks for your help.

[StevenWaters1]

I agree with Donnie-- it seems like an "un-built" version of ESRI's JavaScript API would be the best way to integrate it into an existing application/process that is already leveraging another AMD loader.

I work for a large institution (a federal agency) that makes extensive use of RequireJS, and we do not have the luxury of making our entire agency switch to using Dojo just so that our maps will be compatible with everything else.

Any comprehensive solutions would be greatly appreciated! Thanks,

[DougCollins]

I also agree with Donnie.  With so many different JavaScript libraries available now, it is sad that ESRI has placed this limitation on its users.  If there is a workaround, then please document it.

[ReneRubalcava]

You may want to take a look at Scotts blog post here
http://geospatialscott.blogspot.com/2013/09/the-esri-api-for-javascriptdojo-build.html

He discusses how he is using the Dojo build system to create single file builds and a big help was that there is a minified, unbuilt version of the api where the URL looks like js.arcgis.com/3.8amd. Since it's unbuilt, it's definitely not for production use, too slow and too many requests, but you could probably figure out how to incorporate it into your r.js build system.

There is also an example showing r.js to turn your modules into single-file builds with the esri js api.
https://github.com/robertd/esri-jsapi-rjs-example

The esri stuff is still coming from CDN, but your own code can be a single built file, including templates.

The former of these two options sounds like it might best assist in your case.