feat: only get template fields once selected

[elzody]

• Resolves: File templates showing very slow #51780
• Related: fix: check if template fields should be extracted richdocuments#4713

Summary

Creating a new file from a template can take a very long time if browser cache is disabled, does not exist yet, or an incognito session is used. This is because the TemplatePicker.vue component requests all templates from the /ocs/v2.php/apps/files/api/v1/templates endpoint, which includes all the extracted fields of each template. For office documents, this meant that, for each template file, a request was being made to Collabora one after the other, causing very poor performance. I tried to find a workaround for this in the richdocuments app (e.g. using concurrent requests), but was not able to find a viable solution that made a noticeable difference in performance.

My solution is to add a new property to the BeforeGetTemplatesEvent class, indicating whether or not the template fields should be extracted. This allows more fine-grained control, as if you only want the templates but don't want to waste compute or wait on I/O to extract the template fields, you can pass false as a value for withFields, which is the default. If you do want the fields, you pass true. This is used for the new endpoint, so the front end can call it to get the fields for whatever template is selected.

You can find the related richdocuments pull request above, which includes tests.

Screen Recordings

Performance before

template-picker-slow-loading.mp4

Performance after

template-picker-fast-loading.mp4

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[skjnldsv]

Awesome, thanks for this!
The code looks good 👍

[susnux]

OCP changes need to be documented in the app upgrade guides in the developer docs afterwards

[elzody]

/compile

[juliusknorr]

Just noticed now, I would have marked as a bugfix, @elzody Since the backport would need manual adjustments to be backward compatible with 31 can you take care of that?

[juliusknorr]

/backport to stable31

[pedropintosilva]

Awesome, thanks 🥳

[mmeeks]

Great to see the fix - thanks ! =) I had always assumed we just cached large thumbnails of the templates in the object store (as I assume we do for the file thumbnail view) and serve / re-use those for the template selector - is that not the case ?

[elzody]

@mmeeks The issue was not the thumbnails, but rather the fact that we send each of those templates to Collabora for field/content control extraction via the extract/transform API. It was taking a long time to process those, so now it just skips that when displaying them, and will only send the template to have the content controls extracted once the user selects which one they want to use.

And of course, once the content controls are returned, we cache them on our side for the future, unless the template file itself changes (in which case we re-fetch them because they might have changed), or after a certain amount of time (I forgot how long off the top of my head).

[mmeeks]

Wonderful =) thanks Elizabeth.