[{"id":2,"title":"Creating Responsive views in Svelte.js and SvelteKit","content":"Svelte builds in flow control into its HTML Markup, here's a basic example.\n\n```html\n{#if mobile}\n \n{:else}\n \n{/if}\n```\n\nWe could leave this post here and that would be the end of it. You can work out how to determine if a device is mobile, using whatever set of criteria you like. You build two components, one mobile and one desktop and your done, responsive right down to the HTML with little to no effort...\n\n...but, this isn't particularly efficient for Svelte.js and especially not for SvelteKit. Why? Well there's (at least) three reasons:\n\n1. You essentially have two import hierarchy trees per javascript file. Let's say that you implement this logic in your Root component (that's the component that renders your entire page), you essentially create two separate rendering processes for a single page. Assuming that the components within `SomeMobileComponent` and `SomeDesktopComponent` share no components below this becomes incredibly bloated\n2. You're increasing the overhead of maintaining your codebase. Writing essentially two root components and switching between them depending on whether the page is rendered on desktop or mobile creates a lot of code bloat.\n3. If you use SvelteKit, you may end up rendering the wrong view on the server, sending it to the client which the client then has to correct when it receives the page, making the entire overhead of computing the page on the server redundant.\n\nThis approach though, is still largely the right way to do it, just with a few tweaks. Let's see what those tweaks are.\n\n## Individual Component Responsiveness\nFirstly, unless your entire page changes depending on whether you're on mobile or desktop (and I promise in almost every case it doesn't) you don't need to do this switch at the root. Instead, determine what components are actually going to change between mobile and desktop, then do it at their root. For example, the menus on this site - [AdamGreen.Tech](https://adamgreen.tech) - change depending on if we're on Mobile (default), Tablet (>600px) or Desktop (>1000px). Let's look at our `components/Menu/index.svelte`.\n\n```html\n\n\n{#if $device === 'desktop'}\n \n{:else}\n \n{/if}\n```\n\nPlacing the switch at the root of the component you're actually changing removes the need to maintain two separate root components. This helps to fix the first problem, codebase bloat, by only maintaining separate Mobile, Desktop and Tablet components for the components that need to change between devices.\n\n## Grouping Shared Behaviour\nIn most responsive situations, a lot of the layout isn't actually changing, but a few components are potentially being reordered. Take this blog post as an example. If you're viewing this post on desktop you'll notice that the metadata (author, publish date etc.) is shown on the right side of the display in a green box. On mobile this same box is moved inside the post and placed at the bottom. The responsive part isn't the box itself, just the position it's placed in. \n\nSo, in practice we have four files `index.svelte` the root file that switches between desktop and mobile components `Mobile.svelte` which is the mobile view `Desktop.svelte` which is the desktop view, and `Meta.svelte` which is the component that actually shows the meta data. Here's what they look like\n\n```html\n\n\n\n{#if $device === 'desktop'}\n \n{:else}\n \n{/if}\n```\n\n```html\n\n\n

\n \n \n

\n```\n\n```html\n\n\n

\n \n

\n```\n\nNotice that `Desktop.svelte` and `Mobile.svelte` are nearly identical, except for the fact that the desktop version places the meta box in a separate `

` which then is placed on the right hand side of the page. \n\nBy extracting out the `Meta.svelte` component, we're essentially creating a shared component between the two responsive components. When Webpack, Rollup, Vite etc. comes to build this project, it'll create one function to represent the `Meta.svelte` component which the functions representing both `Desktop.svelte` and `Mobile.svelte` will call in order to render the Meta component. If a particularly large component needs to be made responsive at a high level, regrouping shared components can ultimately help to reduce the size of the output.\n\n## Informing SvelteKit how to render\nOne of the biggest issues this approach faces is utilising server-side rendering from SvelteKit effectively. Good web design says that a mobile view should scale well onto a desktop device without much change. However, depending on how the logic for deciding between mobile and desktop components is written, what tends to happen with this approach is the server builds a mobile view that hits a desktop, the logic takes over client-side and rerenders the view for desktop creating a dramatic cumulative layout shift.\n\nAt the end of the day, all these components are set up to default to their mobile component. What we should really be doing is determining server-side whether to return a mobile or desktop rendered page. If we figure this out, the cumulative layout shift will be negligible (and mostly a consequence of loading fonts, images etc.).\n\nHere's what we're going to do:\n1. We're going to create a [`hooks.js` file](https://kit.svelte.dev/docs#hooks) to pull a special header called [`Sec-CH-UA-Mobile`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-UA-Mobile). This header will be set to `\"?1\"` if a mobile view should be returned and `\"?0\"` if a desktop view should be returned. We're going to stuff this information into the session object which all load functions have access to.\n2. In the `routes/__layout.svelte` [load function](https://kit.svelte.dev/docs#loading) (which runs no matter what page is loaded) we'll add the boolean in the session information to the props of the layout component. \n3. Using the information gleaned from the header, we're going to update a store that all responsive components can access to decide which of their Mobile or Desktop components to show.\n4. We'll create a [derived store](https://svelte.dev/docs#run-time-svelte-store-derived) that returns a string saying `\"desktop\"`, `\"tablet\"` or `\"mobile\"` depending screen width and the server override.\n\nFirst let's look at the `hooks.js` file located in `src`.\n\n```javascript\n// src/hooks.js\nexport function getSession(request) {\n return {\n mobile: request.headers['sec-ch-ua-mobile'] === '?1'\n }\n}\n```\n\nEssentially, every `load` function for every svelte component will receive the returned object as `session`. We can see this in the `__layout.svelte` component below. The `__layout.svelte` component is used as a wrapped for every page (assuming it's placed in `src/routes`.\n\n```HTML\n\n\n\n\n\n\n```\n\nNotice that we also bind the `innerWidth` of the HTML document (using [`svelte:window`](https://svelte.dev/docs#template-syntax-svelte-window)) to another store in our `$lib/utils/device.js` file.\n\n```javascript\n// src/lib/utils/device.js\nimport {writable, derived} from 'svelte/store';\n// a SvelteKit provided variable that indicates if we're on browser\nimport {browser} from '$app/env';\n\n//default to 0 width - this won't be updated server side because svelte:window won't work server side\nexport const width = writable(0);\n//this will be set server side, from the __layout.svelte component\nexport const mobile = writable(true);\n\n//This store computes what device to render for\nexport const device = derived([width, mobile], ([width, mobile]) => {\n // if width is >1000 (px) or we're not on browser and a mobile view hasn't been requested\n if (width > 1000 || (!browser && !mobile)) {\n //then we're on desktop\n return 'desktop';\n // if width is >420 (px) then we're on the browser and we're on a tablet\n } else if (width > 420) {\n // we're on a tablet\n return 'tablet';\n } else {\n // if none of the previous conditions were satisfied, we're either not on a device >420px, \n // or we're on the server, and a mobile view has been requested\n return 'mobile';\n }\n});\n```\n\nServer-side, this logic essentially determines if we're on mobile, or desktop. Note that it can't determine server-side if the device is large enough to be considered a tablet, however, generally the approach we take is that a mobile view sufficiently scales to suit a tablet, and that the changes between mobile and tablet are not as stark as the changes between mobile and desktop (and therefore don't result in a large cumulative layout shift).\n\nThis approach allows you to do a rough and ready responsive view server-side. This is ideal particularly for SEO and bots that'll visit your site in both a tablet and desktop mode. \n\n## Summary\nSvelte.js and SvelteKit let you do some pretty cool responsive work without bloating your code base, or the end output. More than that, you can deliver an SPA to client that is already SSR'd to their particular device (within reason) reducing the amount of time it takes to load and the layout shift they experience.","author":{"id":1,"firstname":"Adam","lastname":"Green","username":null,"preferedLanguage":null},"url_title":"responsive-views-in-svelte-js","sub_heading":"Control logic built into Svelte's HTML Markup means that creating alternate mobile, desktop and tablet views is fairly trivial but prone to bloat.","published_at":"2022-01-24T19:30:25.287Z","created_at":"2022-01-24T18:27:47.912Z","updated_at":"2022-03-10T11:39:57.309Z","seo":{"id":17,"title":"Creating Responsive views in Svelte.js and SvelteKit. - AdamGreen.Tech","description":"Control logic built into Svelte's HTML Markup means that creating alternate mobile, desktop and tablet views is fairly trivial but prone to bloat.","image":{"id":2,"name":"design icon.png","alternativeText":"","caption":"","width":1024,"height":1024,"formats":{"large":{"ext":".png","url":"https://cdn.adamgreen.tech/1b49121013dff129ad70481236c9aa32.png","hash":"1b49121013dff129ad70481236c9aa32","mime":"image/png","name":"large_design icon.png","path":null,"size":29.86,"width":1000,"height":1000},"small":{"ext":".png","url":"https://cdn.adamgreen.tech/cd0221f32b43f82d6c09697cb136fafe.png","hash":"cd0221f32b43f82d6c09697cb136fafe","mime":"image/png","name":"small_design icon.png","path":null,"size":17.22,"width":500,"height":500},"medium":{"ext":".png","url":"https://cdn.adamgreen.tech/a7c9b2c5f661a5e8bfe1e8be0160b554.png","hash":"a7c9b2c5f661a5e8bfe1e8be0160b554","mime":"image/png","name":"medium_design icon.png","path":null,"size":24.56,"width":750,"height":750},"thumbnail":{"ext":".png","url":"https://cdn.adamgreen.tech/cc2d414902e25685fc360474da88a72c.png","hash":"cc2d414902e25685fc360474da88a72c","mime":"image/png","name":"thumbnail_design icon.png","path":null,"size":7.67,"width":156,"height":156}},"hash":"a357959a91e050d469f84aaf0239e77e","ext":".png","mime":"image/png","size":6.93,"url":"https://cdn.adamgreen.tech/a357959a91e050d469f84aaf0239e77e.png","previewUrl":null,"provider":"do","provider_metadata":null,"created_at":"2022-01-13T15:43:49.024Z","updated_at":"2022-01-13T15:43:49.047Z"}},"featured":{"id":2,"name":"design icon.png","alternativeText":"","caption":"","width":1024,"height":1024,"formats":{"large":{"ext":".png","url":"https://cdn.adamgreen.tech/1b49121013dff129ad70481236c9aa32.png","hash":"1b49121013dff129ad70481236c9aa32","mime":"image/png","name":"large_design icon.png","path":null,"size":29.86,"width":1000,"height":1000},"small":{"ext":".png","url":"https://cdn.adamgreen.tech/cd0221f32b43f82d6c09697cb136fafe.png","hash":"cd0221f32b43f82d6c09697cb136fafe","mime":"image/png","name":"small_design icon.png","path":null,"size":17.22,"width":500,"height":500},"medium":{"ext":".png","url":"https://cdn.adamgreen.tech/a7c9b2c5f661a5e8bfe1e8be0160b554.png","hash":"a7c9b2c5f661a5e8bfe1e8be0160b554","mime":"image/png","name":"medium_design icon.png","path":null,"size":24.56,"width":750,"height":750},"thumbnail":{"ext":".png","url":"https://cdn.adamgreen.tech/cc2d414902e25685fc360474da88a72c.png","hash":"cc2d414902e25685fc360474da88a72c","mime":"image/png","name":"thumbnail_design icon.png","path":null,"size":7.67,"width":156,"height":156}},"hash":"a357959a91e050d469f84aaf0239e77e","ext":".png","mime":"image/png","size":6.93,"url":"https://cdn.adamgreen.tech/a357959a91e050d469f84aaf0239e77e.png","previewUrl":null,"provider":"do","provider_metadata":null,"created_at":"2022-01-13T15:43:49.024Z","updated_at":"2022-01-13T15:43:49.047Z"},"tags":[{"id":2,"name":"Svelte.js","description":"Articles relating to the front-end framework, Svelte.js.","published_at":"2022-01-23T23:08:27.715Z","created_at":"2022-01-23T23:08:26.335Z","updated_at":"2022-01-23T23:08:27.730Z"},{"id":3,"name":"SvelteKit","description":"All articles relating the Svelte.js Multi-page Framework, SvelteKit.","published_at":"2022-01-23T23:08:56.299Z","created_at":"2022-01-23T23:08:54.619Z","updated_at":"2022-01-23T23:08:56.316Z"},{"id":5,"name":"Responsive","description":"Posts relating to designing webpages and websites that adapt to the device they're rendered on e.g. mobile, tablet or desktop.","published_at":"2022-01-24T19:31:32.950Z","created_at":"2022-01-24T19:31:30.593Z","updated_at":"2022-01-24T19:31:32.967Z"}]}]

Responsive.

Creating Responsive views in Svelte.js and SvelteKit