jszip_v3

[jskrzypek]

I was recently looking at Stuk/jszip#224 and I think there would be a lot of benefits to adapting docxtemplater to the newer async jszip. This would allow us build/download and include things like subdocuments and images that would otherwise require building everything synchronously and waiting for each step. Any thoughts on this?

[edi9999]

First : I think jszip v3 is not yet released, and there hasn't been any news on that MR since August 2015.

I'm not sure I understand what you're speaking about here, what exactly do you mean when you say :

This would allow us build/download and include things like subdocuments and images that would otherwise require building everything synchronously and waiting for each step.

But yes, if jszip v3 comes out, I will update the dependency of docxtemplater.

[jskrzypek]

I perhaps wasn't too clear. My main interest was to be able to include images that I fetch from the web. Because in general the pictures in a docx are included in the word/media folder and referenced through word/_rels/document.xm.rels it seems like an ideal use case since you can just build the relation and the xml and then just pass the stream from the request into jszip's new async file() method, which will accept node streams.

I am also thinking of situations where someone has an omnibus docx report to compile with a number of subsections, some perhaps built with docxtemplater, others not, also with the possibility to fetch data from a db or web. If, say, we were waiting on the results of a query to our db to return data that we need to loop over, we could start by building a raw XML template for each item, and then just populate the fields in that XML when the results are resolved.

What you suggested in https://github.com/open-xml-templating/docxtemplater-image-module/issues/41 regarding supporting parsers that return promises might do the trick. Looking at it again, perhaps v3 of jszip wouldn't really have that much of an impact on this, as even the image loading we could just do synchronously after all of them resolve.

[edi9999]

Closing this as there is nothing to do, issue https://github.com/open-xml-templating/docxtemplater-image-module/issues/41 should probably be moved here

[morphinewan]

JSZip v3 was released for almost 2 years. Any support plan for docxtemplater? Thanks.

[edi9999]

Hello @morphinewan, the reason for not updating jszip to version 3 is that is async only, which is harmful for perfomance. See #340 (comment) and the linked discussions from there on for more of this discussion.

I do not plan to switch to an async-only library.

[jefbarn]

@edi9999 async usage is better in a browser context because it prevents hanging the UI thread. Also I would suggest if you plan to keep the JSZip 2 dependency that you make it a proper npm dependency so that users don't have to worry about importing the wrong version.

[edi9999]

Webworkers are a way to really not block the UI thread : https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

Templating and zipping are CPU intensive tasks, they should be done in separate workers instead of asynchronously, where they would still "eat" performance, just not continuously.

For jszip@2, I'm also not so fan of that, in previous versions, jszip was something "internal", but people always asked how to do things on the generated zip object. Since this dep is explicitly external, people know that they have to look at the jszip documentation.

I was hoping that jszip v3 would allow to have sync methods in the long run, but it happens not to be planned.

[edi9999]

Also, the fact that we do the zipping synchronously does not mean that docxtemplater cannot resolve tags asynchronously.

See :

https://docxtemplater.readthedocs.io/en/latest/async.html

[edi9999]

The recommended approach is now to use the Pizzip module , as explained in the doc : https://docxtemplater.readthedocs.io/en/latest/generate.html