You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been trying to dig around to figure out how preprocessors work. So far the most functional code I've written can only scrape the contents of the svelte files, but I've had no luck successfully modifying any content without generating 500 errors with 0 zero feedback, no stack traces whatsoever.
I figure it's worth an in-depth tutorial somewhere more prominent. Because being able to transform documents is now much more critical because of the new default handling of hydration errors.
Here's the concept, I have markdown files for blog posts. Part of those posts include code blocks (which include data for graphs! and other cool things) copy/pasted directly from profiling runs and other places. The data is otherwise completely arbitrary and otherwise realistically just text that just doesn't quite yet "look good". In an earlier version of sveltekit it was completely fine to process the markdown. Then turn those sections of text into .json files and then render the charts by inserting <canvas> elements into the document client-side and letting something like chartjs handle the rest. All within code sitting under /src...
With the more recent versions of sveltekit, what was once trivial to handle after server side rendering on the client EG: the <canvas> element is now a hydration error. Which produces a rather annoying side effect of flashing the content you expect for a fraction of a second, and you're sat frustrated that you're now fighting sveltekit that was so helpful before.
So now, to play nice it would be far easier to "pre" process everything. There is a comment floating around the documentation about this problem. Essentially saying to turn what once were server-side renderable into dynamic routes or something like that so that svelte doesn't yell about structural issues.
My suspicion is that I'm not returning what svelte kit expects from a preprocessor function and a utility script which is supposed to provide frontmatter data is failing with the 500 error. But I'd like to start fresh and see if anyone else can explain how this works from scratch.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I've been trying to dig around to figure out how preprocessors work. So far the most functional code I've written can only scrape the contents of the svelte files, but I've had no luck successfully modifying any content without generating 500 errors with 0 zero feedback, no stack traces whatsoever.
I figure it's worth an in-depth tutorial somewhere more prominent. Because being able to transform documents is now much more critical because of the new default handling of hydration errors.
Here's the concept, I have markdown files for blog posts. Part of those posts include code blocks (which include data for graphs! and other cool things) copy/pasted directly from profiling runs and other places. The data is otherwise completely arbitrary and otherwise realistically just text that just doesn't quite yet "look good". In an earlier version of sveltekit it was completely fine to process the markdown. Then turn those sections of text into
.jsonfiles and then render the charts by inserting<canvas>elements into the document client-side and letting something like chartjs handle the rest. All within code sitting under/src...With the more recent versions of sveltekit, what was once trivial to handle after server side rendering on the client EG: the
<canvas>element is now a hydration error. Which produces a rather annoying side effect of flashing the content you expect for a fraction of a second, and you're sat frustrated that you're now fighting sveltekit that was so helpful before.So now, to play nice it would be far easier to "pre" process everything. There is a comment floating around the documentation about this problem. Essentially saying to turn what once were server-side renderable into dynamic routes or something like that so that svelte doesn't yell about structural issues.
My suspicion is that I'm not returning what svelte kit expects from a preprocessor function and a utility script which is supposed to provide frontmatter data is failing with the 500 error. But I'd like to start fresh and see if anyone else can explain how this works from scratch.
Beta Was this translation helpful? Give feedback.
All reactions