verson 4.x widgets vs web components

[Aeseir]

With the move to web components on the way, will version 4 widgets stop working, or will users still be able to use the 4.x library widgets albeit without support?

[JuliePowell]

Hello @Aeseir! We are making a full transition to W3C standards-based web components. Widgets will eventually be removed from the SDK. We are currently working towards the following tentative schedule:

• All widgets deprecated by Q1 2026
• Widgets removed Q1 2027

You can find more information about our transition plan in this blog: https://www.esri.com/arcgis-blog/products/js-api-arcgis/developers/javascript-maps-sdk-a-full-transi... 

[JeffreyThompson2]

@JuliePowell I don't think you fully answered this question. Allow me to re-ask it a little differently.

1. If we are using an older version of the API, will Widgets continue to work?
2. In future versions of the API, will Widgets still be included/usable, but no longer getting updates?
3. If we have built a custom Widget using the ViewModel class, will they continue to work in future updates?

I'm pretty sure the answer to the first question is yes and the second one is a no. I don't know about the third one, but I really hope it's a yes.

[JuliePowell · Accepted solution]

Ahh, ok. Sorry about that.

1. yes
2. no
3. This one is a bit more complicated, see below

The Widget class is going away with widgets. With regards to view models, it is a bit more complicated. First off, we know how important it is that developers can continue to create tailored experiences with the SDK. Going forward, you will be able to build the same custom experiences using the underlying business logic, but the implementation will change. As we move to the component-based architecture, view models are being considered for 3 possible buckets:

1) The View Model will be kept in the core API, but reworked/moved: The functionality will simply move to another location (since they are currently located in the widgets/ folder).

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.

Categorization of view models into the three buckets above depend on the explanation above, but also based on what we are learning from customers. We really want to understand which view models are being used, and for what purpose so that we can make sure we account for the wide variety of scenarios and customer requirements. We are encouraging customers to fill out this survey to help inform this roadmap:

https://arcg.is/005zS9

One other aspect that I would like to share is that sometimes view models are used to make a slight adjustment to the UI (like hide part of it, or add a button to do something). Part of our roadmap is to implement slots which are placeholders within the component UI for you to embed your own functionality/workflows. Components also have configuration and styling options through css properties. So in some cases, developers can write and maintain less custom code because they are able to use the out of box components (as opposed to creating their own UI on top of the view models), and still tailor the experience to meet their requirements. So, the more specific information you can share in the survey, the better we can design the component options for your needs. 

I am working on a blog that covers this topic. I will post a link here when it is published. 

[JonathanDawe_BAS]

Thanks @JuliePowell  this is really helpful context. I’ve actually filled out the survey before after seeing one of your earlier posts, and I’ve always made heavy use of the widget viewmodels in the API.

In my opinion, the viewmodel pattern is one of the best things about the API. It gives you a really flexible way to build your own version of a widget, kind of like a “headless component,” so you can apply your own styling and structure while still using Esri’s underlying logic.

For example, we built our own custom search widget using a different UI library, but we were still able to plug in the SearchViewModel and other parts of the API like the coordinate formatting utilities. It works really well for us because we get to customise the UI, while Esri handles all the core logic and testing.

I think this is a real concern. Just because the functionality might still exist somewhere in the API at a more atomic level, that doesn’t mean it’s as usable or helpful. The viewmodels provide a really valuable layer of abstraction that pulls together Esri’s best practices for how to coordinate and structure that functionality. Without them, developers have to reassemble and maintain a lot more of that orchestration themselves.

[timtucker-dte]

Any ideas how long it'll be before we see client side graphics & feature layers as web components?

Much of our use of the SDK would be immensely simplified if it supported things like:

<arcgis-map>
    <arcgis-geojson-layer url="/api/geojson" />
    <arcgis-feature-layer>
        <arcgis-web-symbol point={{latitude1, longitude1}} style="push-pin-1"/>
        <arcgis-web-symbol point={{latitude2, longitude2}} style="push-pin-1"/>
    </arcgis-feature-layer>
</arcgis-map>

 As-is, we're finding it takes a lot of state management logic in React to track when a map is ready to start adding things to it and make calls to update lists of features when / if they change.

(also submitted this as feedback via the survey link)

[JonathanDawe_BAS]

I found a nice implementation of this functionality/pattern in an open source library which I've adopted (and adapted) into my own projects. https://github.com/antarctica/embedded-maps/tree/main/src/lib/arcgis/components/ArcLayer 

Originally adopted from here: https://github.com/am-maneaters/re-arc/tree/main/packages/arcgis-react 

Layers example here: https://re-arc.netlify.app/#Intro%20to%20Layers 

[Aeseir]

Thanks @JuliePowell.

For us current version of arcgis js sdk meets our needs for now and next year or so. We have heavily extended it to fit our use cases and usage patterns.

As long as the widgets and maps all work with version 4.x, after the depreciation date, we are happy as larry.

Since components seem a lot more restrictive (we leverage the programmatic nature of SDK heavily, with customised UX), we would rather wait a bit till maturity develops and then establish a migration plan as needed.