About model.modelData incremental JSON

I found the model.modelData change is not included in the incremental JSON, that is OK for me.
My question is do you have any plan in the future add change of modelData to incremental JSON?

if I don’t want to include the data to the incremental JSON or toJson, I just use “_” before the property name, that is good?

I just checked, and Model.toIncrementalJson and Model.toIncrementalData both put out the Model.modelData object if it has been modified.

Yes, if you don’t want the Model methods to serialize a property, have it start with an “_” underscore. Or make the property not enumerable on the Object. Or have the property value not be serializable, such as a function.

Sorry, It was my mistake it dose. because I skip the undoManager so it does not emit IncrementalJson
but I wonder why when skipping the undoManager it doses not emit IncrementalJson.
even when skipping the undoManager already changed the model.

my test code is

  var skipUndoStatus = digm.skipsUndoManager;
  digm.skipsUndoManager = true;
  digm.model.set(digm.model.modelData, "aaaaa", "ssss" + (ssssscount++));
  digm.skipsUndoManager = skipUndoStatus;

The point of the Model.toIncremental… methods is so that at the end of a transaction you can generate a summary of all of the changes. But unless those changes are recorded, there won’t be anything to report.

I suppose it would be possible to implement that functionality using a Model Changed listener that recorded the adds/modifies/removes in a separate data structure. But that would basically be duplicating information that is stored in a Transaction anyway.

it means if I skipsUndoManager then it does not emit any incremental JSON, yes?
if I want it to emit the incre…JSON then I must implement my own trace data structure of it, and record any detailed action of changes of model, right?

by the way, this is the sample code of previous question,
already listening to the changes event, but there is no JSON emit, { “incremental”: 0 }

Well, not for the ChangedEvents that were raised when skipsUndoManager was true, but if there were other changes, those would still be emitted by toIncrementalJson.

I haven’t tried this, maybe you shouldn’t be setting skipsUndoManager at all. At the end of a transaction you could iterate through all of the ChangedEvents in the Transaction.changes list. For those ChangedEvents that you do not want to to be undone or redone, you could override their ChangedEvent.undo and ChangedEvent.redo methods to be no-ops.

If you are always going to perform a whole transaction with skipsUndoManager, then there’s an even easier solution. Don’t bother setting skipsUndoManager, but after the end of the transaction just remove the Transaction from the UndoManager.history. That way it’s as if it never happened, but you still will have gotten the chance to get a Transaction ChangedEvent and call toIncrementalJson. I think you can implement this with a “CommittedTransaction” “Transaction” ChangedEvent. Just pop the last Transaction off the history.

I tried diagramA.undoManager.history.pop();
the error occur
The object is frozen, so its properties cannot be set: List()#419
at B (go.js:12)
at ua (go.js:12)
at E.t.pop (go.js:38)

I still don’t know what you are trying to accomplish, so there is yet another possibility that might apply to your situation. Do you need the user to undo or redo at all? If not, then there’s already a documented solution, and you don’t need to set skipsUndoManager at all. Just set UndoManager.isEnabled to true and UndoManager.maxHistoryLength to zero.

I need users to undo and redo, Just sometimes need to not undo and want to save the data to server.
I already checked the document of the transaction , https://gojs.net/latest/intro/transactions.html
[UndoManager.maxHistoryLimit] to zero. is not my case, it totally disables the UndoManager

OK, I think this does what you are looking for, as long as you are looking to “skip” a whole transaction.

      $(go.Diagram, . . .,
          "undoManager.isEnabled": true,
          "ModelChanged": function(e) {
            // detect the end of a committed transaction
            if (e.propertyName === "CommittedTransaction") {
              // maybe call e.model.toIncrementalJson(e) here
              var txn = e.object;  // this is the Transaction, but might be null
              if (txn && txn.name === ???) {  // here you need to decide whether to "ignore" the transaction for undo/redo
                txn.clear();  // this removes all of the ChangedEvents from this Transaction
                txn.isComplete = true;
                e.model.undoManager.undo();  // pop the Transaction off the history list

it works! thank you walter, the key is after toIncrementalJson to call this,
I really happy for this! :)