Latest Contributions by AndyGup

@JonathanTiu  with regards to the increased init.js request times, thanks for the information. That might be related to a size increase in the worker between 4.27 and 4.28. I can also repro dev tools reporting the init.js requests being stalled when caching is enabled. We need to do some research. I'll open an issue pending some initial investigation. It's not clear what's actually happening versus what might be misreported in dev tools, e.g. 200 vs 304 status response codes. ... View more

Hi @JonathanTiu, you should only see the first request to  https://js.arcgis.com/4.28/esri/core/workers/init.js, depending on how you've configured Charles. You shouldn't see any other subsequent requests to the same modules, e.g. init.js. If the browser is caching correctly, there will only be that one request, confirming that browser caching is working correctly. Did that make more sense? ... View more

Yes, you can use Charles debugging proxy to determine if the requests are being cached for "/esri/core/workers/init.js". Also important, make sure you have unchecked "Disable caching" in the dev tools Network tab. When the browser is correctly reporting worker caching, you will see at least three HTTP requests to "init.js" in the browser console: First - https://js.arcgis.com/4.28/init.js (HTTP 200) Second - https://js.arcgis.com/4.28/esri/core/workers/init.js (HTTP 200) Third - https://js.arcgis.com/4.28/esri/core/workers/init.js  (HTTP 304) Here's a screenshot from Safari, as an example:   ... View more

Hi @JonathanTiu , yes without getting into all the details, generally speaking the number of worker requests (e.g. init.js) spawned at startup is related to the number of CPUs. Perhaps more importantly for your situation, we have previously investigated the browser caching of workers, which is related to the init.js requests you are seeing. We discovered that devtools (e.g. Chrome and Firefox) has misreported subsequent worker requests as HTTP 200's. We had to use Charles debugging proxy to verify they were actually being correctly cached as 304s. I don't currently have it installed but I can install/retest on our end. I did just notice that Safari is correctly reporting 304s. Is this something you can double check on your application? ... View more

Thanks for the suggestion. We aren't sure what might be possible with our current release process, however I did open an internal issue to further discussion. ... View more

Hi @HHAO, did you get any developer console warnings or errors? Can you reproduce this in a vanilla JS app: https://developers.arcgis.com/javascript/latest/sample-code/sketch-geometries/. If you can't reproduce this in a vanilla JS app, please provide a simple, working github repo, Stackblitz or codesandbox. Here's an example Vue app using "@arcgis/core" that's also a good starting point: https://github.com/Esri/jsapi-resources/tree/main/esm-samples/jsapi-vue. And, we'll also need the full OS output for the Linux box, e.g. cat /etc/os-release. ... View more

Hi @DavidJohnson7, are you using @arcgis/core? When an ArcGIS JavaScript Maps SDK app loads, there are variety of HTTP request types depending on what functionality is in your app. These include .js, vector tiles, queries, localization files (json), css and sprites. The JavaScript-based dependencies should only be a relatively small number of the total HTTP requests needed to load your app. Angular 13 uses Webpack, and that typically does a very good job of minimizing the number of SDK JavaScript bundles that are needed for the initial app load. We track this information here: https://github.com/Esri/jsapi-resources/blob/main/esm-samples/.metrics/. I'm not familiar with your architecture, such as number of simultaneous users and hardware sizing. However, with regards to HTTP requests overloading your server, the most definitive approach would be to host the ArcGIS assets locally, and tweak your HTTP caching settings for those assets and the bundled modules. If you don't host the assets locally, then you'll be using the ArcGIS CDN and it's edge server caching rules, which may or may not be appropriate for your unique requirements. Is that something you have looked at? ... View more

Hi @ElhamAmin  This sounds like a Vue.js configuration issue and not related to ArcGIS JS SDK functionality. Vue.js can have some weird caching issues. You might checkout the Vue.js documentation such as this page: https://vitejs.dev/guide/assets.html, or do some related internet searches. ... View more

Hi @JonathanTiu sometimes, some of the internal dependency relationships cause seemingly unrelated modules to be loaded. We do our best to stay on top of addressing unneeded dependencies that could be lazy loaded or treeshaken. The AMD CDN is highly optimized, as far as CDN performance goes. Depending on your use cases, If you have more exacting needs than can be addressed using the CDN, you might also look at using the ES modules via @arcgis/core. Then you have somewhat different control mechanisms (but not necessarily more optimized), by using a local module bundler to create the final on-disk module output. ... View more

Thanks for Stackblitz. I tried a few things and wasn't able to repro the prod build issue. Since it does runs locally, you'll need to dig deeper. Here are some recommendations. - Run and compare 'npm list' on both dev and prod. Make sure both builds have the exact same dependency versions. A small difference in versions could be the cause of the problem, of course. - Run a 'diff' against the main bundle files from both dev and prod. I understand some variable names may change, but try to decipher if there are substantive differences. - Double check that the prod build is using the same bundler configurations. ... View more

@FlockSafety  can you provide a simple repro sample? e.g. github, stackblitz, codesandbox. That error looks like it might be generated by webpack. However, you might also give it a try using our React/Vite sample to create a repro: https://stackblitz.com/github/Esri/jsapi-resources/tree/main/esm-samples/jsapi-react?file=README.md. ... View more

@TYoung  have you tried getting the API key to work in a vanilla JavaScript app yet? For example, you can also use the ESM CDN for testing purposes: https://github.com/Esri/jsapi-resources/tree/main/esm-samples/jsapi-esm-cdn. ... View more

Yes, you seem to be on the right right track for integrating the CustomContent Class: https://developers.arcgis.com/javascript/latest/api-reference/esri-popup-content-CustomContent.html.  The CustomContent.creator function can be used to return an HTMLElement. In  your case this will be an Angular component. You'll need to pay attention to data binding and component life-cycle. Experiment and see how it goes. Please post your findings here so others can learn, or others may have already gone down this path and respond back. ... View more