Esri’s ArcGIS Maps SDK for JavaScript is evolving, with a commitment to standards-based web components. This shift in architecture is designed to boost front-end web development productivity and integrate seamlessly with application frameworks like React and Angular. With the move to a component-based architecture, developers will retain the ability to create custom experiences using the SDK’s underlying business logic, but the way that this logic is accessed and utilized will evolve.
Background
As discussed in the JavaScript Maps SDK: A full transition to components blog post, the SDK started with a widget architecture because web component standards were still maturing and lacked broad browser adoption. Now, with widespread browser support for web component standards, Esri is transitioning its technology. As part of this transition, all widgets are slated for deprecation (tentatively planned for Q1 2026) and eventual removal (tentatively planned for Q1 2027). Developers are strongly encouraged to migrate their UI code to use components instead of widgets and MapView/SceneView.
Along with the removal of widgets, the Widget class will also be removed. View models, which are how the SDK currently exposes the underlying business logic of widgets, are currently located under the `widgets/` folder. Therefore, at a minimum, we must move view models to another location.
The Future of View Models
Rather than simply moving the view models to a new location, we are putting careful thought into designing the best way to expose the functionality within the modernized SDK.
View models are being categorized into three potential scenarios:
1) The view model will be kept in the core API, but reworked/moved: The functionality will move to another location (since they are currently located in the widgets/ folder). The API might also slightly change, for example to account for missing functionality needed by the component
2) The view model will be dissolved into the core API: The functionality will be available in core, but through other APIs. For example, AreaMeasurement2DViewModel logic could move to an analysis API similar to what 3D has for AreaMeasurementAnalysis.
3) The view model’s logic belongs to the component: The logic will be exclusively used by the component and the view model will be deprecated and later removed. View models fall into this category when we believe that they don’t provide additional value to developers. For example, in the case of the WeatherViewModel, different APIs already exist to set Weather directly on SceneView, so the view model isn’t really necessary.
Let your voice be heard
The categorization of each view model depends on the above explanations as well as customer feedback. Esri is actively encouraging developers to complete this survey to better understand how view models are being used and for what purposes. This input is crucial for informing the SDK’s long-term roadmap and ensuring that the SDK continues to offer both maximum productivity and the flexibility needed to meet specific organizational requirements.
Understanding common motivations for using view models is also informing the development of new component features. For instance, if view models are currently used for UI simplification (like removing buttons or options), a configuration option could be added to the component to control visibility. Similarly, for integrating custom workflows, slots will be implemented within component UIs, serving as placeholders for embedding custom functionality. Components will also offer configuration and styling options through CSS properties. This approach aims to reduce the need for developers to write and maintain extensive custom code by enabling them to leverage out-of-the-box components while still tailoring the user experience.
Adapting your code to use the new implementation
Release notes will include all changes related to view models. In addition, we will be providing comprehensive resources detailing how legacy view model functionality is exposed including code snippets to demonstrate recommended coding patterns.
We have already started deprecating view models, which are specified in the release notes but will later be added to holistic SDK documentation that covers all view model changes. Deprecated view models and the new implementation for the same functionality are as follows (as of version 4.33):
- AreaMeasurement3DViewModel –> Use the Area Measurement 3D component or AreaMeasurementAnalysis instead.
- ButtonMenuViewModel –> Use TableMenuConfig, Calcite components – Dropdown, Calcite components – List, or Calcite components – Menu web components instead.
- DirectLineMeasurement3DViewModel –> Use the Direct Line Measurement 3D component or DirectLineMeasurementAnalysis instead.
- FullscreenViewModel –> Use the JavaScript Fullscreen API directly instead.
- LineOfSightViewModel –> Use the Line Of Sight component or LineOfSightAnalysis instead.
- NavigationToggleViewModel –> Use the Navigation Toggle component instead.
- SliceViewModel –> Use the Slice component or SliceAnalysis instead.
- WeatherViewModel –> Use the Weather component instead.
Conclusion
Our strategic evolution of the JavaScript Maps SDK highlights our commitment to you to offer a modern, powerful SDK that offers maximum flexibility and productivity for building state-of-the-art applications that meet your unique requirements.
To get started building web apps with the the SDK’s components, explore the below resources:
Get started
Tutorials
Component overview
Programming Patterns
Article Discussion: