Having trouble pointing to locally hosted Esri API "There was an error attempting to load ..."

[petemahoney]

We are experimenting with the esri-loader and I can get it to work but only when I point the url to a cdn hosted version of the API. Our applications all have to hit an internally hosted copy of the arcgis js api - we can't use CDN. When I point the esri-loader to the internally hosted api:

esriLoader. loadModules(["esri/arcgis/Portal", "esri/arcgis/utils", "esri/config"], { url: "https://localhost/esri/" }) .then([Portal, utils, config]) => { // do cool stuff });

I get and error in the console:

Uncaught (in promise) Error: There was an error attempting to load https://localhost/esri/ at HTMLScriptElement.onScriptError (esri-loader.js:76)

I'm guessing that the locally hosted version of the API isn't quite what this package is expecting? We build it using the bower version of the API.

The bower.json file we use to create that internal copy of the arcgis-js-api has the following in the bower.json file.

{ "name": "esri-internal", "authors": [ "xxxxx" ], "description": "Local ESRI JSAPI resources for apps", "main": "", "keywords": [ "ESRI" ], "license": "\"\"", "homepage": "https://xxxxxxx/browse", "private": true, "dependencies": { "arcgis-js-api": "3.20.0" }, "resolutions": { "dojo": "v1.12.1/esri-3.20.0", "dijit": "v1.12.1/esri-3.20.0", "dojox": "v1.12.1/esri-3.20.0" } }

Would love to use the esri-loader but this is the blocker at the moment. Any idea what might be causing the error? Is this an issue with esri-loader or is it an issue with our internal build of the api? What can I do to debug?

[tomwayson]

First, is your local build working outside esri-loader? I mean, can you copy a simple sample page and point it to your local dojo and have it work?

If so, did you have to create a custom dojoConfig to make that work? If so, are you using that in the esri-loader app? I don't see in the above snippet that you are configuring dojo via options. If instead you're relying on the global dojoCofig, you have to make sure that is set before loadModules() is called.

[tomwayson]

To clarify, esri-loader can work fine w/ a locally hosted build of the API, however it will not work against the bower "source" files.

You need to first run a dojo build of the files you created with bower, serve that build on a server (or localhost) and then point esri-loader at that URL.

[petemahoney]

OK - so this sounds clearly like a problem with my locally hosted ArcGIS JS API - not with esri-loader. And so I guess this issue is really just a way to get some advice from you smart people for how to do a dojo build or specify a dojoConfig. Going to look into that today. That sounds like my two options. We do have other apps that hit this locally hosted API and they do specify a dojoConfig. My initial attempts to make that work for this app which uses esri-loader were not working but have some more time today and will be taking a look.

While I got you though, this particular app we're working on is only going to use a small part of the API (Portal Authentication/login), would it make sense to create a custom build (either with a bower dojo build or web optimizer) of the JS API to improve performance/load time of the app?

[tomwayson]

If you don't need the geodata visualization capabilities of the API (mapping, 3D, etc), you should consider using https://github.com/Esri/arcgis-rest-js

Unfortunately, we don't have a good clean high level doc on auth yet, but take a look at my issue outlining what such a doc would look like: https://github.com/Esri/arcgis-rest-js/issues/316 - that links out the API references and demos that have everything you'd need to do OAuth.

[tomwayson]

get some advice from you smart people for how to do a dojo build or specify a dojoConfig

I haven't done a dojo build since 2015 and I don't plan to do ever do one again, so if your problem is with the build I can't really help you.

If the problem is w/ the config, then post the code you're using to set the config global here and maybe smarter people than myself will materialize.

That sounds like my two options.

Again, if the problem is in running the build, there are other options like the web optimizer or downloading the SDK: https://developers.arcgis.com/javascript/3/jshelp/intro_accessapi.html

[tomwayson]

@petemahoney I'm going to assume you got this working and close this issue. Feel free to re-open if needed.

[petemahoney]

Not sure how to reopen :) But would love to ask one more question if I could.

Still trying to figure out how to get this to run against a locally hosted flavor of the ArcGIS JS API. I have experimented both with downloading the API (https://developers.arcgis.com/javascript/3/jshelp/intro_accessapi.html#download-api) and using the web optimizer builds of the API.

When I point to either one (via the url property of the options object passed to the esriLoader.LoadModules method) I get a 403 error. However when I append init.js to the url for the downloaded version it works. I'm not sure how I got the idea to do that but hoping someone can explain why that works - according to the readme in this repo I shouldn't have to do that so I figure I've got something set up wrong. In the web optimizer build there is no init.js file at all.

I know you also mentioned that I could run a dojo build manually of the bower source files for the API and point to that - not sure I really see the benefit of doing that if I can just download a built version anyway and use that. Other than maybe I'd get to tweak some build settings but I'm not sure that's important to me.

[tomwayson]

according to the readme in this repo I shouldn't have to do that

can you be more specific?

[petemahoney]

in the readme (https://raw.githubusercontent.com/Esri/esri-loader/master/README.md) in the section "Lazy Loading the ArcGIS API for JavaScript" there's an example where the URL is passed in on the options parameter:

const options = {
  url: 'https://js.arcgis.com/3.26/'
};

so that doesn't work for me - when I use my local downloaded built api

const options = {
  url: 'https://localhost/esri-api-v320/'
};

however for some reason it does work when I use

const options = {
  url: 'https://localhost/esri-api-v320/init.js'
};

I don't know what esri-loader does with that url parameter but it only works when I append init.js.

[tomwayson]

Thanks for clarifying.

In your case, https://localhost/esri-api-v320/init.js is the URL for your locally hosted copy of the API and that is what you should use.

This is not an esri-loader issue. If you configured one of the sample pages to point to your locally downloaded copy of the API, you'd have to use <script src="https://localhost/esri-api-v320/init.js"></script>.

The only reason url: 'https://js.arcgis.com/3.26/' works is b/c that server redirects (w/ a 301 no less!) to https://js.arcgis.com/3.26/init.js:

I suspect that your local build does not rewrite or redirect from https://localhost/esri-api-v320/, which is fine. There's no rule that the build output script has to be called init.js nor that you have to set up any fancy rewrites/redirects to hide whatever the file name may be.

[tomwayson]

I know you also mentioned that I could run a dojo build manually of the bower source files for the API and point to that - not sure I really see the benefit of doing that

I wholeheartedly agree. Doing a Dojo build is a non-trivial undertaking, and in my experience is not worth the trouble.

Some might think that they can create a build of the API that only includes the modules they need in the build layer. I've never been able to make a build layer that is any more efficient than the compact build.