Latest Contributions by AndyGup

This might be an issue with the Angular syntax that you are using. Here's an example codepen using the ArcGIS ESM CDN (for prototyping-only) that shows getElementById() working: https://codepen.io/andygup/pen/poBxxxw?editors=1000. With Angular try using "@viewChild": https://angular.io/api/core/ViewChild. And, here's an example usage of viewChild with "@arcgis/core":  https://github.com/Esri/jsapi-resources/blob/main/esm-samples/jsapi-angular-cli/src/app/app.component.ts#L28 @ViewChild('mapViewNode', { static: true }) private mapViewEl!: ElementRef;   ... View more

Hi @SaurabhUpadhyaya I see you have two recent questions that mention errors related to WebGL contexts. This most likely is related to your ArcGIS code and not an issue with React. Your best option is to provide a vanilla JS codepen using the ESM CDN: https://github.com/Esri/jsapi-resources/tree/main/esm-samples/jsapi-esm-cdn. That way we can all take a look and provide suggestions. Note, the ESM CDN is for testing and prototyping, only. It doesn't offer the performance of a locally built ESM app. ... View more

I'm not seeing those skips on my local build. Please post a link to a repro sample. ... View more

We haven't seen that error before with Angular/esbuild. Can you provide a repro app so we can examine it in more detail? ... View more

Hi @ForrestLin you'll need to provide a repro app. We recommend using our esm-samples as a starting point: https://github.com/Esri/jsapi-resources/tree/main/esm-samples/jsapi-angular-cli. Here's our troubleshooting guide for local builds for more info: https://developers.arcgis.com/javascript/latest/troubleshooting/. ... View more

> What is the well-known limitation of ES modules you mention I mentioned it above. Basically, unbundled ES modules (ESM) such as "@arcgis/core" typically perform poorly in a production environment. We are constantly optimizing the ArcGIS JS Maps SDK, however ESM builds require a combination of treeshaking, lazy-load and code splitting (chunking) to create an optimal build output. This isn't specific to ArcGIS, for example you can read about why bundling is recommended in the Vite.js documentation:  https://vitejs.dev/guide/why.html#why-bundle-for-production. > Hence, far and away the biggest improvement I could get in build performance, is an approach that doesn't always re-build the ArcGIS library dependency. Vite.js could really help with your use case of having fast(er) build times. Vite does dependency pre-building to dramatically speed up builds: https://vitejs.dev/guide/dep-pre-bundling. Try this sample app: https://github.com/Esri/jsapi-resources/tree/main/esm-samples/jsapi-vite-ts. On my 5 year old machine it takes 20 seconds for a production build.  For dev builds, it's pretty close to zero on my machine - it takes about 150 - 170ms (milliseconds), and rebuilds are almost instant. And, also to reiterate checking out the new map-components. You can access those via CDN and they include TypeScript types: https://developers.arcgis.com/javascript/latest/components-get-started-cdn/. ... View more

Do you require the Webpack-specific tooling? If not, you might take a look at Vite.js. > The pre-built AMD modules served that scenario, but per above, the TypeScript typings for that are being deprecated. If/when you migrate to (new) map web components, those are typed. > Why is the biggest library I reference (by a huge margin) the only one that doesn't come with a viable pre-compiled option? TL;DR - It stems from a well-known limitation of ES modules. Components will make life much easier in that respect. Currently for ESM there's no ECMA-standard equivalent to the AMD dojo build layers. Those are what makes the AMD ArcGIS CDN much more performant than the ESM ArcGIS CDN. For example, JavaScript module declarations have been in TC39 Stage 2 since 2022, and it could be quite a while before it gets finalized as a standard and then adopted in browsers. ... View more

Hi @JonathanTiu  Yes, we did figure it out. It's related to fine tuning the API and how it uses workers under-the-hood. The size of the workers is just one parameter out of many that affects the initial load performance metrics. Overall, for our baseline testing apps, those metrics improved between 4.27 and 4.29. With that said, if you have a simple, focused repro app that shows a major performance regression on the initial app load, then please open a Tech Support ticket so they can get this formally documented. ... View more

@JasonDoingMapsto speed up your webpack/TypeScript dev builds, you might look into https://www.npmjs.com/package/esbuild-loader. ... View more

Hi @AndresKasekamp  you'll need to do further testing by removing '@arcgis/core' functionality and calcite elements one-by-one to try and find the root cause. Otherwise there's too much going on in the sample including the calcite react wrapper, calcite-panel, calcite-shell, calcite-shell-panel and various '@arcgis/core' modules. ... View more

Update: the Angular team merged the bug fix. Now we wait for the next release of zone.js. ... View more

Hi @boa_panter please see my comments and post additional information in this other thread: https://community.esri.com/t5/arcgis-javascript-maps-sdk-questions/zoom-buttons-don-t-work-in-angular-map-component/m-p/1398115/highlight/true#M84074.  ... View more

Thanks for StackBlitz. See the discussion here for more information on this Angular bug and our suggested (potential) workaround: https://community.esri.com/t5/arcgis-javascript-maps-sdk-questions/zoom-buttons-don-t-work-in-angular-map-component/m-p/1398110#M84073 ... View more