Latest Contributions by YannCabon

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

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

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

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

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

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

It was updated. UniqueValueRenderer | ArcGIS API for JavaScript 4.16  ... View more

Hi, UniqueValueRenderer works with GeoJSONLayer as well. This is missing in the documentation, we'll update. Thanks! Yann ... View more

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

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

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