Latest Contributions by AndyGup

It's been a while since I used Jest with Angular and no guarantee that it will work, but you may need to do something like this in your Jest config: "transformIgnorePatterns": [    "node_modules/(?!(@angular|@arcgis|@esri|@stencil/)" ], And, you might also need: https://www.npmjs.com/package/jest-preset-angular. ... View more

Hi @hectorsalamanca you might try using esriRequest instead, it uses native fetch: https://developers.arcgis.com/javascript/latest/api-reference/esri-request.html#esriRequest. Here's a working example that uses the pattern: https://github.com/Esri/jsapi-resources/blob/main/esm-samples/jsapi-node/src/request.mjs. ... View more

Hi @mbussey, that's correct - if you install 4.23.7, then it will include watchUtils. ... View more

@JonathanTiuI I verified in Charles while using Chrome that the SDK's wasm requests are being correctly cached. Chrome 119 dev tools appear to be incorrectly reporting cached file requests as HTTP 200s. Here's a screenshot: Also, the wasm scripts are being loaded correctly (synchronously). This is the pattern defined by the WorkerGlobalScope of the browser's Web Workers API,. More information is available on MDN here: https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts. As you may know, when stalls are reported in the network tab of the dev console, they can be the result of many different factors. Taking that into account, I didn't see anything unusual after multiple tests. We will continue to investigate the size of the workers. ... View more

@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