Closed jerimiahwelch closed 3 months ago
Cool! Would love to know more about your goals so that I can better prioritize this.
You can also reach me on Discord @mhevery
Hi @mhevery ,
We are transitioning away from AMP + PWA and we liked that Qwik had better performance and more flexibility.
We are building with Qwik for production. We haven't released yet, but here is our current qwik demo site: https://care.womp.it/
This clinic search list component is part of a website that we will provide at a dedicated domain(s). In addition to the regular site, our client Piedmont health would like to show health appointments on their blog pages. This will help people find the right kind of medical appointment more easily.
This is what we are trying to build, but you need a local proxy to see it properly at the moment.
We are hoping to use containers in this cross-origin context to reuse the clinic search component and not need to develop it twice. We would prefer to use containers instead of iframes for the improved performance as well as providing the parent document more analytics transparency, a/b test control, and CSS control. These have all been issues with our current shadow-dom based web components.
After some testing and CSS hardening, the qwikloader works with this approach on the Piedmont site. The only issue is the component importing JS from the parent domain after user interaction.
We are also interested in using this MicroFE container approach for some of our internal tools so that different teams can develop and release portions of the site independently. The blog client-side script approach in this ticket is intended for minimal work on the healthcare network's side, but we are also exploring Server-side Container composition for other tools https://blog.cloudflare.com/fragment-piercing/.
I work for https://dexcare.com/. We help people find the right kind of appointment with their healthcare network.
OK, I dug into it a bit, and the issue is coming from Vite.
const a = o(_(()=>i(()=>import("./q-0777dc25.js"), ["build/q-0777dc25.js", "build/q-a741c7da.js", "build/q-47bdf09a.js", "build/q-683653e0.js", "build/q-0815ac35.js", "build/q-d2a0a80e.js", "build/q-e4ce1e98.js", "build/q-5b5c912e.js", "build/q-85384b7b.js", "build/q-f2327580.js", "build/q-6db0b552.js", "build/q-6febb18e.js", "build/q-3a50c098.js", "build/q-d42d0c15.js", "build/q-121ac03d.js"]), "s_U4biimqwnQ0"))
The problem is that vite sees q-0777dc25.js
and it knows that q-0777dc25.js
imports q-0777dc25.js
(and so on) so it wants to be smart and pre-fetch all of these to avoid the waterfall problem. So it takes the array and inserts it into the DOM as <link rel="modulepreload" as="script" crossorigin="" href="/build/q-e480eacf.js">
so that the browser does prefetching. But the browser document is on a different domain, hence the errors. Interestingly these are just that, errors, but the application should be fully functional as those fetches have no purpose other than to avoid waterfall.
Related issues on this problem: https://github.com/vitejs/vite/issues/5214, https://github.com/vitejs/vite/issues/3133, https://github.com/vitejs/vite/issues/5120,
Possible fix: https://github.com/vitejs/vite/pull/9938
Add this to your vite.config.js
build: {
modulePreload: {
resolveDependencies: (url, deps, opts) => {
return deps.map((v) => 'http://myserver/' + v);
},
},
},
https://vitejs.dev/config/build-options.html#build-modulepreload
@mhevery ,
Thank you so much for your time on this! And so quickly too. It's been a whirlwind of a morning, but we will be able to try out this solution by early next week.
That matches what we were seeing. The functionality was working, but it was making duplicate requests to the origin.
We currently are setting the q:build attribute to match the server at runtime instead of compile time (below), so that q:base will match the deployment environment without the need for config files. We will dig into Vite module preload and try to see if something similar is possible as well.
Can this issue be closed?
I'm closing this and we're adding better base
support
https://github.com/QwikDev/qwik/pull/6017
please reopen if there is still an issue
Which component is affected?
Qwik Runtime
Describe the bug
Hello,
We are excited to use Qwik Containers to create a Cross-Origin Micro Frontend, but we are seeing that the Qwik runtime is not importing from the specified q:base origin after user interaction.
As shown in the qwik containers documentation, we are inserting a Cross-Origin Qwik Container:
Steps to reproduce
Expected behavior
Observed behavior
Reproduction
https://wompme.blob.core.windows.net/7910/qwikContainerCorsImportIssue.html
Steps to reproduce
See repro steps in description.
System Info
Additional Information
No response