|
POST
|
Hi Michael, Thanks for the question! The link to the codepen is broken, if you don't mind reposting it. The Maps SDK does have an overhead compared to other libraries due to the amount of out of the box functionalities and datasets it supports, as well as the developer experience it provides like property change tracking or client-side querying capabilities. All of which makes building rich applications faster and easier, where you may have to build a lot of custom code with other libs. There are definitely areas to explore on the front of memory optimizations though. For your use cases. The SDK provides different solutions for moving assets. First, I would say, favor using a client-side FeatureLayer instead of a GraphicsLayer (I'm making the assumption this is what the codepen was about). Check the class description section about creating a feature layer from an array of features. That offsets the memory and data processing to a worker. The other option is to use a client-side stream layer. See the section in the StreamLayer class description, as well as this sample, or this one https://codepen.io/ycabon/pen/MYjYYNa?editors=1000 Yann
... View more
02-25-2026
12:19 PM
|
1
|
0
|
291
|
|
POST
|
Hi Sebastian, If possible, instead of creating a buffer geometry yourself, use the Query.distance and Query.unit to send the buffer parameters to the server and let it do it.
... View more
02-24-2026
05:44 PM
|
2
|
0
|
261
|
|
POST
|
Hi, The server you are trying doesn't have CORS headers configured for JavaScript (and the Maps SDK) to correctly fetch the capabilities file.
... View more
02-23-2026
04:31 PM
|
1
|
1
|
207
|
|
POST
|
Hi! There are currently no plans to phase out AMD modules, but we anticipate that this will eventually happen. We're actively monitoring developments in build and bundling technologies and continue to test AMD and ESM support on the CDN. Today, AMD remains very efficient for loading unbuilt applications, though that may evolve. One factor is that we depend on tools like TypeScript, which has announced plans to deprecate AMD output in the future: https://github.com/microsoft/TypeScript/issues/54500 Since the technology landscape can change significantly in just a few years, we want to shield your application code from potential disruptions in how modules are distributed on the CDN. That’s why we introduced the new utility function $arcgis.import() for applications without a build step. While it currently uses AMD modules under the hood, it’s designed to switch to ESM in the future without requiring changes on your side. If you're developing your application using the AMD modules (for example, from the SDK Download) and a AMD build tool like dojo or requirejs, we recommend migrating to ES modules and modern build tools (see the getting started). When we do move forward with deprecating AMD, we will communicate early and provide a clear deprecation period. Yann
... View more
06-27-2025
02:06 PM
|
10
|
1
|
1324
|
|
POST
|
You may see some change in 4.31. We installed an optimization regarding this:
Plus when the layerview queries the feature layer, the layer may have to reproject the geometries if their spatial reference doesn't match the view's.
It's always better to have the Feature Layer spatial reference matching the view's, to avoid reprojection. But if the data is reprojected, the layer keeps the reprojected geometries in memory in a cache for later reuse if mulitple queries need the same geometries in the same out spatial reference. In 4.31, that cache is purged every 5 seconds, so some memory would be reclaimed more frequently.
... View more
12-05-2024
10:05 AM
|
1
|
2
|
2640
|
|
POST
|
Hi Andrew,
I can give you some answer on that. In general, we have a map and layers on one side, and a view and its layerviews on the other. A layerview for a feature layer or stream layer queries or receives data from the layer it is rendering.
For a feature layer backed by a feature service, the data is store remotely on the service. The layerview queries and stores the data in memory. For a stream layer, the layerview receives data from the websocket and stores the data in memory.
Now for the in memory feature layer case, there is no service to back the data, the FeatureLayer itself stores the data in memory. So the data is multiple times in memory (in webworkers). The whole dataset held by the feature layer, and the data visible on screen held by the layerview.
It is not the same data. The layerview keeps only the data intersecting the view, optimized for rendering (geometries can be generalized or/and quantized) and projected to the spatial reference, with the required fields for display. Plus when the layerview queries the feature layer, the layer may have to reproject the geometries if their spatial reference doesn't match the view's.
The stream layer works differently since the layer doesn't hold any features in memory. Only what is received via the websocket is kept by the layerview, which can also purge it.
We keep optimizing the in memory feature layer so we should see some improvements, but their will always be a difference with the stream layer since they fundamentally work differently.
... View more
12-05-2024
09:53 AM
|
1
|
4
|
2647
|
|
POST
|
Like @AndyGup said, it's a regression. If you override `fetchTile()` I'd suggest to extend `BaseTileLayer` https://developers.arcgis.com/javascript/latest/api-reference/esri-layers-BaseTileLayer.html which is better suited for extensibility.
... View more
12-15-2022
09:20 AM
|
1
|
0
|
2158
|
|
IDEA
|
Hi Jonas, Your function is the way to go. This is not possible to change RefreshableLayer.refresh() for a couple of reasons. - Layers are not aware of the views and layerviews. Multiple MapViews can display a same map and layers. So that function can only be done from the application code that knows about both the view and the layer. - There is no way to detect when a refresh is actually finished. While the layerview is refreshing, the user can still pan and zoom, and "updating" will remain true until the data is fully updated. Here's another version of your function that ensure the layerview is updating then not updating: async function refreshLayer(layer, view) {
layer.refresh();
const layerView = view.allLayerViews.find((layerView) => layerView.layer === layer);
await reactiveUtils.once(() => layerView.updating);
await reactiveUtils.once(() => !layerView.updating);
} Your goal is to detect when a refresh has failed. It can mean a lot of things. In the case of a tile layer for example, we can't consider that the refresh has failed because one tile failed to refresh. For feature layers, data is fetched using different strategies depending on the server capabilities. It would be helpful to get more information about the information you would need, and how it would translate in the UX. The only way to detect that some data failed to be fetched at the moment is to create a log interceptor https://developers.arcgis.com/javascript/latest/api-reference/esri-config.html#log to intercept the messages in the console.
... View more
04-13-2022
09:25 AM
|
0
|
0
|
2981
|
|
POST
|
Hi Shanon, We don't have a proper way to disable pbf at the moment. You are on the right track to use interceptors. It would work if you intercept the call to the service info, and override the supported query formats to only have JSON. esriConfig.request.interceptors.push({
urls: /FeatureServer\/\d+$/,
after: function (response) {
response.data.supportedQueryFormats = "JSON";
}
}); Cheers Yann
... View more
08-26-2020
04:24 PM
|
3
|
3
|
11742
|
|
POST
|
I'm sorry your are running into this. API Classes moved away from `dojo/_base/declare` and internals have changed. We never supported extending classes using native ES classes, and it worked by chance. We might support it at some point, after more refactoring, but it's not immediate work. See Implementing Accessor | ArcGIS API for JavaScript 4.16 const ExtendedFeatureLayer = FeatureLayer.createSubclass({
additionalMethod() {
}
})
You can make it work with ES classes, but this is not supported and will likely change in the future class ExtendedLayer extends FeatureLayer {
constructor(props) {
super(props);
this.postscript();
}
}
... View more
07-29-2020
11:51 AM
|
0
|
2
|
2268
|
|
POST
|
It was updated. UniqueValueRenderer | ArcGIS API for JavaScript 4.16
... View more
07-29-2020
08:37 AM
|
2
|
0
|
3577
|
|
POST
|
Hi, UniqueValueRenderer works with GeoJSONLayer as well. This is missing in the documentation, we'll update. Thanks! Yann
... View more
07-11-2020
10:52 PM
|
3
|
2
|
3577
|
|
POST
|
The whole API is barely based on dojo now and declare is just one of the last things to stop using from dojo.
... View more
12-18-2019
10:56 AM
|
1
|
1
|
3085
|
|
POST
|
That's a good question. esri/widgets/Widget already extends esri/core/Evented actually. It's not documented to let us make any modifications faster. When a module is documented we need to support it and any modification would go through deprecation etc. (we are still trying to improve the deprecation/change process). esri/core/Evented changed as the multi-inheritance was removed for example. I managed to get this done in a single release cycle. If the module had been public it wouldn't have been possible.
... View more
12-18-2019
08:10 AM
|
1
|
3
|
3085
|
|
POST
|
Hi Nicolas, By removing `declare` we can't anymore extend both dojo's classes and Accessor for example. As a matter of fact the API is using its own version of Evented as a mixin, which is not from Dojo. There is a couple of quick ways you can mix in Evented from Dojo while extending Accessor. Since `dojo/Evented` is a very simple class with no constructor and internal state, the fastest solution is to use directly the functions from `dojo/Evented`. require([
"esri/core/Accessor",
"dojo/Evented"
], (Accessor, Evented) => {
function EventedMixin(Base) {
return Base.createSubclass({
on: Evented.prototype.on,
emit: Evented.prototype.emit
})
}
var MyClass = EventedMixin(Accessor);
var instance = new MyClass();
instance.on("event", () => console.log("event received"));
instance.emit("event");
}); Here I created a mixin EventedMixin which creates a subclass of the provided Base and which adds the on and emit methods from dojo/Evented. Another option would be to copy the implementations from dojo in the mixin instead of referencing them. Thanks Yann
... View more
12-17-2019
02:42 PM
|
3
|
5
|
3085
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 02-25-2026 12:19 PM | |
| 1 | 02-23-2026 04:31 PM | |
| 2 | 02-24-2026 05:44 PM | |
| 10 | 06-27-2025 02:06 PM | |
| 1 | 12-05-2024 10:05 AM |
| Online Status |
Offline
|
| Date Last Visited |
03-05-2026
04:29 PM
|