Usage of the (in preview) Document.compare interface

[arashd]

Post how-to questions about your code on Microsoft Q&A

I'm building a Word add-in that makes document edits and shows them as tracked changes.

I'm trying to implement a diff algorithm that allows me to show granular tracked changes after making an edit--ones that are OOXML-aware, don't cross out whole paragraphs and allow more granular tracked changes, and so on. Using the output of the compare algorithm would be very useful here.

My first attempt at this was to use getFileAsync to get the document contents before mutation and to build a named File object to pass into compare.

var fileContent = getDocumentAsCompressed();
const blob = new Blob([fileContent], {
      type: "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
});

const fileName = "mydocument.docx";
const file = new File([blob], fileName, {
  type: "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
});

const blobUrl = URL.createObjectURL(file);

// mutate the document
...

options = ...
context.document.compare("filename", options);
await context.sync();

console.log("Comparison complete.");

I've realized that compare fails silently in this case. I'm wondering if there's a better way of doing this, and if the failure is intentional, whether there are plans to support in-memory files given understandable limits on filesystem access from Word add-ins.

[roldengarm]

I believe it's not possible at the moment, see also this: https://github.com/OfficeDev/office-js/issues/4616

[YijunMS]

@arashd Thanks for reaching us. After the discussion in the GitHub issue mentioned above, we are planning to develop a new Api which takes the base64 string of a document as parameter (instead of its file path). In this case, if you can convert your file to base64 string in the addin, then you should be able to do the comparison through the new Api. Please let me now if the base64 Api can solve your problem, asks from customer would help us to improve the priority of this feature.

[roldengarm]

@YijunMS we would benefit from this as well. Right now we store it on Azure Blob Storage & generate a SAS URL. This works well, but is a little overkill.