The updateId property is not part of the API spec (here's the interface definition). TypeScript certainly doesn't like it when referenced:
You can hack around this by referring to it using bracket notation...
...but this isn't really very TypeScript-y, as you're working around the problem, and if for some reason, the property disappears from the object then you'll have to handle the error to avoid the visual crashing.
The property itself appears to be added by the developer visual (which hosts the custom visuals runtime) and is likely playing the role of a correlation ID for logging purposes and will only have any meaning to the originating service.
Personally, if I can't see it in the API spec, I wouldn't rely on it for anything I would do inside the visual logic. If I needed one, I'd generate it within the update method with a suitable package, as you have more control over what you can do with it.
The ID would not provide access to a previous state, so if you wanted to handle this, you would need to store a previous state in your view model when updating during the desired operation, to allow comparison to the current state later on, if you need to revert. TreeViz does something like this, although for the case they're using if for, VisualUpdateType (which has been introduced after they wrote their visual) might be more appropriate.
Regards,
Daniel
If my post solves your challenge, then please consider accepting as a solution to help other forum members find the answer more quickly 🙂