Latest Contributions by AndyGup

Hi John, here's a proof-of-concept app showing how to use JS API 4.x ES modules with webpack 5 and Electron 11.2: https://github.com/andygup/electron-esri-map. This demonstrates that the underlying integration with webpack and electron is possible. What will be challenging is figuring out the right configuration permutations to get Angular, JS API ES modules, Webpack and Electron all to work together into one application.  With regards to writing unit tests, we will have a session at the upcoming 2021 Developer Summit includes insight on writing unit tests with JS API ES modules and Angular 11. ... View more

Oh! We usually refer to that action as panning and zooming. Typically "drag and drop" indicates using the cursor to lift individual features from one location and set them down in another location on the map. I was not able to see pixelation other than some temporary and normal fading-in as the various map tiles loaded. One suggestion is to verify your CPU and memory usage while panning and zooming. ... View more

Gotcha, can you share a stackblitz or, preferably a non-Angular codepen that reproduces the issue? You'll need to share a working example so we can figure this out. ... View more

Hi, have you tried to reproduce the issue in a non-Angular, plain old HTML/JavaScript app? Do you have a public sample I can take a look at? Depending on what your code is doing, there's a slim possibility you could be running into a component change detection issue. An easy thing to try is to run your mapping code outside of Angular, for example: https://github.com/Esri/angular-cli-esri-map/blob/arcgis-webpack-angular/src/app/esri-map/esri-map.component.ts#L159. ... View more

Quick follow-up: We did some testing and found a 4.17 regression where GroupLayer is not visible on the view if it contains feature collection. We've opened an issue for this and we'll investigate if we can fix for 4.18 (which will be released in a few weeks). We weren't able to reproduce any performance issues using this test app: https://codepen.io/U_B_U/pen/XWjXped?editors=1000. I also tested the same code using Angular 11 (I can only verify against the latest version) and it ran fine.  We didn't see any re-ordering issues with any layers in a GroupLayer. Please share a sample that reproduces the issues you are seeing and we'll take a look. ... View more

Hi, can you share a stand-alone, non-framework sample that reproduces the GroupLayer issue(s) using the CDN? Offhand we weren't aware of any bugs similar to what you are describing, it would be great to narrow down the problem. ... View more

Awesome, glad it's working again for you. We are also working on a fix and doing additional testing.  ... View more

Thanks for reporting, sorry you are having issues. Tech Support is investigating and I'll pass on your additional information. ... View more

Hi Jay, thanks for reporting this, we are aware. There's a possibility that a general fix already being working on for Accessor in 4.18 might fix your issue. I'm not sure exactly when the fix will be checked in, but you will be able to test it out on /next build prior to the production release: https://github.com/Esri/feedback-js-api-next. ... View more

Thanks for clarifying. Based on your additional info it sounds like things are working correctly in the JS API. And, we'll continue to make improvements. Just looking at total system memory usage of an app, it's impossible to see what's really going on. For example, even the browsers themselves can leak memory.  The definitive way to test if the JS API is leaking memory is to run it in a stand-alone app.  ... View more

Hey Andrew, how are you measuring memory usage?  When I use Chrome's "Take Snapshot" I'm not seeing any memory leaks. Here's the workflow I'm using: 1. Load app - take snapshot 2. Open map - take snapshot (pan/zoom around a bit) 3. Close map - take snapshot 4. Repeat steps 2 & 3 Using your repo, I followed this pattern through 12 iterations and everything looks good. You can see the size of the sequential heap snapshots in this screen capture stay fairly consistent in size: ... View more

Hey Andrew, we did a bit more testing in a stand-alone, non-Angular test app and the 4.17 view.destroy() code appears to be working as expected, a few things to know: At 4.17, there will still be some items cached in memory after you call destroy(). For the MapView to be memory efficient it reuses the same instances of certain arrays and other objects. They are created once and reused. The important thing is that memory usage does not increase after the first MapView is created. If your user workflows call for a lot of back and forth between map-related pages and non-map-related routes, we still recommend recycling MapViews rather than destroying them. I think I may have mentioned it in the previous issue, some customers with complex workflows have built a pool of MapViews in an array that lets a limited number of views be recycled. A few things for you to try before you retest: Remove both references to the JS API in your index.html. Esri-loader will take care of lazy loading the JS API when you call loadModules(). Add esri-loader to your package.json file as shown here using some variation of npm install esri-loader@latest.  Remove this line from your package.json: https://github.com/docmur/angular-esri-memory-test/blob/master/frontend/package.json#L39 and delete esri-module-loader from node_modules. This is to make sure you only have one instance of esri-loader in memory. ... View more

Hi Andrew, just confirming, is this issue continuation of your previous issue? At 4.17 there is a known issue with view.destroy() not fully releasing memory. Sorry about that, we've tentatively scheduled a fix for 4.18 in December.  Your code looks correct, just one small note that when you call view.destroy() you shouldn't need to call map.destroy(). With that said, if Angular attaches any references to the MapView.container that could also cause items to be retained in memory and the ArcGIS JS API has no control over that. Once we have a fix in place for view.destroy() it will be much easier to test for Angular related issues. ... View more

Gotcha, full page refresh would definitely free the memory up however I'm sure that's not your preferred approach. So, some good news is we just added a view.destroy() method in the /next build of the JS API that you can test it out before the next release (4.17 - Early October 2020): https://github.com/Esri/feedback-js-api-next. If you have a chance to test it, let us know how if you run into any issues? // Unset map from the view so that it is not destroyed const map = view.map; view.map = null; // Coming in 4.17 - destroy the view and all attached resources view.destroy();‍‍‍‍‍‍‍‍‍‍‍‍ ... View more