Undocumented breaking change for UpdateWorkflowData in 4.27

362
7
Jump to solution
02-26-2024 03:51 PM
JasonDoingMaps
New Contributor III

In v4.26.5 of @ArcGIS/core, the UpdateWorkflowData class had a property called "edits". interfaces.d.t.s declared it as follows:

    /**
     * The [edits](https://developers.arcgis.com/javascript/latest/api-reference/esri-widgets-Editor-Edits.html) used to keep track of a feature being updated.
     *
     * [Read more...](https://developers.arcgis.com/javascript/latest/api-reference/esri-widgets-Editor-UpdateWorkflowData.html#edits)
     */
    edits: Edits;

 

But in version 4.27+, the property is gone. There's no mention of this in the breaking changes documentation, and I'm unclear on what my migration / update path should be.

I was using this property to access the feature (of type Graphic) being updated, to manipulate some of its attributes before the update workflow committed the changes to the server.

My code used to look something like this:

function save(editorVM: __esri:EditorViewModel) {
  let edits = (editorVM.activeWorkflow.data as __esri.UpdateWorkflowData).edits;
  edits.feature.attributes.myCustomAttribute = 'abc';
  editorVM.activeWorkflow.commit();
}

Now I'm trying to find another way to manipulate those attributes before committing the update.

From the EditorViewModel I can get the SketchViewModel, which has a property for updateGraphics, which does contain the feature being edited. But when I set attributes on it, they're not included in the commit to the server.

Also from the EditorViewModel, I can get the FeatureFormViewModel, which has a feature property, which does contain the feature being edited. But again, when I set attributes on it, they're not included in the commit to the server.

1 Solution

Accepted Solutions
HeatherGonzago
Esri Contributor

Hi, so to add to what we already know. Currently, there is no 1:1 alternative to `UpdateWorkflow.edits`. Unfortunately, this was a needed breaking change for some bigger updates that went through with our relationship work we did back with 4.27. With this said, NOT having it documented as such is not ok, and for that we apologize.

I wanted to fully confirm my suspicions so I spoke to a member on our development team regarding your approach with using `rootFeature`.  Although undocumented, it will do what you need for now. The thing to consider is that this property is designed specifically to access the underlying original (root) feature that began the edit workflow you are currently in. If you have nested workflows, ie. relates, it may not access the feature you intend if you are editing in this scenario since these workflows tend to be nested. For basic updates, this should work fine. We intend on getting a better alternative to this for our next release.

View solution in original post

0 Kudos
7 Replies
ReneRubalcava
Frequent Contributor

Looking at the documentation for UpdateWorkflowData it might have been renamed to "candidates"

https://developers.arcgis.com/javascript/latest/api-reference/esri-widgets-Editor-UpdateWorkflowData...

JasonDoingMaps
New Contributor III

The "candidates" property was in v4.26 also.

Per documentation: "This is only relevant when there are multiple candidates to update."

In my case, the property is null. Probably because I'm editing only one feature.

0 Kudos
JasonDoingMaps
New Contributor III

I also just found that the documentation for the "Edits" class is effectively out of date.

https://developers.arcgis.com/javascript/latest/api-reference/esri-widgets-Editor-Edits.html

"It helps keep track of updated feature edits. This is accessed via the UpdateWorkflow.edits property."

As I've found, that property no longer exists on UpdateWorkflow.

Or actually, it no longer exists on UpdateWorkflowData. I'm not sure it ever existed on UpdateWorkflow - it didn't in v4.26 at least.

0 Kudos
HeatherGonzago
Esri Contributor

This was a mistake on our end. We did document when we deprecated CreateWorkflowData.edits at 4.23.  To instead use CreateFeaturesWorkflow.pendingFeatures to access edits made to the workflow data .https://developers.arcgis.com/javascript/latest/4.24/#deprecated-classes-properties-methods-events.

I apologize, and agree that this is very confusing. The documentation will be fixed asap as this cannot go as-is.

In the meantime, I'm working on getting something to help get you on your way. I just wanted to let you know this omission in doc was not intentional and we'll get it straightened away as a priority. Sorry for all the confusion. I'll post back as soon as I clarify what you need to do moving forward until we get that doc updated publicly.

 

JasonDoingMaps
New Contributor III

Thanks for checking in Heather. It looks like there's been more than a documentation mix-up though, as CreateFeaturesWorkflowData got the new property "pendingFeatures", while UpdateWorkflowData received no equivalent when its "edits" property was removed.

I did discover that UpdateWorkflowData has an undocumented property (also, not present in the TS typings) called "rootFeature" that appears to work the same as Edits.feature used to - i.e. before committing the workflow, I can set attributes on it, and they are persisted to the server. I'd be very hesitant to use an undocumented property though, as that's even more likely to vanish without notice. 😄

0 Kudos
HeatherGonzago
Esri Contributor

@JasonDoingMaps yes, you're correct. I meant to state that we didn't mean to keep this out of the doc. It was inadvertently missed when some updates were made. This should be fixed. As for the underlying issue that you are asking about, ie. what are you now supposed to use in its place? There is a way to do this, but that too wasn't publicly documented. I will be in touch shortly to get some more info to you as I had to confirm some things on our end as well. Again, sorry for the confusion. We'll get it squared away and make sure you have something to work with.

 

 

HeatherGonzago
Esri Contributor

Hi, so to add to what we already know. Currently, there is no 1:1 alternative to `UpdateWorkflow.edits`. Unfortunately, this was a needed breaking change for some bigger updates that went through with our relationship work we did back with 4.27. With this said, NOT having it documented as such is not ok, and for that we apologize.

I wanted to fully confirm my suspicions so I spoke to a member on our development team regarding your approach with using `rootFeature`.  Although undocumented, it will do what you need for now. The thing to consider is that this property is designed specifically to access the underlying original (root) feature that began the edit workflow you are currently in. If you have nested workflows, ie. relates, it may not access the feature you intend if you are editing in this scenario since these workflows tend to be nested. For basic updates, this should work fine. We intend on getting a better alternative to this for our next release.

0 Kudos