Hello,
I have been using the JavaScript api in an angular app since 4.17, I was able to work with TypeScript and the builds are working fine with WebPack, when 4.18 became available, I decided to ditch our reliance on the WebPack scripts that were being used, and went with the 'supported' method of copying the assets and referencing them via esriConfig.assetsPath, That was working great after some trial and error, and now that 4.19 is out and 'production ready' we wanted to move away from the reliance of having to deploy all the assets with the web app (deployed to containers, so an extra ~20MB per deploy would be good to get rid of).
I removed the line that was setting the assets path, removed the copy of assets locally and updated the reference to the CSS stylesheet. all is _almost_ well; the app loads, requests are made to the assets, paths are correct, BUT I am getting CORS errors from the ESRI servers when trying to load the assets (js.arcgis.com)? I can manually navigate to the links just fine, so I know the paths are correct, but the webmap won't load any esri widgets, all my custom code is working fine, Portal items are loaded and display, but any request to the javascript assets fail with the CORS error (just one example):
Fonts and CSS from the CDN work just fine (main.css, icon for basemap widget, font file all get sent down fine).
I can go back to using the local assets, but since that is ~20MB, I would really like to avoid having to depend on it to make the maps work. Thanks for any help!
Solved! Go to Solution.
I have a couple questions on the CORS errors. There's nothing in the ArcGIS JS API that should be triggering preflight:
I understand the desire to reduce the on-disk size, but depending on what you find, you may have a good case for sticking with local assets.
Hi @Anonymous User Do stand-alone webmaps load okay directly in your local browser?
outside of an angular app? I have not tried yet. but I did spin up an empty angular 11 app to do some testing (for another project), and I am having the same issue. I will try to spin up a non-angular test app this evening and see if I am still getting the errors
Yes, I meant using the ArcGIS Online MapViewer. For example, can you load this webmap in your browser? https://jsapi.maps.arcgis.com/apps/mapviewer/index.html?webmap=e691172598f04ea8881cd2a4adaa45ba
ok. Yes, that link works/loads for me in the browser. The odd thing is. this setup was working for ~1 week before I started noticing the CORS errors. I did a couple of days of testing locally before I pushed my code changes to the test site, and it was working there for at least a few more days before the errors started.
so, update on this. my standalone angular app appears to be working correctly now (no CORS errors). so it appears to be isolated to the other, more complex app. I will do some more troubleshooting to see if I can track down what in the application could be causing this. Thanks!
update #2:
I no longer get CORS errors in the standalone app, but I am getting a 'version mismatch' warning:
[esri.core.workers] Version mismatch detected between ArcGIS API for JavaScript and assets:
API version: 4.19 [Date: 20210422, Revision: d399841c]
Assets version: 4.19 [Date: 20210504, Revision: dd3facdb]
but in another app that was recently updated to the 4.19 release, I am getting the CORS errors as well. it appears to be that when the map is behind some sort of (non-esri) login system, it starts breaking?
On the version mismatch, we a couple of patches, and it just lets you know. Since it's still 4.19, you should be ok. Warnings won't break anything. You can point to the correct version of 4.19 using jsdelivr as described here.
Thanks for the info! I wasn't too concerned since it was just a warning and nothing else seemed to be impacted, but wanted to make sure it wasn't some fundamental issue with how I was going about things.
I have a couple questions on the CORS errors. There's nothing in the ArcGIS JS API that should be triggering preflight:
I understand the desire to reduce the on-disk size, but depending on what you find, you may have a good case for sticking with local assets.