Remove custom web-forms caching by key, defer to workbox pwa

[spwoodcock]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation
• 🧑‍💻 Refactor
• ✅ Test
• 🤖 Build or CI
• ❓ Other (please specify)

Related Issue

Looking into this during #2674

Describe this PR

• We implemented a custom caching mechanism for webforms, to avoid loading every time a feature is clicked.
• Since then, we added workbox runtime caching.
• Ideally the webforms can be cached as part of the PWA workbox config.
• If you think it's feasible, could you please continue this @DanielJDufour 🙏?
• If not, we can close and keep caching manually - but we need a way to avoid the cache conflicts that keep occurring (perhaps we need a rule to omit this path in workbox too).

Checklist before requesting a review

• 📖 Read the Field-TM Contributing Guide: https://github.com/hotosm/field-tm/blob/main/CONTRIBUTING.md
• 📖 Read the HOT Code of Conduct: https://docs.hotosm.org/code-of-conduct
• 👷‍♀️ Create small PRs. In most cases, this will be possible.
• ✅ Provide tests for your changes.
• 📝 Use descriptive commit messages.
• 📗 Update any related documentation and include any relevant screenshots.

[optional] What gif best describes this PR or how it makes you feel?

[DanielJDufour]

Sure! I can take a look! I think the crux of it will be trying to find a way for the workbox cache to apply to the iframe's context. I'll try to think creatively, including maybe loading workbox inside the iframe. I'll know more once I dive in! Thanks for getting this started!

[DanielJDufour]

I'm working on this currently. I think we want to look into pre-caching 'https://hotosm.github.io/web-forms/odk-web-form.js' and '/web-forms.html'.

For the things that depend on the config.json, which is dynamically loaded, I don't think we can technically do pre-caching in the service worker using a manifest. Instead, I'll look at trying to do "preemptive" (is that the right word?) runtime caching where we cache right when the project is loaded (and not waiting for a map feature to be selected). In other words, try to load the resources as soon as we can (after config.json loaded).

[spwoodcock]

I'm working on this currently. I think we want to look into pre-caching 'https://hotosm.github.io/web-forms/odk-web-form.js' and '/web-forms.html'.

For the things that depend on the config.json, which is dynamically loaded, I don't think we can technically do pre-caching in the service worker using a manifest. Instead, I'll look at trying to do "preemptive" (is that the right word?) runtime caching where we cache right when the project is loaded (and not waiting for a map feature to be selected). In other words, try to load the resources as soon as we can (after config.json loaded).

Nice, sounds like a plan! Its likely the cache config in the vite config for the precaching 😃

[spwoodcock]

Hi @DanielJDufour!

We are finalising and deploying the MdP project for a demo / review around 29th July.
Do you think this issue might be solvable before then, or it's more complex? 🙏

[DanielJDufour]

@spwoodcock , yes. I think it's solvable. Worse case scenario is if I can't get the elegant vite.config.ts approach to work to precache the files in the service worker. I can just force an early runtime cache, by calling fetch on the resources when the app loads. I'll give myself to Wednesday to get the more elegant approach to work. If it doesn't work then, I can take the more hacky approach.