Open benmccann opened 3 years ago
I'm having a similar issue, but it's on the client side, I have this component called AdSlot, and it gets blocked if you have an AdBlocker turned on, and, because of that, everything gets broken in my page, the css does not load properly and so on
EDIT: I forgot to mention, the problem only happens when running a production build, with npm run dev
it works fine
I'm having a similar issue, but it's on the client side, I have this component called AdSlot, and it gets blocked if you have an AdBlocker turned on, and, because of that, everything gets broken in my page, the css does not load properly and so on
EDIT: I forgot to mention, the problem only happens when running a production build, with
npm run dev
it works fine
For reference, looks like my Ghostery is breaking my Sveltekit SPA when in production. 'npm run preview' is ok, and dev. If I host the SPA locally though from the build folder, I can reproduce the issue. Pausing Ghostery and the page hosts fine.
I have one theory, in that I redirect of route based on username of the site like so example.com/username - this redirect uses a branch.io deep link which Ghostery doesn't like
Is there any chance the SPA on hydration hits a URL like example.com/index and causes Ghostery to interject? Why would the behaviour differ from the production build to the npm run preview
?
Any ideas on how I can resolve this - just spent 2 days learning SvelteKit and went to deploy for then this to happen :-( Currently I host on firebase hosting but will look at alternatives to see if I can circumvent the issue for now.
hey! i was wondering if this issue is still open because the milestone was set a long time ago.
Describe the bug
The page from the reproduction loads during SSR and then fails during hydration during dev mode if you both have adblock on and are not using the new
experimental.prebundleSvelteLibraries
option (https://github.com/RobBrazier/svelte-awesome/issues/775).This particular example is kind of an edge case, but the outcome is really bad and I'm not so sure how rare it is more generally. Per Rich's point, sometimes things fail to load because you live in NYC and take the subway and lose connectivity going into a tunnel. That the entire page would be wiped out eventhough SSR succeeded is quite a bad outcome. If we wrapped the whole hydration in a
try
/catch
maybe you'd at least see the server-rendered page. Or perhaps if we had error boundaries the developer could do something smarterReproduction
https://github.com/benmccann/500-import-failure
Logs
I get a message in the browser:
Screenshot:
System Info
This fails on
1.0.0-next.138
and newer all the way up tomaster
since that's when we turned oncompilerOptions.hydratable
: https://github.com/sveltejs/kit/pull/2024https://github.com/sveltejs/kit/blob/master/packages/kit/CHANGELOG.md#100-next138
Severity
blocking all usage of SvelteKit
Additional Information
No response