Svelte is my favorite framework, and today we\u2019re exploring using SvelteKit to handle routing and data fetching for headless WordPress!<\/p>\n\n\n\n
This article is part of a series exploring implementing the WordPress template hierarchy<\/a> in various frameworks. In the Astro + WordPress article<\/a>, we covered many foundational topics. I recommend giving that a quick read before proceeding, especially if you\u2019re not familiar with WordPress, its template hierarchy, or how to implement the template hierarchy in a JavaScript framework. <\/p>\n\n\n\n For a working example of what we discuss here, check out the wpengine\/hwptoolkit<\/a> repo.<\/p>\n\n\n\n Table of Contents<\/strong><\/p>\n\n\n\n In the article on Astro<\/a>, we discussed 4 major steps in the template hierarchy that must be recreated for a front-end framework. URI => Data => Template => Render: Data + Template. <\/p>\n\n\n\n In Astro, we did this on the server, leveraging a catch-all route. Then, we used Astro\u2019s rewrites to switch to a different route under the hood that acted as our template. The rewrites were important to allow us to keep bundling working correctly. Given that SvelteKit rehydrates and does client-side routing by default, this will be even more important here! <\/p>\n\n\n\n Svelte does have a mechanism for rewrites, or as they call them, reroutes<\/a>. Compared to I decided to see how it would work, but I didn\u2019t like it. The implementation had some significant edge cases, which ultimately made it too cumbersome. <\/p>\n\n\n\n Unlike Astro, because reroutes are a SvelteKit Hook<\/a>, any code in this hook runs on every request; it happens before SvelteKit’s file-system routing. This is important because it means all routes get handled by the The difference being, if I add a route in the file system for content not driven by WordPress, Astro seamlessly handles that before the catch-all route (i.e., file-system router => catch-all rewrite => template). In SvelteKit, that same route would still get passed to the reroute hook (i.e., reroute hook => template). The file-system router has been fully circumvented. Additionally, this means we\u2019re making a request to WordPress on every request to the server. To avoid both these issues, we have to add logic to specifically include and exclude certain routes from being sent to WordPress or avoid the file-system router. In the end, it felt like I was having to invent a new router, on top of SvelteKit.<\/p>\n\n\n\n While we can use a catch-all route in the Svelte router, we\u2019re back to being worried about how our JavaScript will bundle. But SvelteKit has a whole data loading system for routes that Astro doesn\u2019t have. Some quick searching led me to a pretty cool solution. <\/p>\n\n\n\n Usually, frameworks only support returning serializable data from data loading functions like the Next.js However, SvelteKit also has a universal<\/a> load function in These load functions support asynchronous calls and thus also support dynamically importing Svelte components with the ESM Let\u2019s put this all together in SvelteKit. The steps are:<\/p>\n\n\n\n To get the full URI, we\u2019ll use the SvelteKit file-system router and a catch-all route: Note<\/strong>: SvelteKit creates routes based on folder names, not file names, we\u2019ll create specific files here soon.<\/p>\n<\/blockquote>\n\n\n\n To run the seed query<\/a> in SvelteKit, we\u2019ll use the server load function in Our app will use a function we built for Faust<\/a> to take the data from the seed query and generate a list of possible templates, sorted from most specific to least specific. For example, the templates for a page could look like this: Because we\u2019re using dynamic imports to import our WordPress templates, they don\u2019t have to be dedicated routes. However, we do need a single location where they all exist so we can easily import them programmatically. We will use a <\/p>\n\n\n\n Like with Astro, we can read from the file system to determine which templates are available. This is a bit easier than registering them manually.<\/p>\n\n\n\n Because we\u2019re reading from the file system, this work must be done on the server. The code could be handled directly in our server load function. Alternatively, to use the universal load function, you\u2019d have to create an API endpoint. <\/p>\n\n\n\n Svelte has another superpower: a special built-in version of This is handy because it allows us to get the available templates from an endpoint<\/a>. Then, regardless of whether I choose to fetch that data in the universal ( We now have a list of possible templates and a list of available templates. Based on the prioritized list of possible templates, we can determine which of the available templates to use. <\/p>\n\n\n\n A quick bit of JavaScript<\/a> can compare the list of possible templates (single-post-sample-post, single-post, single, singular, index) to the list of available templates (archive, home, archive, single) and the first match is our template. In this case, Now that we\u2019ve built all the pieces, we can put this into a single function<\/a> that takes a URI and returns the template. The server load function<\/a> for our catch-all route now looks something like this:<\/p>\n\n\n <\/p>\n\n\n\n We have all the data, now we need to use that data to load our template in the universal load function.<\/p>\n\n\n\n The data returned from a server load function is always resolved before the universal load function is executed and passed to it. <\/p>\n\n\n\n Additionally, because we\u2019re returning data from the universal load function, we\u2019ll lose any data we returned from the server load function. If we want data from both, we must return the server data from the universal function. <\/p>\n\n\n\n Our universal load function<\/a> now looks something like:<\/p>\n\n\n <\/p>\n\n\n\n Okay, so our load functions are doing their jobs. The final step is to render our template, which is passed to the page route.<\/p>\n\n\n\n Svelte makes this easy in the route template<\/a>:<\/p>\n\n\n <\/p>\n\n\n\n The template hierarchy has now been implemented, and WordPress is routing! Now we need to get some data for our routes. <\/p>\n\n\n\n We could query data from within our Svelte components. However, these queries will be executed on the client and not prerendered at build or on the server. <\/p>\n\n\n\n This is preferably handled in one of our load functions. Either the server or the universal load functions may be used. There is a slight difference in how and when this data is queried. <\/p>\n\n\n\n The most important thing to note is that the universal load function will execute once on the server and again on the client (albeit without the need for a redundant network request<\/a>) for server-rendered pages. However, it will only be executed on the client for client-side navigation.<\/p>\n\n\n\n The server load function is only executed on the server, and the response is delivered via JSON to the client for hydration. Client-side navigation means a new JSON payload is delivered. <\/p>\n\n\n\n Depending on the caching headers you opt to set, code complexity, etc., either of these may have performance implications or benefits. In this example, I\u2019m going to fetch this data from the universal load function<\/a>. <\/p>\n\n\n\n The first step is creating a place to define queries that need to be executed for a given template. Since we\u2019re already dynamically importing templates, importing the needed queries along with them seems logical. This way, all GraphQL, HTML, JS, and CSS can live within one file.<\/p>\n\n\n\n SvelteKit allows us to export things from the module-level script tags<\/a> in a component. i.e.;<\/p>\n\n\n\n
\n
\n
Routing<\/h2>\n\n\n\n
Astro.rewrite()<\/code><\/a>, this is a very different system. Reroutes are basically dedicated middleware that is executed on every request to the server, rather than a simple function that can be called. <\/p>\n\n\n\nreroute<\/code> hooks, not just the ones that make it to a catch-all route<\/a>. <\/p>\n\n\n\ngetServerSideProps<\/code><\/a> function. This is because the framework has to turn this data into JSON to send it to a browser. SvelteKit offers this same functionality with its server load function<\/a> in +page.server.js<\/code>. <\/p>\n\n\n\n+page.js<\/code>! This function is executed both on the server and on the client, so it can support returning non-serializable data\u2014data like a Svelte component!<\/p>\n\n\n\nimport()<\/code> syntax<\/a>. We can combine this to make seed queries, load the appropriate template, and render a page. <\/p>\n\n\n\nTemplate Hierarchy in SvelteKit<\/h2>\n\n\n\n
\n
\n
Catch-All Route<\/h3>\n\n\n\n
src\/routes\/[...uri]\/<\/code>.<\/p>\n\n\n\n\n
Seed Query<\/h3>\n\n\n\n
+page.server.js<\/code>. This data is serializable. In apps that you build, you can either choose to use the server load function as demonstrated here or the universal load function, depending on the type of page and the type of data that it requires.<\/p>\n\n\n\nCalculating the Possible Templates<\/h3>\n\n\n\n
[page-sample-page, page-2, page, singular, index]<\/code>.<\/p>\n\n\n\nCreating Available Templates<\/h3>\n\n\n\n
wp-templates<\/code> directory with our templates inside, like this:<\/p>\n\n\nsrc\n<\/span><\/span> \u21b3 wp-templates\/\n<\/span><\/span>\u00a0\u00a0 \u21b3\u00a0index.svelte\n<\/span><\/span>\u00a0\u00a0\u00a0\u00a0\u21b3\u00a0home.svelte\n<\/span><\/span>\u00a0\u00a0\u00a0\u00a0\u21b3\u00a0archive.svelte\n<\/span><\/span>\u00a0\u00a0\u00a0\u00a0\u21b3\u00a0single.svelte\n<\/span><\/span><\/code><\/span><\/pre>\n\n\nfetch<\/code><\/a>. This is available in load functions and optimizes our request. In the case of server load functions, it doesn\u2019t make an HTTP request but directly executes the JS, meaning we don\u2019t have the overhead of a network request. <\/p>\n\n\n\n+page.ts<\/code>) or server (+page.server.ts<\/code>) load function, it will always work optimally.<\/p>\n\n\n\nChoosing a template<\/h3>\n\n\n\n
single<\/code> is the winner!<\/p>\n\n\n\nPutting it all together<\/h3>\n\n\n\n
\/\/ routes\/[...uri]\/+page.server.js<\/span>\n<\/span><\/span>\n<\/span><\/span>export<\/span> const<\/span> load = async<\/span> (event) => {\n<\/span><\/span>\u00a0const<\/span> {\n<\/span><\/span>\u00a0\u00a0\u00a0params<\/span>: { uri },\n<\/span><\/span>\u00a0\u00a0\u00a0fetch,\n<\/span><\/span>\u00a0} = event;\n<\/span><\/span>\n<\/span><\/span>\u00a0const<\/span> workingUri = uri || \"\/\"<\/span>;\n<\/span><\/span>\n<\/span><\/span>\u00a0const<\/span> templateData = await<\/span> uriToTemplate({ uri<\/span>: workingUri, fetch });\n<\/span><\/span>\n<\/span><\/span>\u00a0return<\/span> {\n<\/span><\/span>\u00a0\u00a0\u00a0uri<\/span>: workingUri,\n<\/span><\/span>\u00a0\u00a0\u00a0templateData,\n<\/span><\/span>\u00a0};\n<\/span><\/span>};\n<\/span><\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nLoading the template<\/h3>\n\n\n\n
\/\/ routes\/[...uri]\/+page.js<\/span>\n<\/span><\/span>\n<\/span><\/span>export<\/span> const<\/span> load = async<\/span> ({ data }) => {\n<\/span><\/span>\u00a0const<\/span> template = await<\/span> import<\/span>(\n<\/span><\/span>\u00a0\u00a0\u00a0`$wp-templates\/${dataToPass.templateData.template?.id}<\/span>.svelte`<\/span>\n<\/span><\/span>\u00a0);\n<\/span><\/span>\n<\/span><\/span>\u00a0return<\/span> {\n<\/span><\/span>\u00a0\u00a0\u00a0...data,\n<\/span><\/span>\u00a0\u00a0\u00a0template<\/span>: template.default,\n<\/span><\/span>\u00a0};\n<\/span><\/span>};\n<\/span><\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nRendering the template<\/h3>\n\n\n\n
\/\/ routes\/[...uri]\/+page.svelte\n<\/span><\/span>\n<\/span><\/span><script<\/span>><\/span><\/span>\n<\/span><\/span>\u00a0const<\/span> { data } = $props();<\/span><\/span>\n<\/span><\/span><\/span><\/script<\/span>><\/span><\/span>\n<\/span><\/span><\/span><\/span>\n<\/span><\/span><data.template<\/span> \/><\/span><\/span><\/span>\n<\/span><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\nQuerying Data <\/h2>\n\n\n\n
Defining Queries<\/h3>\n\n\n\n