Introducing Svelte

Asking this question might seem like a real shocker when we’ve been used to the likes of React, but it is possible – let me introduce you to Svelte!

Created by Rich Harris in 2016, it was designed to prove that you don’t need to create lots of extra component code but could write code that is much closer to vanilla JavaScript. Following this mantra means you can reduce the amount of code you need overall; in a sense, Svelte follows the principle of not reinventing the wheel when you already have perfectly good markup that can do the job. However, what makes it work is that it compiles code into reusable JavaScript modules – without the need to operate the framework at runtime.

Not running a framework at runtime is significant: we don’t pay the cost of shipping a sizable runtime library (and yes, tools like React get bigger, not smaller), plus our application will be super fast, without the abstraction you otherwise get with other tools.

Throughout this book, I will take you on a journey through creating a simple front-end ecommerce store that we can use on any small to medium online retail site. We’ll start with a quick review of how Svelte works in this chapter but then swiftly move through creating the various components required for our store, as well as sourcing data. We’ll take a look at a host of different topics on the way, such as managing events, styling, and the like – with the focus on creating our store but learning about the various parts that make up Svelte.

We have a lot to cover – so without further ado, let’s dive in. As with all things programming, we will be setting up our development environment, ready for working on our Svelte project.

Setting Up a Development Environment

Okay, with the introductions over, it’s time to get to business!

Okay, let’s move on. I’ve touched on the fact that we need Svelte, but asked one question: how do we get a hold of and install it? There are a couple of options open to us, so let’s take a look at them in greater detail.

Creating Your First Application

We could spend ages talking through how Svelte works, but that’s not so interesting – instead, let’s dive in and use the REPL tool to start manipulating some simple Svelte code! It’s a great way to learn, mainly as Svelte code is structured in a format that closely resembles how you might write a CodePen demo. We will revisit this structure shortly in more detail, but for now, let’s dive in and take a quick look at a typical “Hello World” app to get up to speed with using Svelte.

Breaking Into Using REPL

To get acquainted with Svelte, using the REPL tool, follow these steps:

1. 1.

   First, crack open your browser and navigate to www.svelte.dev. Click the REPL link at the top right of the page.

   The keen-eyed among you will note that you could equally browse directly to the REPL tool once you know the link. Browsing to this URL will work, but be aware though that it includes a version-specific reference to Svelte. You may end up invertedly browsing to and using an older version of Svelte if you’re not careful!

    

1. 2.

   Once at the page, you will see a split code window – on the left is an open file, App.svelte, with the Result, JS output, and CSS output tabs on the right. The tool comes with a version of the typical “Hello World” app running, which we can see in Figure 1-1.

    

1. 3.

   Try changing the value assigned to the name from 'world' to your name – see how it changes automatically on the right?

    
2. 4.

   Let’s add a little color to the result – after the opening <script> tag, insert the code as highlighted:

   <script>

     let name = 'Alex';

   </script>

   <h1>Hello {name}!</h1>

   <style>

     h1 { color: purple; }

   </style>
    
3. 5.

   The results shown on the right will automatically update, so we end up with “Hello…” in a purple font.

    
4. 6.

   Okay, let’s ramp things up a little. Inside the script block, leave a blank line after the let name= entry, and add this:

   <script>

     let name = 'world';

     function handleClick() {

       alert('no more alerts');

     }

   </script>
    
5. 7.

   Next, add in this button code immediately after the <h1> tag:

   <h1>Hello {name}!</h1>

   <button on:click|once={handleClick}>

     Click me

   </button>
    
6. 8.

   Try clicking the “Click me” button – what do you get? If all is well, we should see a dialog appear (Figure 1-2, shown overleaf).

    

You’ve now completed your first Svelte demo – easy, right? Most of the code we’ve used is plain vanilla JavaScript, but with some key differences: let’s take a moment to review what we’ve covered in this demo in more detail.

Understanding What Happened

So, what did we achieve in that last demo?

It is fair to say that while it may seem to have been a trivial exercise, this was intentional – it was more about working through the constituent parts of a typical Svelte application than exploring the intricacies of the code itself! We will explore the code in more detail throughout this book, but for now, let’s take a quick look at the sections that make up our application.

You will see it’s made up of three parts – we’ve included a <style> block, <script> block, and a markup section, which is standard for all Svelte apps.

We kicked off by browsing to the REPL tool for Svelte, which is a playground for testing code – we understood from earlier that this is perfect for getting started with Svelte, but we will later move to other tools.

The code we entered begins with a style block to add color to an H1 tag we will use in our demo. Next, we then added a script block, where we’ve defined a variable name to equal the text “world” and created a simple event handler. We then created standard markup to render that name and introduce a clickable button. There are two key differences, though – the use of parentheses to act as a placeholder for our name variable and the inline event handler to fire a message. If we click that message, we will get a simple alert to say “no more alerts” – it seems a little ironic to display a warning when we no longer want any alerts, but it is only a simple demo, after all!

Don’t worry, though, if sections such as the event handler don’t entirely make sense at this stage; it’s enough to know that the format we’ve used is a standard way to fire events in Svelte and equates (roughly) to <button onclick='alert("no more alerts")>Click me</button>.

We will cover events in more detail later in Chapter 5 of this book.

Okay, let’s crack on. Now that we’ve been introduced to Svelte, it’s time for a little theory. Yes, I know: theory isn’t everyone’s idea of fun, but it’s essential to understand how Svelte ticks and what makes it different from its competitors. Don’t worry, though, I will keep it short! With that in mind, let’s take a stab at answering that very question.

What Makes Svelte Different?

Looks harmless, right? The object we’ve just created (using that code) represents how it should display on the page and the virtual DOM. If we update the state in an application with such a component, this will be re-rendered as a new object; the virtual DOM has to reconcile that against the previous version to work out what should now be displayed.

This updating all sounds good, but hold on – if we already have a physical DOM, why do we need a virtual one? Doesn’t that add overhead to our project?

Tools such as React aim to let you build declarative, state-driven applications without worrying about state and performance – even with a virtual DOM, the speed is usually adequate for our needs. However, there are caveats to this – updating state is still a lot of work, and while features such as React’s Fiber will break things into smaller chunks, it won’t reduce the overall time it takes to update state.

Let’s think about that for a moment – if we updated the name property to use something else, then the diffing algorithm would have to (a) check the elements, (b) enumerate through attributes, and (c) update the DOM – in this case, the text.

That might not seem much, but bear in mind that it’s only point (c) that adds any value in this case – points (a) and (b) don’t change!

Suppose we were to change the props.item value, then we would be creating a new array of virtual li elements each time – while it may not be an issue and be sufficiently fast for your needs, it’s still unnecessary! We risk ending up landing ourselves with a bottleneck that becomes difficult to optimize at a later date.

What if we could achieve the same result without the use of a virtual DOM? This is where Svelte comes in – instead of compiling code at runtime (and therefore needing that runtime library), we compile at build time into pure, highly efficient imperative code.

Let’s say that a typical to-do app in Svelte weighs in at about 4Kb. Compare that to production versions of React and ReactDOM (taken from a CDN), without any application code, weigh in at 128Kb. That equates to 32x the size! Granted, it may not be an entirely fair comparison, but the point is that there is still a hefty increase that we have to consider when using tools such as React. You can see the steps we have to go through when using React, compared to Svelte, in Figure 1-3.

Although we can build entirely usable applications using Svelte by itself, this isn’t the only option – to take advantage of techniques such as server-side rendering (SSR) and code splitting (essential in today’s development), we can use Sapper.

Sapper is an application framework built using Svelte, which comes preconfigured with best practices such as SSR and code splitting. Svelte developers recommend it as the preferred way to build applications. It makes developing applications simpler, and we should consider it when it comes to architecting any project using Svelte.

What’s the deal with SvelteKit? Sapper is undergoing a complete rewrite, as it is based on techniques that have been available for a few years and have become outdated. Its replacement is SvelteKit, which is still in active development – we’ll explore this and more later in Chapter 12.

Okay, let’s move on. We need to cover one more topic before getting stuck into code, though, which is the issue of browser support. Svelte supports most recent browsers, with at least one exception – to understand what that means for us, let’s dive in and take a closer look.

Setting Up Our Project

We’ve already covered the various ways to install Svelte. For this book, I will focus on using option 2, the custom Svelte template, available from the main Svelte site.

It has several useful files and folders already configured for us, such as package.json and the src folder, making it easier to develop our project. It’s a simple process to set up the site, so let’s make a start.

Demo – Creating Our Initial Site

To set up our base site, ready for building into a store front end, follow these steps:

1. 1.

   The first step is to install Node.js and NPM – go ahead and browse to www.nodejs.org, and then download and install a version appropriate for your platform. If prompted, please use the default settings.

    
2. 2.

   Next, go ahead and extract a copy of the template-master.zip file from the code download that accompanies this book – this contains our preconfigured site, ready for installing.

   It’s also available from https://github.com/sveltejs/template/archive/master.zip.

    

1. 3.

   Go ahead and extract the template-master folder from within the zip file, and save it to your PC. Then rename it to sveltebook. Next, fire up a Node.js terminal session, and then change the working folder to the sveltebook folder from step 3.

   For the exercises in this book, I will assume the location is at the root of your C: drive. Please alter as appropriate if you would like to save it to a different location.

    

1. 4.
   At the prompt, enter npm install && npm run dev to install and run the project. After a few moments, we should see this in the terminal session:

   

    
2. 5.

   Assuming we do, switch to your browser, and then browse to http://localhost:5000 to see our base site in all its glory, with the text shown in Figure 1-4.

    

At this point, our site is now ready for us to develop into our store front end throughout this book. It was a simple exercise, but an important one – let’s pause for a moment to review the steps we covered in this exercise in more detail.

Exploring the Structure of Our Site

Remember how we worked through setting up a Svelte starter site at the start of this chapter, using the custom template provided by the Svelte developers? If we open the sveltebook folder we created earlier, Figure 1-5 shows us what to expect.

This const initiates every Svelte site. We can pass into it any number of defined property values, or props – in our case, name, which equates to the value world.

We’ve used basic styling here, but Svelte can use external style libraries such as emotion as well – we will cover how in Chapter 7.

The files we’ve run through are core to making Svelte work – we will, of course, add more when we develop components, but they will hang off these initial files.

Okay, let’s crack on. I’ve hinted that we will be building an online store front end as the theme for this book. The question is, what will our store sell, I wonder?

Setting the Background

Yes , indeed, our store will be selling coffee! At this point, I’m reminded of that saying from the movie Dante's Peak, where Greg, one of the geologists studying a volcano about to cause havoc with the town Dante’s Peak, goes a little crazy when given his daily cup by the town’s mayor and coffee shop owner. But I digress…

For this book, we will build out an online store that will sell roast coffee beans. Billed as one of the world's most popular drinks, coffee consumption is increasing, with America, Germany, Italy, and Japan being among the biggest importers of the product.

Throughout this book, we will explore the different elements that make Svelte, such as creating components, managing state, and adding data. We’ll also cover the logic required to route information, responding to events, and more – all will be based on creating code for our store, but at the same time, I will cover the essential theory for each topic.

We will then finish deploying our project to a host and exploring what we can do to extend it further by adding in payment facilities. So, as you can see, we have plenty to cover!

Summary

We can see creating a website as something of a roller coaster – there will be highs and lows, successes, and challenges to deal with, as we begin to develop what will become our final solution. Over these last few pages, we’ve started to look at our project’s background and get ourselves ready to create the site – let’s take a moment to review what we have learned before beginning the real development work.

We started by introducing Svelte before swiftly moving onto set up our development environment and exploring the various options to obtain the framework. We then dipped our toes into our first application, using the REPL playground, before exploring some of the principles behind how Svelte works and what makes it different from other frameworks.

We then rounded out the chapter by setting up the base site for our project. At the same time, we also covered the background details of what we will develop in this book.

Okay, so what’s next? Ah, yes, we need to start creating components that will form the basis of our online store! There is a good handful to make, so stay with me, and I will reveal all in the next chapter.

Understanding the Makeup of Components

If you have ever used CodePen demos, then you already know the basics behind creating Svelte components!

But I digress.

Getting back to reality, though, it doesn’t matter which framework those demos used – it might have been Vue, React, or even plain vanilla JavaScript. The same thing applies in each instance: CodePen demos are (broadly) separated into three areas, namely, CSS, HTML, and JS (or JavaScript). We can include links to external libraries, but the same principle still applies: our core code will reside in one of these areas.

Svelte works on precisely the same principle – we split code into three areas, each contained within their relevant markup tags. To see what I mean, let’s go ahead and create some examples, so you can see how this works in practice.

Creating an Example Component

The best way to get started with creating a Svelte component is to use the REPL tool. Although this might sound a little odd as a name, it is just a playground for writing code; it works in the same way as CodePen demos, so you should have no difficulty using it!

We can use the browser version, which is available at https://svelte.dev/repl, which is perfectly fine for our needs.

The URL for the Svelte REPL playground will redirect to a version-specific URL – this is normal and expected.

I you run the URL in Chrome, you can install the playground as an app in your browser – click the link highlighted in Figure 2-1 to install the app when prompted.

Wait for it to show this window (Figure 2-2).

We can then use the download symbol (second from left in the blue-gray bar) to download the finished code or create an account to save our work online if desired.

Okay, assuming you’ve added the app (or are on the REPL playground in the browser), let’s start creating our demo component as part of the next exercise.

Building the Example Component

To start our foray into creating components in Svelte, we will warm up with a quick demo by creating a Button component – this may be very simple, but it shows off some key features of creating and importing components in Svelte. Let’s take a look at how it works in more detail.

Creating a Custom Button

To set up the Button component, go ahead and follow these steps:

1. 1.

   First, fire up your browser, and head over to https://svelte.dev/repl; the URL will redirect to show a version-specific address – this is normal.

    
2. 2.
   Next, in the tab marked App.svelte on the left, add this code:

   <script>

     import DefaultButton from './DefaultButton.svelte';

   </script>

   <DefaultButton />
    
3. 3.

   Next, click the plus symbol to the right of the word App.svelte to add a new component.

    
4. 4.

   When prompted (it will show Component2.svelte), change the name to DefaultButton.svelte.

    
5. 5.
   Go ahead and add in this script code to that tab:

   <script>

     export let buttonAction = () => alert('Welcome to the world of Svelte!');

   </script>
    
6. 6.
   In the same tab, miss a line and then add in this style block:

   <style>

     button {

       color: #ffcc00;

       background-color: #333;

       border-radius: 5px;

       padding: 8px;

       border: none;

       font-size: 20px;

     }

   </style>
    
7. 7.
   Finally, leave a line blank, and then add in this markup:

   <button on:click={buttonAction}>

     <slot>Hello World</slot>

   </button>
    
8. 8.

   The editor will automatically save the code – after a few moments, you will see the button shown in Figure 2-3.

    

1. 9.

   Go ahead and click it – you will see the message appear as indicated in Figure 2-4.

    

1. 10.

   The demo is now complete – you can either download the code for future use or save it if you have logged in with an account.

    

Congratulations, you’ve now created your first component in Svelte! I know that some of you might wonder what all the fuss is about, as that was a straightforward exercise. But his simplicity is what makes Svelte so fantastic; it was designed to require minimal code and operate very much like writing CodePen-style demos.

However, it hides a lot of the code required to create and run the demo; if you look at the JS output window in the REPL playground, you will see what I mean! Our less than 24 lines are multiplied by a factor of almost 5 when it comes to building the final code!

But I digress. Although the code looks very straightforward, it does include a couple of essential points that are worth noting – let’s take a look at the code in more detail.

Reviewing the Code

So, what did we achieve in the last demo?

If we take a closer look at the code again, we can see that much of what we wrote was plain HTML markup and CSS styling – this in the main is just standard code, so easy to understand.

However, what makes it different is the simple, easy-to-read style of coding – Svelte uses the same principles used by CodePen, where we focus on the key elements and let Svelte build the code into valid JavaScript. In this last demo, we created a simple Button component – we started in App.svelte by adding an import to our base component before calling an instance of it on the page.

We then switched to creating that component; at the top of DefaultButton.svelte, we first inserted a script block that contains an export statement:

<script>

  export let buttonAction = () => alert('Welcome to the world of Svelte!');

</script>

In a nutshell, export in Svelte allows us to expose a property from within a component, which we can call from a parent component. In this case, we exposed buttonAction, which triggers the alert to display the message.

Next up came a styling block, using standard CSS styles available to any component that supports them. We then moved onto the last block, which is the markup:

<button on:click={buttonAction}>

  <slot>Hello World</slot>

</button>

At face value, this looks like any other standard markup for a <button> element, but notice the presence of <slot></slot>? It is a placeholder for any child elements that should reside inside the parent button element, which will override any text or elements present in the original component.

That last statement is crucial – if we were using React, for example, then we would have done something like this:

<Button label={"This is a label"} />

“There is nothing wrong with using prop values, right?” I hear you say we override what’s already in the component, right? I would 100% agree with you: but what if we didn’t have to specify that prop value? Svelte is clever enough to work out if there are any child elements and drop them into the <slot> placeholder – no need to specify a prop value!

To prove it, change the <DefaultButton /> tag to this in your demo:

<DefaultButton>

    This is an overridden button

</DefaultButton>

Watch how it changes automatically in the Result window on the right (Figure 2-5). See how easy that was to change the text?

Okay, now that we’ve become acquainted with the basics of using components, let’s put some of that knowledge to good use and begin to create the first components for our shopping cart demo. Over the following few pages, we’ll reuse some of these principles to build out components to make a simple cart icon at the end of the chapter, which we will then style later in the book.

Setting Expectations

At this point, it’s an excellent time to set some expectations – after all, we simply don’t have the space to build something that replicates the likes of Amazon!

Okay, let’s continue. Before we start coding, let’s quickly cover an essential part, which is understanding the architecture we will use in our demo.

Working Out the Architecture

Architecture is an essential part of any site – this is what makes it easier to manage features such as data or state and help keep our code DRY, so we’re not repeating ourselves too often. For this book, we will keep the structure very simple, with all of the various elements we create in the \src folder.

If we take a look at the folder structure, we can see that the \src folder contains the files and folders listed in Figure 2-6 – note that App.svelte and main.js come as standard; we will create the others.

Inside the \components folder, we will create the following:

• Button.svelte – We’ll use this for the add-to-cart feature in the product gallery and on individual product pages.

• Cart.svelte – This is the main shopping cart component for the site.

• Header.svelte and Footer.svelte – These we will use to create the header and footer for the page layout.

• Products.svelte – This forms the main product gallery for the site.

• Product.svelte – This is the product card with individual details of a chosen product.

Switching to the \pages folder, we will add three pages: About, Coffee, and Home. These are not compulsory, but give a little context to the site and make it look a little more realistic. The About and Home pages will be self-explanatory; the Coffee page is a little history about the coffee we would be selling from our site.

There are two ancillary files we will also create and store at the root of the \src folder in the next chapter – these are productlisting.js and stores.js.

To understand how it all hangs together, let’s take a look at a schematic of the site architecture that I’ve created in Figure 2-7.

Here, we can see the parent App.svelte, which calls components and pages from the src folder. During the build process, Svelte pulls the script code into a compiled bundle.js file, with styles in bundle.css. We can directly call images from within the \public\images folder, at the same time.

As you’ve been working through the demo, notice anything particular about filenames, say in comparison to React? It doesn’t matter if we’re developing a page or component; they are effectively the same thing when it comes to file naming in Svelte. It comes with a big proviso, though: they all follow the same structure, but when it comes to adding code, there are some differences.

We will cover it later in more detail.

Moving on, the first task is to update the main application component, App.svelte.

Making a Start with App.svelte

For our first exercise, we need to update the App.svelte file – this is effectively the master file, of which all of the other files will hang. We’ll use this to generate the structure for our page – let’s take a look at what is involved in more detail.

We now have the basics for our site, but I’ll bet you’re wondering: what exactly have we added? It is what makes Svelte so easy to use; we focus on producing clean, easy-to-read code!

Most of what we add will be standard JavaScript, CSS, and HTML markup, with only a few Svelte keywords in the mix. That said, we should cover a couple of essential points from this demo, so let’s take a moment to review the code in more detail.

Creating the Header

Now that we have our main app.svelte file in place, along with a component index, it’s time to create some of the missing components.

There are seven in total that we need to create; all follow similar principles. We also have three pages to assemble too; for convenience, we will lift copies of the relevant files from the code download that accompanies this book. At the same time, we will also copy across various images required for the site. I’ve sourced these from multiple locations, such as FreeSVG.org (https://freesvg.org), but feel free to use your own versions if you prefer.

Let’s make a start with setting up the header component.

Short, sweet, and straightforward – that’s how I like my exercises. Okay, yes, I know that might open me up to various – shall we say – comments, but there is some truth in the matter: anything for a simple life!

There is, however, one crucial point that we should explore more from this demo – the use of the writable import. Ordinarily, I would go into detail here, but we will cover it and more when we explore data and state management in the next chapter. For now, all we need to know is that it deals with passing values between components and that this (in a way) is similar to the principles used by React’s props facility.

Let’s move on. The next component we will set up is the footer – this one is purely markup, although we use a plugin. To see what I mean, let’s dive in and take a look.

Setting Up the Footer

We have the main app file in place, along with our component index and the header – we can’t have the latter without top and tailing it with a footer! Fortunately, this is just as easy to set up – let’s take a look at what’s involved in more detail.

That’s another step closer to getting the basic site set up – we still have a few more components to add, though! Most of what we added in this demo is just plain HTML markup; the CSS styling we will add later when we cover styling in Chapter 7. There is one point of interest, and that’s the plugin we’ve used: svelte-inline-svg.

The plugin turns that code into this (Figure 2-8).

It is preferable to in-line SVGs where possible, as we can style individual elements within the SVG. SVGs in image files will be treated as images and can only be styled via externally facing properties such as width and height.

Okay, let’s keep going and turn our attention to setting up the product gallery, which will be the shop window to our store.

Creating the Product Gallery

Assembling the product gallery is the most critical part of our project – after all, we clearly wouldn’t be able to sell without products and therefore make money!

For this book, we’ll keep to just a handful of products that we will source from a data block – we will explore sourcing data using other methods later in the book. To get things started, let’s take a look at the code required in more detail.

Although we are getting close to a starting site that runs, if we were to run our code now, it would error – we still need to add several components! One of these components is the product detail (or description) page – let’s run through what’s required in more detail.

Creating a Button Component

Yes, the sharp-eyed among you should spot that we’ve not created the component, even though we’ve added references to one! Let’s quickly correct that omission, by adding one in now.

Excellent, now that we’ve gotten that out of the way, let’s carry on with adding the cart to our demo.

Creating the Remaining Pages

At this point, we’ve now added the bulk of the code required for our store – there remain only three files to source, About.svelte, Coffee.svelte, and Home.svelte.

These are some additional pages to help make our mini site look a little more realistic. They are not obligatory, but if you don’t include them, you will need to remove references to allow the site to work!

All three files can be sourced from the \src\pages folder in the code download that accompanies this book; copy and paste the folder as-is into the \src folder of our project area.

File Formats and Svelte – A Note

By now, I’m sure you will have noticed that we’ve used two file formats – .svelte and .js – when constructing our components.

It’s important to note that you will simply need to use .svelte for constructing pages and components in most cases. The only time we need to use .js as a file format is when importing content that is not a component. By this, I’m thinking of files such as stores.js; all other files should use the .svelte extension during development.

Okay, that aside, everything is now in place: it’s time to start.

Testing the Initial Site

We now have the basics of our mini store – granted, it won’t be perfect, but it will at least show the core elements of how we might begin to create such a store using Svelte.

It’s at this point we can now run the site; to do this, switch to a Node.js terminal session, and then run npm run dev at the prompt (making sure you change the working folder first). If all is well, we should see something akin to Figure 2-9.

Okay, it won’t win any styling awards anytime soon, but, hey, it is at least running, albeit a little functional! It gives us an excellent base to start fleshing out how it looks and works – this is something we will do through five chapters before deploying it into production in Chapter 9.

Summary

Building a site should be considered something of a journey – it’s not about the end product, but the journey, which is more important! It is no different with Svelte; we still use the same principles, irrespective of the framework. We’ve started on that journey to construct our microsite; let’s take a moment to review what we learned thus far in this chapter.

We began working through the principles of creating a simple component, using the playground that comes with Svelte. We then moved onto setting expectations for our project before exploring the proposed architecture for the site.

Next up came the start of the construction process – here, we began with the core app file before working our way through each of the various components. We then finished pulling the product pages from the code download (as they are simple markup pages) before testing the site for the first time. Granted, it won’t win any style awards any time soon, but we will quickly fix that later in this book!

Right, we still have a lot more to cover, so let’s move swiftly on: it’s time to get down with data! All right, that was a terrible play on words, but data plays a fundamental role in any site. We’ve added in simple data to start things off, but what if we wanted to use a third-party source, for example? No problem – stay with me, and I will show you that and more when we explore how to link in data to our Svelte site.

Why Is Data So Important in Svelte?

There is a simple answer to that question, although the question we should really be asking is what makes state and data so important in Svelte? This has a lot to do with what makes Svelte tick: reactivity. You see, Svelte is all about keeping the DOM in sync with changes we make in application state. This could be anything from changing a value to performing multiple actions in response to a triggered event.

While it is true that it is written in Svelte, the same principle applies to frameworks such as React and Vue, where we trigger the execution of a function on clicking a button. When this happens, Svelte will tell the assignment with code that tells the DOM to update the state.

This is specific to Svelte and is called a reactive declaration – it is used to compute a value from more than one base value. It will recompute automatically when any of the base values change: in this example, this would be numcount.

We can also add numbers=numbers to the original code which will work just as well; a spread operator makes it clearer as to what we’re doing.

It works now! It does mean that we can’t use keywords such as pop, shift, unshift, or splice; instead, we have to use assignments to trigger an update in state within Svelte.

Moving on, although we talk about maintaining (or updating state), in reality we’re updating values or data in code. There are several different ways to do this – let’s take a look at the options.

For exercises in this chapter, we will use the REPL playground for convenience; these exercises will work just as well if you want to run them locally.

Passing and Setting Values in Code

If we need to update data or values (and therefore change state), we can use any one of several different techniques to affect the update.

It’s important to note that each has its own quirks; we will explore the difference between each later in this chapter and understand when we should use each method.

Okay, let’s move on. Throughout this book, we’re focusing on building a mini ecommerce site to sell coffee. We will use some of the techniques we’ve covered so far, but before we do, let’s build some quick demos to see how some of what we’ve explored so far works in action. We’ll begin with passing prop values between components.

Exploring the World of Props

Cast your mind back to the start of this chapter – we talked about how to manage state inside of a component, but doing so between components requires a whole different approach. We’ve briefly covered the three ways to do this; our starting point (and which is similar to the likes of React) is to set and pass properties between components.

This is arguably the simplest method, but also the most clunky – we have to pass a property down through each layer, which can get cumbersome if doing this for a component more than two to three layers deep. There are ways to get around that which we will cover in more detail shortly, but for now, let’s take a look at how to pass props within Svelte in more detail.

Passing Props

To set up this demo, run through these steps:

1. 1.

   First, go ahead and browse to https://svelte.dev/repl – as before, just be aware that it will redirect to a version-specific URL, to indicate which version of Svelte is being used.

    
2. 2.
   Next, in the first tab which should be labeled App.svelte, add this code:

   <script>

     import Button from "./Button.svelte";

     function Twitter() {

       console.log("Twitter button clicked");

     }

     function Instagram() {

       console.log("Instagram button clicked");

     }

     function Facebook() {

       console.log("Facebook button clicked");

     }

   </script>

   <div>

     <h1>Get me on social media!</h1>

     <Button name="twitter" handleClick={Twitter} />

     <Button name="instagram" handleClick={Instagram} />

     <Button name="facebook" handleClick={Facebook} />

   </div>
    
3. 3.
   Next, click the + symbol to the right of the tab name, and replace the (highlighted) word Component2 with Button:

   <script>

     export let name;

     export let handleClick;

   </script>

   <button on:click={handleClick}>{name}</button>
    
4. 4.

   If all is well, we should see something akin to the screenshot shown in Figure 3-1.

    

Cool – it’s a simple demo, but illustrates perfectly how we can pass properties to a single component!

Although we’ve passed distinct values in each instance, there is more we can do: we can even set default values or use a spread operator if we want to pass multiple values to that component. In the meantime, let’s take a quick look at the code we’ve created, ready to see how we might use it in our shop demo later in this chapter.

Making Use of Context in Svelte

If we need to pass values between components (be they static, dynamic, or even a function), then this is straightforward when the components are very close together and in the same hierarchy. By default, we must maintain state at the parent level and pass down – if we pass upward, Svelte will complain that we are creating a circular effect.

If the components are some ways apart, or not even in the same tree, then using props becomes less practical; instead, we have to use the Context API. This is perfect for communicating with multiple components and descendants, but avoids the need to pass props – instead, we communicate with a central store (not to be confused with Svelte stores – more later!).

Granted, this is just an example, so I certainly wouldn’t advocate using my naming convention, but it’s the principle of how it works that counts!

We can only use getContext to retrieve a key either within the component which used setContext or in one of its descendants – this descendant can be several layers deep, but the important point here is we do not have to pass values via intermediate descendants.

If we need to communicate with a component in a different tree, then we need to use Svelte store tool – more on this later in this chapter.

Okay, enough talking: it’s time to get dirty with context, so to speak! To really understand how it works, let’s take a look at a quick demo using the Svelte playground.

Making Use of Context

In this demo, we’re going to switch from one color to another, after a two-second delay:

1. 1.

   First, browse to the Svelte REPL site at https://svelte.dev/repl – don’t forget that the URL will redirect, as from previous exercises.

    
2. 2.
   In the App.svelte tab, add this code, which will perform the change using setContext:

   <script>

     import {setContext, getContext} from 'svelte';

     import {writable} from 'svelte/store';

     import Child from './Child.svelte';

     let state = writable({color: 'hotpink'});

     setContext('state', state);

     setTimeout(() => {$state = {color: 'red'}},2000);

   </script>

   <Child />
    
3. 3.
   Switch to a new tab, and then rename it to be Child.svelte – in the main part of this tab, add this code:

   <script>

     import {getContext} from 'svelte';

     const state = getContext('state')

   </script>

   <h1>

     This is the {$state.color} value

   </h1>
    
4. 4.

   If all is well, we should see the color change from hot pink to red, as indicated in Figure 3-2.

    

You might want to increase the setTimeOut value to something larger to see the effect happening – the change is very quick!

Another simple exercise – this is what I love about Svelte! Svelte makes writing code simpler, as it uses standard markup and JavaScript where possible, with very little extra required that is specific to Svelte. It makes it a cinch to use tools such as setContext and getContext – let’s take a look at the code we’ve used in the last demo to understand how it works.

Creating and Maintaining Svelte Stores

Over the last few pages, we’ve explored how using props can help with passing information between components. While it works well in principle as a technique, it isn’t without its flaws; it can only handle components in the same tree, and we have to pass the values down through each layer which can become cumbersome. Context goes some way to resolving this, but still only within the same tree.

The real question is, how can we manage passing components across different trees? There is a way to do this, and we touched on using it in the last demo: Svelte stores .

The basic principle is that instead of passing values down, we store them in a central location, so we can access any value needed from any component. It requires a little more code to operate, but removes the need to pass down values through multiple layers – definitely a win for us! To see what I mean, let’s take a look at a quick example in more detail, as part of our next exercise.

Operating Stores

To set up and operate a Svelte store, follow these steps:

1. 1.

   First, browse to https://svelte.dev/repl – this URL will redirect to show which version of Svelte we are using (currently 3.35.0 at the time of writing).

    
2. 2.
   Next, in the App.svelte pane on the left, add this code:

   <script>

     import { username } from './stores.js'

     username.set('new username');

     const newUsername = 'Alex';

     username.update(existing => {

       console.log(`Updating username from ${existing} to ${newUsername}`);

       return newUsername

     })

   </script>

   <h1>

     Hello, {newUsername}! </h1>
    
3. 3.

   Now go ahead and hit the + symbol next to App.svelte – rename the tab that appears to stores.js.

    
4. 4.
   In the window below it, add in this code:

   import { writable } from 'svelte/store'

   export const username = writable('Guest');
    
5. 5.

   Take a look at the right – if all is well, we should see the text shown in Figure 3-3.

    

1. 6.

   Next, press Ctrl+Shift+I (Win, Linux) or Cmd+Shift+I (mac) to bring up the browser console – we should see the update logged, similar to Figure 3-4.

    

And with that our Svelte store has been easily set up. The great thing about stores is that we can access values from any component and do not have to pass values down the chain from parent to child (as is the case for props). It is true that this last exercise was a little simplistic, but the real value will come when calling values from any component – these we treat as if they were standard variables in our code.

Leaving that aside, creating a writable store is only part of the picture; there are a few more tips and tricks we can use to really take advantage of stores. Let’s take a moment to explore the code we’ve used in more detail, to see how it fits into the wider picture.

Understanding the Differences

Svelte props, Context API, or stores, which one do I use? It’s a very good question. We’ve covered three useful tools, but you thinking it might seem confusing as to which we should use and when!

I’ve produced a flowchart that summarizes which option to use, which is shown in Figure 3-5.

The first question to ask is if we need to cross over between different component trees – to use the real branch analogy, is that component further down the same branch, or on one round the other side of the tree, or maybe even higher? If it is lower down on the same branch, then we can use props or the Context API. Either will work, but bear this in mind: if we need to pass values down more than say two to three levels, using the Context API will be the better option.

If, however, our target component is elsewhere on that proverbial tree (say round the other side, for example), then the best option to use is stores. This allows us to use a central location which is accessible from anywhere in our code, irrespective of where the component is in the tree (virtual or real!)

Stores can be a little tricky to manage, particularly if a project you’re working on becomes complex; the key to making it work lies in understanding where the components sit in the tree hierarchy and whether you need to reference values from different locations in the same tree or across multiple component trees in your code.

Now that we’ve covered the different ways to pass values around our code, it’s time to put them into practice. Some of you may have noticed that we’ve touched on using one of the features already; before we get practical with code, let’s quickly cover off what is in our code, before adding new features.

Adding Functionality to Our Site

Let’s take another closer look at the website code we’ve created so far and in particular two files: stores.js and Header.svelte.

We could use standard props, but this would be cumbersome. Not only would we have to pass multiple values down from parent to child, we would likely have had to implement data twice as the product data would have been inaccessible from within the Header component. Using a store makes it simpler to access from anywhere in the site and allows us to maintain a single source of truth for data.

Moving on, over the next few pages, we will focus on adding in two techniques. We will add in a derived store to help calculate the total cost of our basket shortly, but first, let’s work on adding support for props.

Exploring Alternative Data Sources

So far, we’ve concentrated on constructing front-end features using Svelte – after all, this is what Svelte is all about, right? We used a Svelte store to create our data “back end,” which works great for a small site.

This point did get me thinking though: What if we needed to scale out? How would this look? We of course would need something such as GraphQL; in this current environment, it would be a popular choice. The key though would be to connect the two: there are several ways to achieve this connection.

One of the more well-known ones we could use is a package called svelte-apollo, available from https://github.com/timhall/svelte-apollo. Created by Tim Hall, the package is designed to integrate support for GraphQL when using Svelte. It’s written to return data in a Svelte store format which we can read and update as needed. There is an excellent demo and two articles on how to add GraphQL support, on the Techformist website – note you will need to read and complete both; otherwise, the first won’t operate correctly!

The articles are available at https://techformist.com/posts/2019/2019-08-15-todo-app-using-svelte-graphql/ and https://techformist.com/spin-up-your-own-local-graphql-server-within-15-min/.

Hopefully this gives you a flavor of what is possible – while Svelte focuses more on the front-end UI, it doesn’t mean to say we can’t hook it into a back-end system such as GraphQL. Doing so will open up a world of possibilities – we could connect it to any manner of databases that support GraphQL or even into a third-party cloud-based system such as DatoCMS (https://datocms.com) or Hasura (https://hasura.io)!

Summary

Over the course of this chapter, we’ve covered a variety of different concepts around passing data between Svelte components, as well as updated our site demo; let’s take a moment to review what we have learned in this chapter.

We kicked off by answering that all-important question of why data is so important in Svelte; we learned that this all stems from the concept of reactivity and how Svelte manages state within the application. We then moved onto understanding the different methods for passing information, before exploring each one in turn to understand how each operates and the constraints we may face when using the method.

We then turned our attention to adding new features to our website demo – at this stage, we covered just the markup, as styling will feature in a separate chapter later in the book. We worked through examples to add in prop support and new functionality using derived stores, before rounding out with a quick discussion about using alternative data sources such as GraphQL to scale up data for a Svelte application. We still have a lot more to cover however. The next chapter is where things will start to really get interesting, as we add logic to HTML markup within our Svelte application. Yes, my friends, it’s time to make some decisions and write logic.

Creating If-Else Conditions

Look familiar? Sure, it’s written in Svelte, but that is purely syntax – it should be easy to work out to only display a logout button if the user has already logged in.

This simplicity is the beauty of Svelte – when it comes to exploring functions such as this one, Svelte doesn’t overcomplicate things; it strives to keep code as clean as possible. The only difference is the hash or slash symbols; many other frameworks already used brackets or parentheses.

Keep that thought in mind. To see what I mean, let’s take a look at implementing a simple if-else block in Svelte to display a QR code provided that the input string is not empty.

Creating a QR Code

To show a QR code on the screen, follow these steps:

1. 1.

   First, go ahead and browse to www.svelte.dev/repl – don’t forget about the by-now-familiar redirection that will happen!

    
2. 2.
   Next, in the App.svelte tab, enter this code:

   <script>

     let inputText = "I love Svelte!";

     let textPresent = false;

     let API_URL = "https://api.qrserver.com/v1/create-qr-code/?size=150x150&data=";

     if (inputText !== "") {

       textPresent = true;

       API_URL += inputText;

     }

   </script>
    
3. 3.
   Leave a line blank, and then add in this markup:

   <h1>

     A Random QR Code...

   </h1>

   {#if textPresent}

     <img src={API_URL} alt="qr-code"/><br>

   {:else}

     <h2>

       Are you sure you can see me?

     </h2>

   {/if}
    
4. 4.

   If all is well, we should see a QR code appear on the right (Figure 4-1).

    

This exercise was a simple one, highlighting how we can use the classic if-else statement in our Svelte code. Indeed, the syntax might look a little different, but the underlying principle is identical to most other languages that support this function! That said, it’s essential to understand how this code works, so let’s pause for a moment to review it in more detail.

Implementing Each Conditions

Cast your mind back a few years – anyone remembers doing a for...while or for...until type loop in their code? Yes, that blast from the past is something you would likely have had to do when iterating through a bunch of items – it was admittedly clunky, but it worked!

Fast forward a few years, and we now have the each block – it’s become a standard way to iterate through any number of different objects, irrespective of how many we might have.

As a function, each exists in all manner of different frameworks, such as React or Vue – Svelte is no different. It works in much the same way as other frameworks, with only minor differences in syntax; let’s take a closer look at an example as part of our next exercise.

Demo – Iterating Through an Each Block

Iterating through an #each block is very straightforward in Svelte. To see how, follow these steps:

1. 1.

   First, browse to www.svelte.dev/repl – don’t forget the URL redirection that will kick in!

    
2. 2.
   Next, we need to add in the script and markup – in the App.svelte tab section, start by adding this script block:

   <script>

     let coffees = [

       { id: 'coffee1', name: 'Peruvian Blend' },

       { id: 'coffee2', name: 'African Inca' },

       { id: 'coffee3', name: 'Ristretto' }

     ];

   </script>
    
3. 3.
   Next, leave a line blank, and then add some rudimentary styling:

   <style>

     ul {

       list-style-type: none;

       display: grid;

       grid-template-columns: 1fr 1fr 1fr 1fr;

       grid-template-rows: 1fr 1fr 1fr;

       gap: 10px 10px;

     }

     li {

       padding: 10px 5px;

       border: 1px solid black;

       text-align: center;

     }

   </style>
    
4. 4.
   We have one more section to add – this is the markup for our page. Go ahead and leave a line blank, and then add in this code:

   <h1>Coffees for Sale</h1>

   <ul>

     {#each coffees as { id, name }, i}

       <!-- open each block -->

       <li>

         <a target="_blank" href="{id}">

           <img src="https://via.placeholder.com/150" alt="placeholder">

           <span>{name}</span>

         </a>

       </li>

       <!-- close each block -->

     {/each}

   </ul>
    
5. 5.

   If all is well, we should see our three fake products appear on the right after a few moments, as shown in Figure 4-2.

    

Mmm… the thought of coffee is making me thirsty… but I digress! We will come back to coffee later, but for now, it’s worth taking a closer look at the code we’ve just created in the last exercise. Most of it is standard HTML markup and CSS styling, but we should cover a couple of essential points in more detail.

Removing the Right Item

If you need to modify or remove items in an #each block, by default, Svelte will remove the items from the end, which is not always where you want them to be removed! Removing an item will drop it out of the list, but it will update other items when we want to leave them alone.

Fortunately, there is a way to get around this, which is to use keyed #each blocks – we assign an identifier to each item and reference it by ID rather than position. That way, we can be sure to remove the correct item and leave the rest alone.

The best way to understand how this works is to see it in action. For our next exercise, we will adapt the previous demo. It only requires some minor changes, but it’s worth it if we want to retain some sense of sanity!

Removing a Selected Item

Removing a specific item is easy with Svelte – to do so, follow these steps:

1. 1.

   First, browse to www.svelte.dev/repl – note that the now-familiar warning about redirection still applies!

    
2. 2.
   Next, go ahead and add this script block at the top of the App.svelte tab:

   <script>

   let coffees = [

     { id: 'coffee1', name: 'Peruvian Blend' },

     { id: 'coffee2', name: 'African Inca' },

     { id: 'coffee3', name: 'Ristretto' },

     { id: 'coffee4', name: 'Peruvian Blend Decaff' },

     { id: 'coffee5', name: 'African Inca Decaff' },

     { id: 'coffee6', name: 'Ristretto Decaff' }

   ];

   function handleClick() {

     coffees = coffees.slice(5,6)

   }

   </script>
    
3. 3.
   Next, leave a line blank, and then add in these styles – they are not obligatory, but will help make the demo look a little more presentable:

   <style>

     ul { list-style-type: none; display: grid; grid-template-columns: 1fr 1fr 1fr; grid-template-rows: 1fr 1fr 1fr; gap: 10px 10px; width: 200px;

     }

     li { padding: 10px 5px; border: 1px solid black;    text-align: center; }

   </style>
    
4. 4.
   Finally, it’s the turn of the markup – for this, miss a line, and then add in the following:

   <h1>Coffees for Sale</h1>

   <button on:click={() => handleClick()}>

       Remove selected item(s)

   </button>

   <ul>

     {#each coffees as coffee (coffee.id)}

       <!-- open each block -->

       <li>

         <a target="_blank" href="{coffee.id}">

           <img src="https://via.placeholder.com/150" alt="placeholder">

           <span>{coffee.name}</span>

         </a>

         </li>

       <!-- close each block -->

     {/each}

   </ul>
    
5. 5.

   If all is well, we should see something similar to the previous demo, but this time with the addition of a button, as shown in Figure 4-3.

    

1. 6.

   You will notice that I’ve extended the number of items this time around to make it a little more interesting – if we click the button, we should see that Svelte has removed all except Ristretto Decaff. We can verify this too in the browser console, as it returns the results of what is left in coffees, as shown in Figure 4-4.

    

At first glance, it might not look like we’re changed that much – granted, we’ve doubled the number of products. Apart from adding an event handler (a subject we will revisit in the next chapter), there is only one other minor change. Take a look at the #each block carefully – notice what it is?

Fetching Content

When it comes to sourcing data for a project, there will undoubtedly be instances where it might take a few seconds to retrieve, right? Without some form of control, our code will simply keep iterating through each step – with the likely result that it falls into a complete heap of errors due to no data!

What can we do? Well, we can use await. Anyone who’s worked with JS promises will know this is a great technique to pause execution until a promise to complete another task is completed successfully or rejected. As long as that task finishes without issue, then the original job can resume execution.

Svelte includes such functionality by default, in the form of await – this works in the same way as standard JavaScript, although the syntax may look a little different. In reality, the only differences are the use of special characters to signify Svelte keywords; the rest of an await block works in the same way as standard JavaScript.

Excellent, we’re now good to go with the demo, so let’s crack on and see how await works in Svelte.

Demo – Sourcing Fake Products

We can easily retrieve data using Svelte’s fetch command – to do so, use these steps:

1. 1.

   We’ll start by browsing to www.svelte.dev/repl – don’t forget the redirection!

    
2. 2.
   In the App.svelte tab on the left, go ahead and add this script block:

   <script>

     const fetchImage = (async () => {

       const response = await fetch('https://

   fakestoreapi.com/products/1');

       return await response.json();

     })()

   </script>
    
3. 3.
   Next, leave a line – we need to add some rudimentary styling, so drop in this code:

   <style>

     div {

       width: 200px;

       border: 1px solid black;

       display: flex;

       flex-direction: column;

       align-items: center;

       padding: 10px;

       animation: fadeIn ease 1s;

     }

     @keyframes fadeIn {

       0% {opacity:0;}

       100% {opacity:1;}

     }

     img {

       display: block;

       width: 150px;

       height: auto;

     }

     span {

       text-align: center;

     }

   </style>
    
4. 4.
   We have one more section to add, which is the markup for our demo – for this, miss a line in the App.svelte tab , and then add in this code:

   <h1>My Fake Store</h1>

   {#await fetchImage}

     <p>...loading products</p>

   {:then data}

     <div>

       <img src={data.image} alt="product" />

       <span>{data.title}</span>

     </div>

   {/await}
    
5. 5.

   If all is well, we should see this fade in on the right after a few seconds (Figure 4-5).

    

There is one thing missing from the image at the end of the last step of that exercise – the image fading into view! Unfortunately, the marvels of modern printing mean it’s not something I can demonstrate on paper, so hopefully, you will have seen it when running the demo.

That aside, this demo highlights a few critical points around using await and fetch, so let’s take a moment to review the code in greater detail.

Exploring Existing Code in the Demo

Right, take a good look through the code. Notice anything?

The keen-eyed among you spot something – we’ve already used some of the code we’ve covered in this chapter in our shop demo. Yes, I confess: it was unavoidable. Otherwise, we might have had to wait even longer to get something working!

That said, the code already included isn’t that extensive – it centers around three files, namely, Cart.svelte, Product.svelte, and Products.svelte. In reality, the latter two are very similar; I suspect that we could create a component that served both purposes with a bit of work.

In this instance, we’re using it to iterate through the cart – if it sees a quantity greater than zero, we add an image of the product, the product name, quantity, and add or remove buttons into the cart.

It is that simple – there is nothing more to it! To see what I mean, let’s dive in and look at adding a couple of features to our shop, starting with adding a login button.

Updating the Shop

A login button, I hear you say? What does that have to do with controlling logic, I wonder?

Well, the answer is simple – it’s not the button, but the condition check behind it that is of interest to us! It’s effortless to implement something to fake the appearance of a logged in user, so let’s dive into our first update and take a closer look at the code.

Adding Login Functionality to Our Site

We will add a simulated logged in user to our shop for the first of two demos that relate to our shop. We won’t cover the back end but instead focus on the UI – it will use the if-else function we’ve covered, plus the getContext and setContext feature from earlier in the book.

Adding Login/Out Links

To set up the appearance of a fake logged in user, follow these steps:

1. 1.

   First, go ahead and crack open App.svelte from within the \src folder – scroll down until you see this line:

   export let name;
    
2. 2.
   Leave a line blank, and then add in these two statements:

     import { setContext } from "svelte";

   let loggedIn;
    
3. 3.
   Immediately below that line, add in this condition check:

   if (name == "") {

     loggedIn = false;

   } else {

     loggedIn = true;

   }

   setContext('key', {

     loggedIn

   });
    
4. 4.

   Go ahead and save the file – we can close it at this point.

    
5. 5.

   Next, switch to the Header.svelte component from the \src\components folder, and look for this line:

   let loggedInText = "Hi, {name}";
    
6. 6.
   Immediately below it, leave a line blank, and then add in this code:

   import { getContext } from "svelte";

   const { loggedIn } = getContext('key');
    
7. 7.
   Scroll down to the markup, and then replace the code in the <div class="basket"> block with this code, as highlighted:

   <div class="basket">

     {#if loggedIn}

       <div>Hi, {name} | Logout</div>

     {:else}

       <div>Hi, Guest | Login</div>

     {/if}

     <div><InlineSVG src="/images/shoppingcart.svg" {...attributesCart} /></div>

   </div>
    
8. 8.

   Save the file and close it – the changes are complete.

    
9. 9.

   Switch to your browser – if you don’t already have it running, browse to http://localhost:5000. If all is well, we should see something akin to the screenshot in Figure 4-6.

    

Perfect use for a conditional check feature – something HTML should have had a long time ago! Admittedly, our demo only touches on the UI and assumes our customer has logged in, but that doesn’t matter – it’s the principle of using an if-else statement block in HTML markup which counts for this demo.

This demo shows off some valuable points around using the if-else block in Svelte, so let’s pause for a moment to review the code added from the last demo.

Understanding the Changes

This change was an interesting exercise – although the main focus was to add in the condition check, we also used Svelte’s context feature. We could have achieved this using props, but that can get messy – instead, using context makes for cleaner code. Let’s take a moment to review what we’ve added to see how it operates in more detail.

We kicked off by adding a reference to the setContext function from Svelte in App.svelte – this is key to making this demo work: it acts as a store for holding information for child components (not to be confused with Svelte’s store function, of course!)

We then set two variables – one called loggedIn to track if a customer has logged in and one as loggedInText to store a placeholder for the welcome greeting. Next up, we added in an if-else condition to determine if the name property was empty; based on this, we could determine if the user had logged in. The last change we made added a command to use setContext to set a property of key, with the value from loggedIn.

We then switched to editing Header.svelte; in this component, we imported the getContext command and retrieved the value of key using this command. We then updated the markup displayed on-screen to determine #if loggedIn was true; if so, we showed the Logout message, otherwise displayed the Login equivalent label.

Okay, let’s move on. For the second demo, we will revisit a subject from earlier in the book: loading data. Yes, I can hear the questions – what does this have to do with using a condition check, I wonder? There is a good reason for it; I will go through it and more in the explanation that will follow, but let’s first look at the demo itself.

Loading Products

For the second of two demos, we’re going to take a different tack – instead of adding a complete function, we’re going to create a partial effect only!

Yes, it won’t be an entirely complete one: don’t worry, though, as it will still work. We’re going to revisit using the await and fetch functions from earlier to help refactor importing data and better control the loading process. There is a twist, though, as this demo will open up options for us. To learn more, let’s first look at the code as part of our next exercise.

Loading Products

To add in better loading facilities, follow these steps:

1. 1.

   First, we need to install a plugin – for this, crack open a Node.js terminal session, and then change the working folder to our project area.

    
2. 2.

   At the prompt, enter this command and press Enter:

   npm install "@rollup/plugin-json" --save
    
3. 3.

   Once done, minimize the session, and then switch to stores.js from within the \src folder.

    
4. 4.

   Go ahead and comment out the entire let products=... block – all 70-odd lines!

    
5. 5.

   Immediately below import { readable, writable, derived } from "svelte/store";, add in this code:

   import * as myjson from '../public/stock.json';
    
6. 6.

   Miss a line, and then add in this declaration:

   let products = readable(myjson.default);
    
7. 7.

   Go ahead and save the file – we can close it at this point.

    
8. 8.
   Next, switch to Products.svelte, and add in the highlighted code as indicated:

     {#await $products}

       <p>...loading products</p>

     {:then}

       {#each $products as product}

         <div>

           <div class="image" style="background-image: url({product.image})"></div>

           <h4><a href="product/{product.id}">{product.name}</a></h4>

   ...

         </div>

       {/each}

     {/await}
    
9. 9.

   Save the file and close it – the changes are complete.

    
10. 10.

    Fire up your browser, and browse to http://localhost:5000, and then click Products in the menu – if all is well, we should see our products appear as before, but this time sourcing it from the JSON file, not inline. We can see the effect in Figure 4-7, where I’ve already gone ahead and added in some basic styling (and which we will cover later in this book).

     

All looks good, right? When you ran the demo, did you see anything happen, or not, as the case may be?

Exploring the Code in Detail

Okay, that last question might have been a little leading, but with good reason – I’m not sure that the “..loading products” text appeared! Before I explain what I mean by that statement, let’s first cover the changes made in the last demo.

Cast your mind back to Chapter 3, where we explored iterating through data in Svelte using stores – it’s a helpful technique but does have one inherent flaw.

We’re only running a small site, so hard-coding data is something we can live with – what if we wanted to run something more significant or source our data from a third-party offering, such as a database? This change would be infinitely more preferable – for one, it means not having to edit code all of the time!

To illustrate this principle in our site, we first installed the @rollup/plugin-json plugin to consume the JSON file – we could have done this manually, but there is little reward for what would effectively be reinventing the wheel. We then moved onto editing the stores.js file – inside this, we added an import reference to the stock.json file before calling Svelte’s readable function to consume the contents and assign it to a variable products.

For the last step, we wrapped the existing #each block in an await statement that checked for the presence of products. If this were false (i.e., it did not exist), we would display a "...loading products" placeholder message. The moment it became true, this would be switched out for the product data and iterated through it for display on-screen for the user.

Okay, let’s move on. Now that we’ve explored the code in more detail, it’s time to answer that question from earlier: Did we really see that “…loading products” message?

An Epilogue – Improving the Placeholder Message

When it comes to displaying data, a good tenet of UI practice shows a placeholder for the customer when loading data – it tells them something is happening, rather than seeing a blank screen. This effect is what we’ve tried to achieve here, but as we’re using localhost, the likelihood is that we may well not see the one thing we’re trying to display on-screen!

As part of researching this book, I tried an alternative way to source the data, which made the “loading product…” message a little more visible. Below let products = readable(myjson.default)... I added this:

console.log("test1", myjson.default)

const fetchData = (async () => {

  await fetch('../stock.json')

    .then(function(response) {

      return response.json();

    })

    .then(function(data) {

      const items = data;

      console.log("test2", data);

    })

});

let a = fetchData();

let products2 = readable([]);

products2 = readable(a);

console.log(products2.data);

When running the code in my browser, I got the response shown in Figure 4-8, which shows we can get identical information using either format. However, trying to get it into a Svelte readable store was something else – I got very close, but as we say in England, “close but no cigar!”

The issue here was extracting data in a format that the Svelte store could understand. This last bit is critical, as Svelte stores only accept values that we can iterate through as an array. Getting the data out from a promise wasn’t too tricky, but altering it into something that didn’t show the message in Figure 4-9 proved to be an entirely different matter!

Still, it was a useful exercise – it’s something we should bear in mind when using promises and no less so than with Svelte.

Summary

The ability to control what happens on a website has been around for years in some form or another – indeed, it even dates back to the days of the old BBC Micro or ZX Spectrum computers, if not even farther! Does anyone remember those? Now, there’s a blast from the past.

But I digress – back to more practical matters. This chapter has all been about implementing logic to control what happens in Svelte – we started looking at creating the Svelte equivalent of the classic if-else condition, known throughout most programming or scripting languages today. We learned that the syntax is very similar to vanilla JavaScript, but with the bonus of being part of HTML markup and not just within a script block.

We then worked our way through several different types of controlling logic: #each, keyed each statements, and how to use Svelte’s fetch/await keywords to control the flow of data into a project.

Next up came the exciting part – this focused on updating the shop, with two demos. The first explored how we could fake a logged in user with the appropriate message, using the equivalent of an if-then-else statement. The second was more of a proof of concept on improving the control overloading data into our site. We then rounded out the chapter with a brief look at why the last demo might not all seem as it should and explored the importance of getting the correct data into a readable store which can sometimes be tricky in Svelte.

Phew, we’ve worked our way through quite a bit there! This is what makes Svelte so easy to learn: it makes coding features a cinch – the markup is significantly lighter and easier to understand and allows us to create content without half of the associated baggage seen in other, larger frameworks!

We’ve made significant progress, but there are still two areas we should explore – what happens if we click on elements or interact with forms in Svelte? Both need handling – stay with me as we take a look at the first, events, in the next chapter.

The Theory of Reactivity

Think back to Chapter 1, where we talked about what makes Svelte different – I want to try a little test.

You might be asking why we’ve done this little test – let me explain.

In a nutshell, it boils down to something I like to call the theory of reactivity. We talked about how Svelte likes to be the odd one out, or the kid that likes to be different – doing away with a virtual DOM, unlike its bigger and perhaps more experienced cousins!

Instead, Svelte wraps our scripts with extra code to tell it when the DOM needs to be updated. This reactivity means that the DOM updates only when is necessary, but at the same time, we don’t need to run a virtual DOM to perform this operation. Thankfully, we don’t need to see all of that code – Svelte allows us to focus on what is necessary and abstracts away the remaining code as part of the build process.

Okay, we should crack on. Now that we’ve had a quick refresher on reactivity in Svelte, let’s take a look at the different types of events that we can create in Svelte in more detail.

Choosing from Different Event Types

Okay, so when it comes to working events, what can we achieve in Svelte?

I’m sure you are familiar with standard events such as onClick() , albeit under a different syntax; if you look closely at some of the code we’ve already written for the demo website, you will see at least one example in use. We’ve created a separate function as the event handler, but we could equally have written it inline.

Right, with this in mind, let’s turn our attention to putting some of this theory into practice; it’s time to get coding!

Creating Events

Now that we’ve seen some of the different types of events available in Svelte, it’s time to see some in action.

For those of you used to frameworks such as React or Vue, you will see some similarities – indeed, if you use vanilla JavaScript, you will equally recognize the same principles in use! To see what I mean, let’s dive into the first exercise for this chapter, with a quick look at how to create standard events in Svelte.

Exploring Event Handlers

To see how event handlers operate in Svelte, follow these steps:

1. 1.

   First, fire up your browser and head over to www.svelte.dev/repl – don’t forget the by-now-familiar redirection!

    
2. 2.
   Next, go ahead and add this code into the top of the App.svelte tab on the left:

   <script>

     function handleClick(event) {

       window.alert('Message from the click handler');

     }

   </script>

   <button on:click="{handleClick}">Click me</button>
    
3. 3.

   After a few moments, you should see a button appear – if you click it, you will see the message displayed in Figure 5-1.

    

1. 4.
   Try changing the code to this in App.svelte:

   <button on:click="{e => window.alert('message from the click handler')}">Click me</button>

   This in-lines the event handler, but clicking it will produce the same result.

    

That was a simple exercise that highlighted an important point: Which one do we use? Is one better than the other? I know some of you will have likely seen recommendations to steer away from using inline event handlers, owing to performance concerns, particularly when it comes to iterating through loops.

This recommendation might be valid for other frameworks, but not for Svelte – it doesn’t matter which format you use! I can already hear the comments to the effect that this surely can’t be true – it is indeed true: you can use either format as you wish. To understand why, let’s first take a quick look at the code before understanding more about what happens under the covers with Svelte.

It’s worth noting that although we’ve focused on using on:click, the same principles apply to other standard event handlers such as on:mouseover. We will touch on how to create custom Svelte events later in this chapter.

Modifying Event Handlers

In the previous exercise, we explored how to add event handlers using Svelte – it was easy to see from the demo that the syntax bears a remarkable similarity to standard JS.

A bonus is that these modifiers can be chained together – for example, we can do this: on:click|once|capture={...}.

It’s all well and good talking about it, but the best way to understand how these modifiers work is to see them in action! We will do this in the next exercise, using two chosen at random from Table 5-1.

Adding Event Modifiers

Assigning an event modifier requires only a small change. To see how, work these steps:

1. 1.

   First, browse to www.svelte.dev/repl – don’t forget the redirection that takes place!

    
2. 2.
   For our first example, we will use preventDefault – go ahead and add this code into the App.svelte panel on the left:

   <script>

     function handleSubmit() {

       console.log("success");

     }

   </script>

   <form on:submit|preventDefault={handleSubmit}>

     <input type="text" placeholder="Name" />

     <button>submit</button>

   </form>
    
3. 3.

   After a few moments, you will see a form appear on the right – click the submit button to see the response shown in Figure 5-2.

    

1. 4.

   Go ahead and remove the |preventDefault text from the code, and then hit the Submit button once the screen has refreshed. You will see the same message appear, but if you click the OK button, the pane behind it will blank out.

   The second example we will look at is stopPropagation – as with standard JavaScript, this will have more of a pronounced effect.

    
2. 5.

   Go ahead and save a copy of the code if you have set up an account with the REPL tool, or bring up a new REPL window.

    
3. 6.
   As before, add this code into the App.svelte tab on the left:

   <style>

     div {

       padding: 1rem;

       border: 1px solid;

     }

     div:nth-child(1) { background-color: gainsboro; }

     div:nth-child(2) {

       background-color: grey;

       color: white;

       border: 1px solid black;

     }

   </style>

   Note I’ve added some color to each div, to make it easier to see <div on:click={() => console.log('Outer div')}>.

    

   <h1>Outer div</h1>

   <div on:click|stopPropagation={() => console.log

('inner div')}>

    <h1>Inner div</h1>

  </div>

</div>

1. 7.

   Go ahead and click the Outer and then Inner div tags – in the console log, you should see the name of the clicked div appear, as indicated in Figure 5-3.

    

1. 8.

   Try removing |stopPropagation from within the code and clicking the div tags as before – you will get a completely different result!

    

Adding an event modifier is an effortless change which can have a dramatic effect on the overall behavior of our code. Let’s take a moment to quickly explore the code we’ve created in more detail before moving on to looking at the next type of events in Svelte.

Creating Events in Components

It’s a good question: we could create events within components – if we triggered them, they would work fine. However, the parent (such as App.svelte) won’t listen to them and consequently won’t react. A good example could be to click an add-to-basket button; with an ordinary event, features such as mini basket counts may not respond (and therefore could become out of sync with the main basket).

To get around this, Svelte has the createEventDispatcher feature – this allows the parent to listen for any instance where a child component triggers an event and responds accordingly. Hold that thought, though – there is a twist on this tale: What if we had to trigger an event held several levels deep rather than just one?

Forwarding Events

Well, we could use createEventDispatcher, but this is likely to generate a lot of extra code. Instead, Svelte provides a shortcut called on:message. This shortcut allows us to forward events down from the parent through intermediaries to the target component, but the net effect means less code to write!

It does raise an interesting question, though, as to whether this is better than simply passing events as part of a call to a native function, but for now, let’s take a look at an example of how we can use both on:message and createEventDispatcher to trigger events from nested components.

Forwarding Events

To see how we can mix both createEventDispatcher and on:message, follow these steps:

1. 1.

   First, browse to www.svelte.dev/repl – as before, don’t forget the URL redirection that will kick in!

    
2. 2.
   Next, in the App.svelte tab on the left, add this code:

   <script>

     import Outer from './Outer.svelte';

     function handleMessage(event) {

       alert(event.detail.text);

     }

   </script>

   <Outer on:message={handleMessage}/>
    
3. 3.

   We need to add another component, so click the plus sign to the right of the App.svelte tab, and rename it to Outer.svelte.

    
4. 4.
   Go ahead and add in this code:

   <script>

     import Inner from './Inner.svelte';

   </script>

   <Inner on:message/>
    
5. 5.

   There is one more component to add – Inner.svelte. Click the plus sign as before, but this time, rename the component to Inner.svelte.

    
6. 6.
   Go ahead and add in this code:

   <script>

     import { createEventDispatcher } from 'svelte';

     const dispatch = createEventDispatcher();

     function sayHello() {

       dispatch('message', {

         text: 'Hi, Alex!',

       });

     }

   </script>

   <button on:click={sayHello}>

     Click to say hello

   </button>

   You will note I’ve used my name in the greeting, but feel free to substitute yours if you like!

    

1. 7.

   After a few moments, we should see this button appear – if we click it, we get a suitable response from the inner component created in the demo (Figure 5-4).

    

This exercise shows how we can track and trigger events in a nested component from pretty much anywhere in our application. The only proviso is that we must maintain the forwarding chain (i.e., pass the event from component to component). Otherwise, a break means the event will not be triggered correctly.

To understand how it works, let’s pause for a moment to review the code we’ve created in this demo in more detail.

Life Cycling Events in Svelte

Over time, there will be critical moments where we might need to perform an action, during the life of a component. This life cycle starts when we create or mount the component and finishes once we have no further need for that component and it is destroyed.

A perfect example of performing this action might be to fetch data when a component is mounted; we might also want to load a library used to perform a function essential to the component’s operation.

The theory of each type of life cycle event is all good, but nothing beats a little hands-on practice, right? With that in mind, let’s play with a couple of these event handlers to see how they work in Svelte.

Working with onMount

If you’ve spent any time developing with the likes of React and Vue, then you may well be familiar with the first of our examples – onMount . This event works in much the same way as React; we can use it to intercept when a component is mounted and ask Svelte to execute an action during this process.

The Svelte tutorial has a great example of how this works – we can use it to fetch data from a mock placeholder service, ready to render slots on-screen, for, say, a gallery. I’ve used it as the basis for our next exercise, with some minor tweaks – let’s look at how it works in action.

Life Cycle Methods Part 1: Onmount

To understand how onMount works in Svelte, follow these steps:

1. 1.

   As from previous exercises, we will start by browsing to https://svelte.dev/repl to use the Svelte REPL tool – don’t forget the redirect that will kick in!

    
2. 2.
   In the App.svelte tab, go ahead and add this script block:

   <script>

       import { onMount } from 'svelte';

       let photos = [];

       onMount(async () => {

           const res = await fetch(`https://jsonplaceholder.typicode.com/photos?_limit=4`);

           photos = await res.json();

       });

   </script>
    
3. 3.
   Next, we need to add some rudimentary styling, so the demo at least looks presentable – for this, skip a line, and then add in this code:

   <style>

       .photos { width: 100%; display: grid; grid-template-columns: repeat(2, 1fr); grid-gap: 8px; }

       figure, img { width: 100%; margin: 0; }

   </style>
    
4. 4.
   Our demo will be meaningless without some form of markup to display – for that, we need to add in this code, first leaving a line blank after the styling block:

   <h1>Photo album</h1>

   <div class="photos">

     {#each photos as photo}

       <figure>

         <img src={photo.thumbnailUrl} alt={photo.title}>

         <figcaption>{photo.title}</figcaption>

       </figure>

     {:else}

       <!-- renders when photos.length === 0 -->

       <p>loading the album...</p>

     {/each}

   </div>
    
5. 5.

   Excellent, our code is now in place: after a few moments, we should see something akin to the screenshot shown in Figure 5-5.

    

This example is a great way to show how we can use onMount to fetch data for a component – it does require us to use the await block to get the desired effect. Still, we can at least delay the loading of data or media until we are ready to render the component.

Exploring beforeUpdate

Let’s take a look at the second of our two demos now – this time, we will explore using beforeUpdate to throw a message before we execute an action in our component.

Life Cycle Methods Part 2: Beforeupdate

To see how we can refine the code, follow these steps:

1. 1.

   First, browse to https://svelte.dev/repl – note the now-familiar redirect that will kick in!

    
2. 2.
   Next, in the App.svelte tab, add this code:

   <script>

     import { beforeUpdate} from "svelte";

     let count = 1;

     beforeUpdate(function() {

       alert("You can see me before count value is updated");

     });

   </script>
    
3. 3.
   We now need to add in markup, so we can use the function we’ve just created – go ahead and miss a line, and then add in this:

   <div>

     <h1>{count}</h1>

     <button on:click={() => count++}>Increment</button>

   </div>
    
4. 4.

   After a few seconds, you will see a button appear – try clicking it: each time, a message will appear before the count is updated, similar to that shown in Figure 5-6.

    

Most of the code in the last two demos should be reasonably self-explanatory, but there are a couple of important points we should explore further, so let’s pause for a moment to consider the code in greater detail.

Implementing Actions

Imagine for a moment that we needed to call onMount in a Svelte project – let’s say for arguments’ sake this was all within the App.svelte file. Chances are we would need to import the onMount function, write our custom function, and then call that custom function from within onMount.

Sounds sensible, right? It serves our needs fine – we have the custom function in place, it’s called when we need it, and we can destroy it at the appropriate time. What if I said that that was potentially a terrible way to write code and that we can do so much better?

I hear you say, “What do you mean we can do better?”

There are two issues here: when using onMount on an element, we could end up with an instance of onMount returning an undefined element, as Svelte hasn’t yet initialized it. The second is that onMount code isn’t reusable; we could shift it to App.svelte from a component, but we still need extra code to call it in each component where it is required. So, what is the solution? Let me introduce Actions – put simply, we can abstract code into reusable actions (think of them as components in a sense) and call the action on an element when needed in code. Perfect!

To see what I mean, let’s dive into a before and after demo to see how it helps keep code clean and concise.

Creating Custom Actions: Part 1

Let’s take a look at how we can improve the code from the previous demo:

1. 1.

   In a new window, browse to https://svelte.dev – the URL will redirect to indicate the version of Svelte in use.

    
2. 2.
   In the App.svelte window, add this code:

   <script>

     import { onMount } from "svelte";

     let node;

     function tellMeAboutTheNode(node) {

       console.log("Information: ", node.tagName);

     }

     onMount(() => {

       tellMeAboutTheNode(node);

     });

   </script>

   <h1 bind:this={node}>Hello onMount!</h1>
    
3. 3.

   Go ahead and fire up your browser’s console log, and then refresh the screen – if all is good, then you should see this message appear, as indicated in Figure 5-7.

    

That was probably one of the shortest exercises I’ve ever written, and I’ve created more than a few in my books over the years! The key here is the number of lines of code we’ve used – ten in total, excluding the script tags but including blank lines. We can certainly improve on it. To see how, let’s move onto the next exercise.

Reworking the Code

We’ve mentioned that Svelte Actions are the perfect tool to help refine this function – not only do they work in the same way as (in this case) onMount(), we can turn them into reusable modules that we can import as if they were just another component!

I’m sure you will agree this makes this type of function infinitely more appealing – to see just how one might look, let’s dive into our next exercise where we will refine the code from part 1 to produce something reusable in our projects.

Creating Custom Actions: Part 2

To see how we can improve the original code, follow these steps:

1. 1.

   First, fire up a new session of the REPL playground, at www.svelte.dev/repl – this will give you a before and after effect.

    
2. 2.
   In the App.svelte tab of this new instance, go ahead and paste in this script block:

   <script>

     function tellMeAboutTheNode(node) {

       console.log("Information: ", node.tagName);

     }

   </script>
    
3. 3.

   Leave a line blank after the closing </script> tag, and then add this:

    

<h1 use:tellMeAboutTheNode>Hello Action!</h1>

1. 4.

   After a moment or two, we should see the results shown in Figure 5-8 – you will need to resize the Console section at the bottom of the Result window to see the full effect.

    

I am sure you will agree that the changes we’ve made already make the code more concise and easier to read!

That keyword use may look innocuous, but it hides a lot of potential: there are all manners of different applications we could use this feature for, which will help when writing our code. Let’s take a moment to pause and explore the code in more detail.

Adding Functionality to Our Site

Throughout this book, we’ve focused on creating a simple ecommerce site using Svelte. It’s a great way to show off some of this fantastic framework’s valuable techniques and features. At this point, I would typically say, “let’s add a new feature,” but – as it so happens – we’ve already done it in more than one place!

The reality is that the syntax is very similar to React or vanilla JavaScript, which makes it easy to understand how they operate in Svelte.

Let’s continue with this theme, though, and add in a few more examples – we will add to the tally for on:click, but at the same time, including examples for createEventDispatcher, the onDestroy() life cycle event, and on:keydown handler. Let’s crack on with the final exercise for this chapter and set up a modal display for our site.

Adding a Modal

Ah, yes, you might well ask why, but it’s with good reason: how many times have you visited a site, only to be bombarded with offers of discounts, or cookie consent forms, for example? I’ve personally lost count – sometimes you might come across a site which uses them sensibly and others… not so much. That criticism aside, models are an essential part of a developer’s toolkit – we could spend time creating one from scratch, but why reinvent the wheel? There are several components out there for Svelte that will do just fine, including one created using code from the main Svelte website! We use this latter component for our next exercise, so let’s dive in and make a start.

The plugin in question is available from the central NPM registry at www.npmjs.com/package/modal-overlay.

Demo – Adding a Modal Overlay

Adding a modal is easy to add in for a Svelte site and uses several features we’ve touched on in this chapter – to see how to, follow these steps:

1. 1.

   First, fire up a Node.js terminal session, and then change the working folder to our project area.

    
2. 2.

   At the prompt, enter this command and press Enter:

   install npm i modal-overlay
    
3. 3.

   Next, go ahead and open Home.svelte in your text editor, and then find this line:

   {#if display}
    
4. 4.
   Immediately below it, add this block of code:

     <Modal on:close={close}>

       <h1>Get 10% off your first order!</h1>

       <p>

         <span>Use code 10PERCENT at checkout</span>

         <img src="images/3.png" alt="image3" />

       </p>

       <button on:click={close}>X</button>

     </Modal>

   {/if}
    
5. 5.

   Save the file and close it.

    
6. 6.
   Next, go ahead and open global.css – scroll to the bottom, and then add in this styling:

   .modal-background { background-color: rgba(0, 0, 0, .7) !important; }
    
7. 7.

   Save and close the file – the changes (for now) are complete.

    
8. 8.

   Revert to the Node.js terminal window, and then make sure you have set the working folder as the project folder. At the prompt, enter npm run dev and press Enter.

    
9. 9.

   Give it a few moments, and then when prompted, browse to http://localhost:5000 in your browser – if all is well, we should see something akin to Figure 5-9.

    

Setting up a modal is a cinch technically, but using them does raise a few UX (user experience) questions, potentially becoming issues if we are not careful in how we use them. We should consider these questions further – before we do so, let’s quickly run through the steps we took to create our demo in more detail.

Summary

Phew, that was one eventful chapter, and yes, the pun was intended!

Managing events is a vital part of any website – it doesn’t matter which framework we use: we need to respond to any interaction from our users. Svelte is no different: the syntax might look slightly different, but the basic principles will be the same. Over this chapter, we’ve worked through various examples before adding new functionality to our site; let’s take a moment to review what we have covered in this chapter.

We kicked off by first reminding ourselves of the theory of reactivity, core to how Svelte works; we then explored some of the different types of events we can use in Svelte.

The first event type we covered was standard events before adding in event modifiers. We then covered the principles of forwarding events into child components before moving on, looking at life cycling events and implementing Actions in Svelte.

We then rounded out the chapter by adding a modal display to our demo site – we saw how easy it was using a plugin, but this wasn’t without drawbacks. We then covered some of these drawbacks to understand what changes we might need to fit our requirements better.

Okay, we’ve come to the end of our tour of events in Svelte and the changes we’ve made to our site, but there is still more to come! It’s time now to get all stylish and smarten up our site (yes, pun very definitely intended there!). Adding styles is very simple for Svelte, but there are several ways to do it – to learn more and see how smart our site will be once we update it. Stay with me, and I will reveal it all in the next chapter.

Creating Forms in Svelte

Okay, I confess: that last statement isn’t always true – data is usually top down, but this is only a general rule. And rules can be broken. The difference is knowing when to break them and why. Let me explain, using a text input as my example.

It’s a simple example, but using bind here means that if we change the value against the name function in the <input> element, it will reflect both in the text within the <h1> tags and the variable declared in the script block. Likewise, if we change the value of name, this will filter down to both the input value and the text within the <h1> tags.

This two-way communication is one thing I love about Svelte – using bind: makes our code more straightforward and easier to read. Svelte automatically handles the two-way binding process, leaving us to focus on manipulating the results as suited for our needs. The same principle applies across all form elements – let us look at a few examples before using them later in this chapter.

Catering for Different Form Elements

We’ve seen how using the bind function makes for cleaner code when setting up two-way interaction with form elements in Svelte – but what about the other elements?

Text area inputs are not the only element Svelte can manage – let’s take a look at some of the others, starting with numeric inputs.

Building a Composite Example

For this demo, we’re going to build a simple coffee selector to choose the different options we might want when ordering coffee.

We’ll keep it simple by focusing on the form elements and not styling; the key here will be to watch how the final statement reacts when we change any of the form options in this demo. With that in mind, let’s dive in and take a look at constructing our demo.

Building a Coffee Selector

To see how easy it is to create and manage form elements in Svelte, follow these steps:

1. 1.

   First, go ahead and browse to https://svelte.dev/repl – don’t forget the usual URL redirect that will kick in!

    
2. 2.
   Next, in the App.svelte tab on the left, add in this script block:

   <script>

     let cnt = 1;

     let name = 'Guest';

     let grain = 'Coarse';

     let size = ['50g'];

     let coffeeType = [

       'Coarse',

       'Fine',

       'Wholebean'

     ];

     let sizes = [

       '50g',

       '75g',

       '100g'

     ];

   </script>
    
3. 3.
   We have a fair chunk of markup to add in, so we will do it in sections. Leave a line blank, and then add in this code:

   <p>

     Please enter your name: <input bind:value={name}>

   </p>

   <h1>Hi {name}!</h1>

   <p>

     This is what we have available in stock right now:

   </p>
    
4. 4.
   Next, leave a link blank, and add in this code – it will display a group of radio buttons:

   <h2>

     Grain

   </h2>

   <label>

     <input type=radio bind:group={grain} value={'Coarse'}>

     Coarse

   </label>

   <label>

     <input type=radio bind:group={grain} value={'Fine'}>

     Fine

   </label>

   <label>

     <input type=radio bind:group={grain} value={'Whole Bean'}>

     Whole Bean

   </label>
    
5. 5.
   Leave a line blank, and then add in this code – this will render a group of checkboxes on-screen:

   <h2>

     Weight

   </h2>

   {#each sizes as bagSize}

     <label>

       <input type=checkbox bind:group={size} value={bagSize}>

       {bagSize}

     </label>

   {/each}
    
6. 6.
   Lastly for this portion, go ahead and add in this code too:

   <p>

     Number of bags required:

   </p>

   <label>

     <input type=number bind:value={cnt} min=1 max=10>

   </label>

   You've chosen {cnt} x {size} {cnt === 1? "bag": "bags"} of {grain} coffee
    
7. 7.

   After a few moments, we should see something akin to the screenshot shown in Figure 6-1, shown overleaf.

    
8. 8.

   Try changing the selected options or entering a different value into either of the input fields – Svelte will change either the “Hi Guest!” or “You’ve chosen…” statements accordingly.

    

It’s a simple demo, but it highlights just how we can begin to use form elements in Svelte. We’ve not included <form> tags – or any styling for that matter – but that doesn’t matter: it’s the principle that counts! We will come back to using form elements later in this chapter when we start to add features to our front-end demo, but for now, let’s pause for a moment to review the changes made in this demo in more detail.

Managing Context

The obvious answer is that it would sound awful!

But that illustrates a perfect example of how Svelte can help with binding elements – maintaining context. Unless we happen to be a budding DJ, we would only want one tune to play at any one time, right? This is where Svelte comes in – we can declare a <script context="module"> block in our code; this allows each media element to talk to each other, without the need for us to manage state manually.

I suspect you probably think that this isn’t possible – for those of you who work with tools such as React, you would expect to have to initiate some form of state management and update it when triggering a new media element. You’d be right if we were talking about the likes of React. Not so with Svelte. To see what I mean, let’s first dive into a demo to see how this all works in practice.

Demo – “One at a Time…”

To see Svelte manage context when binding multiple elements, follow these steps:

1. 1.

   First, go ahead and browse to https://svelte.dev/repl – don’t forget the by-now-familiar redirection!

    
2. 2.

   Next, open a copy of audio player code.txt from the code download that accompanies this book, and copy the contents into the App.svelte tab.

    
3. 3.
   Click the plus sign next to that tab heading, and rename the new tab to Audioplayer.svelte. Go ahead and add in this script block:

   <script context="module">

     let current;

   </script>

   Don’t be tempted to merge the code from step 3 into any existing <script> block. Script modules of this type have to be separate, or this will throw errors.

    

1. 4.
   Leave a line blank, then add in the following code – this defines several variables and a stopOthers() function for our player:

   <script>

     export let src;

     export let title;

     export let composer;

     export let performer;

     let audio;

     let paused = true;

     function stopOthers() {

       if (current && current !== audio) current.pause();

       current = audio;

     }

   </script>
    
2. 5.
   It’s the turn of the markup to be added – leave a line blank, and then add in this code:

   <article class:playing={!paused}>

     <h2>{title}</h2>

     <p><strong>{composer}</strong> - performed by {performer}</p>

     <audio bind:this={audio} bind:paused on:play={stopOthers} controls {src}>

       <track kind="captions">

     </audio>

   </article>
    
3. 6.
   Last but by no means least, we should add in some styling, so our demo at least looks presentable:

   <style>

     article { margin: 0 0 1rem 0; max-width: 800px;

   padding: 5px; }

     h2, p { margin: 0 0 0.3rem 0; }

     audio { width: 50%; margin: 0.5rem 0 1rem 0; }

     .playing { color: #000; background-color: silver }

   </style>

   You can see my version as a Svelte REPL, at  https://svelte.dev/repl/a1874f8f986b4c719115f3f0035504d0?version=3.38.1 – the demo in this chapter is adapted from the original on the Svelte site, at https://svelte.dev/tutorial/sharing-code.

    

1. 7.

   If all is well, we should see the music players appear, as indicated in Figure 6-2, shown overleaf.

    
2. 8.

   Try switching between players – no matter how much you try, you will only see one player operate at a time! As soon as you click the next one, the original will stop, and the new selection kicks in to play.

    

I must admit that classical music isn’t my typical music of choice, but it’s nice to try different things from time to time!

Leaving tastes in music aside, this demo shows off perfectly how we can have multiple media elements on the page yet control which one plays when we want to and don’t end up with a cacophony of different sounds. You’re probably asking, “How are we managing state in this demo, and where does this fit in with element binding?”

Adding a Contact Form to Our Demo

I’ve lost count of the number of websites I’ve visited over the years – I can still remember the heady days of 1997 when the Internet became mainstream! There have been some dramatic changes over the years, but most websites have one thing in common: a means to contact a company.

This feature might be anything from a simple email link to a full-blown contact form – whether the company concerned responds and how long it takes is another matter! The important thing is that we should provide some form of contact feature on any site we build: for our next project, we will do just that, using Svelte and the Yup library.

Building the Contact Form

Now that we’re rested, let’s continue with the second part of this demo – here, we’re going to build the contact form and test it:

Building the Form

To add the form, follow these steps:

1. 1.

   Next, go ahead and open a new file, saving it as Contact.svelte in the \src\pages folder.

    
2. 2.
   At the top of the file, add in this script block – there is a good chunk of code to add, so we will do it in sections, beginning with the opening tag and import statements:

   <script>

     import * as yup from 'yup';

     import {Form, Message, isInvalid} from 'svelte-yup';
    
3. 3.
   Next comes a function to flag if any fields are not validated:

   $: invalid = (name)=>{

     if(submitted){

       return isInvalid(schema, name, fields);

     }

     return false;

   }
    
4. 4.
   We need to determine which fields should be validated and how – for this, add in this declaration:

     let schema = yup.object().shape({

       name: yup.string().required().max(30)

   .label("Name"),

       email: yup.string().required().email()

   .label("Email address"),

     });
    
5. 5.
   We have three additional declarations to add in too:

   let fields = {

     email: "",

     name: "",

     yourmessage: ""

   };

   let submitted = false;

   let isValid;
    
6. 6.
   Last but by no means least, we need to add in a function to take care of submitting the responses:

     function formSubmit(){

       submitted = true;

       isValid = schema.isValidSync(fields);

       if(isValid){

         alert('Everything is validated!');

         console.log("Validated fields", fields);

       }

     }

   </script>
    
7. 7.
   Next, leave a line blank, and then add in this markup block, which we will do in sections:

   <section>

     <h2>Contact Us</h2>

     <!-- image from https://www.pexels.com/photo/beans-beverage-black-coffee-breakfast-373888/ -->

     <div id="banner">

       <img src="images/banner.jpg" alt="banner" />

     </div>

     <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas sed odio id nulla gravida rhoncus. Suspendisse potenti. In volutpat nibh non tellus laoreet, vitae faucibus ipsum sollicitudin. Duis viverra pulvinar tempus. Phasellus odio nunc, imperdiet vitae diam quis, sollicitudin pretium massa. Donec molestie mauris id semper sagittis.</p>
    
8. 8.
   The next block of code takes care of rendering our contact form – we have the opening tags, followed by the name field:

     <Form class="form" {schema} {fields} submitHandler={formSubmit} {submitted}>

       <label for="customer"><span class="required">*<span>Name:</span></label>

       <span class="formformat">

         <input type="text" class:invalid={invalid("name")} bind:value={fields.name}

   placeholder="Name">

         <Message name="name" />

       </span>
    
9. 9.
   Next comes the email address and message fields:

   <label for="emailaddress">

     <span class="required">*<span>Email address:</span>

   </label>

   <span class="formformat">

     <input name="emailaddress" type="text" class:invalid={invalid("email")} bind:value

   ={fields.email} placeholder="Email address">

     <Message name="email" />

   </span>

   <label for="yourmessage">Your message:</label>

   <textarea name="yourmessage" cols="50" rows="10" bind:value={fields.yourmessage} placeholder="Enter your message"></textarea>
    
10. 10.
    Finally, we can add in a submit button and closing tags:

        <span class="submitbutton">

          <button type="submit">Submit</button>

        </span>

      </Form>

    </section>
     
11. 11.

    Go ahead and save all of the files, and then close them.

     
12. 12.

    Next, make sure you have started your Svelte development server, and browse to http://localhost:5000/contact – if all is well, we should see a page with the title, lead-in image, and text; we will see the all-important form further down the page (Figure 6-3), shown overleaf.

     

1. 13.

   Try hitting Submit now – if all is well, you’ll get a message saying there’s a problem, and Submit won’t let you go any further! If you do enter an email and name, you find all is well when hitting that Submit button.

    

This was a prolonged, two-part exercise, but worth it! We’ve covered some valuable techniques while building this demo, so let’s rest for a moment and review the changes in more detail.

Understanding the Code in Detail

So, what did we do? In part 1, we started by setting up the groundwork for our contact form – we installed the yup and svelte-yup plugins before updating the navigation in App.svelte by adding an additional <Route...> for the contact page.

In part 2, things were a little more involved; we started by creating the skeleton for the Contact.svelte page. We added in a script block to handle functionality; this first imported the two plugins. Next up came the function invalid to determine if we had correctly validated the submitted fields; if not, we flag them as such.

As part of this, we then created a schema to determine how to check and validate our targeted fields. For name, we set it to expect a value of type string(), made it compulsory (or required()), and set it to be no more than 30 characters long, with a field name (highly original, I know!). We did something similar for the email field; we set it as a string() field, which was of type email() and required().

Next up, we then set an object to determine the default values for name, email, and yourmessage fields – note we do not use these for validating! We then set a couple of variables used for determining state before creating a formSubmit() function to check our fields are correctly validated.

Last but by no means least, we then added in the markup – most of this is standard HTML, but it’s worth noting a couple of extras:

• We add the {schema} entry to tie each field back to the validation schema.

• The {submitted} value is there to determine if the field has been submitted – it uses the two-way communication we’ve already talked about.

• It uses the bind:value={fields.yourmessage} format to enable two-way communication, so we can use values as and when they are updated in the form.

Otherwise, the form is made up of standard HTML markup that you will find for each type of field we’ve used – hopefully, this shows that we don’t need to add too much extra code to our markup when creating forms using Svelte.

Note the presence of class:invalid={invalid("email")} – it looks odd, but this is purely to add a styling class. We will cover this more in the next chapter.

Summary

Forms, forms... who loves filling them out? I certainly don’t, and I’m sure many of you would agree!

Form filling is one essential part of any website – while they serve a purpose, the whole design can be a real hit-and-miss affair, with some companies getting it spot on and others leaving you feeling frustrated. Leaving the subject of frustrations aside, form creation is just one part of what Svelte has to offer when binding elements using this framework. We’ve covered several useful principles, so let’s take a moment to review what we have learned in this chapter.

We started with a look at the core principle of data being driven from top to bottom and how this doesn’t apply to forms; we understood that frequently we need two-way communication when it comes to binding form elements. We then reviewed examples of how to bind different types of form elements, such as numeric inputs or multiline text boxes, before covering some of the other ways we can bind elements using Svelte.

Next up, we then moved onto the subject of context – when binding to certain elements such as media, we explored how it was helpful to maintain a direct reference to the correct element using context. It means that if we have multiple elements, such as videos, we can target the right element.

We then turned our attention to adding a new feature to our front-end store – this took the format of a new contact us page, with the beginnings of form validation. We covered how validating form elements can be an absolute minefield. We mentioned that in most cases, it is often more effective to use an existing validation library rather than create one from scratch!

In this chapter, we’ve added all of the core features for our website. It’s time to make it look a little more stylish and presentable for our customers! At this point, things will get more interesting, as this opens up some real possibilities for us; it should be no surprise that I’m of course talking about adding styles. We have a lot to cover, so without further ado, let’s crack on and get our website looking presentable in the next chapter.

Making Some Small Adjustments

Ordinarily, I would say that making changes to markup as a result of styling a site is not necessarily best practice: it feels like we’re using styling to dictate how our content should appear when it should be the other way round.

That said, if we were to run the site now, we would see two errors appear:

• So far, we’ve used standard link tags – while there is nothing technically wrong in doing so, they do cause an issue with using stores. If, for example, we navigate from a product page back to the products listing, this can reset a Svelte store. It forces a complete full re-render of the page, which loses anything held in the Svelte store.

• If we click a link from the front page, we might see this error appear in the console log (Figure 7-1).

Don’t worry though, the fixes for both are easy – we need to replace the href tags with <Link to=""> tags and reconfigure the routing block in App.svelte to use a different tag. Let’s dive in and take a look at how in more detail.

Okay, now that we’ve fixed our code, let’s move on and take a look at how we can style elements in Svelte.

Understanding Styling in Svelte

One of the features where Svelte excels is in its approach to styling – unlike other frameworks, where you often have to style elements in-line or perhaps use CSS-in-JS, Svelte keeps things very simple. It uses the basic premise of why reinvent the wheel when you already have an excellent mechanism for styling content?

Sure, you can use libraries such as “Emotion,” but it’s not necessary – it just adds an overhead that will ultimately make your site slower! Often you will find code has been divided into individual components, rather than by file type – you might discover JavaScript in the main component, but with CSS written in-line or defined as constants in a separate JavaScript file. It works, but Svelte takes this one step further – we include everything in one file per component: this includes markup, CSS, and JavaScript.

Taking this approach has some real benefits – everything in a component file is scoped to that component only. There’s no need to bring in other files, and it makes for much cleaner, easier-to-understand code when reviewing later. We will come back to this concept in greater detail, but for now, let’s move on with adding the styling to our front-end demo.

Adding Styling to the Front-End Demo

I’ve compressed the styles for space reasons; the styles will be correctly formatted in the code download that accompanies this book.

With those housekeeping tasks completed, we can now add styles to our site, beginning with some that will apply across the entire site.

Styling the Pages

For this next exercise, we need to make changes to two of the four files in our demo – let’s take a look at the changes in more detail.

Styling – Part 2: Pages

To update the styling for the two pages concerned, follow these steps:

1. 1.

   The first change we will make is in Contact.svelte – we’re going to add in some additional markup that was missing from the original version. The code uses a standard HTML button element – go ahead and add in this reference at the start of the script block:

   import Button from '../components/Button.svelte'
    
2. 2.

   With this in place, we can now switch out the standard button element for a custom component. Scroll down to almost near the end, and then replace the instance of button with Button.

    
3. 3.

   Next, scroll back up to <div id="banner">, and then leave a blank line after its closing tag (two lines down). Add in <div id="content">. Scroll down to the end, and then just before the closing </section> tag, add a closing </div> tag.

    
4. 4.
   With the updated markup now in place, scroll back up to just before the opening <section> tag, and add in this block:

   <style>

     #content { display: flex; column-gap: 80px; }

     .form, label { display: flex; flex-direction: column; }

     label { padding-top: 10px; }

     input { width: 380px; margin-right: 10px; }

     textarea { width: 380px; }

     .formformat { display: flex; }

     .invalid { border-color: red !important; }

     .submitbutton { display: flex; }

   </style>
    
5. 5.
   The next change we need to make is in the Home.svelte file. Open the file in your text editor, and then scroll down to the closing </script> tag. Go ahead and leave a blank line, and then add in this block:

   <style>

     @font-face { font-family: 'black_jackregular';    src: url('/fonts/blackjack.woff') format('woff');   font-weight: normal; font-style: normal; }

     .welcome { font-family: 'black_jackregular', sans-serif; font-size: 30px; width: 50%; }

   </style>
    
6. 6.

   Make sure you save both files, then switch to your browser, and head over to http://localhost:5000. If all is well, we should see something akin to the extract shown in Figure 7-2 (taken from the Contact page).

    

1. 7.

   Browse to Home – once there, you will see similar styling that uses the same rules we’ve applied in global.css.

    

As in the previous exercise, nothing we added was unusual – everything was standard HTML markup or CSS styling.

Adding standard markup or styling is what is so appealing about Svelte. It keeps things very simple, allowing us to focus on what is essential and reduce code bloat to a minimum. As you will see, this is a recurrent theme throughout the styling code for this site; to prove it, let’s continue with the following demo, which is styling the header and footer for our site.

Use of class: in markup

Notice how we used class:invalid={invalid("email")} in our code? It might look a little odd, but this is purely to add a styling class. It’s effectively saying, “apply the class .invalid to this element, if the invalid("email") parameter is true, and not if it is false.”

Styling the Product Pages and Cart

We reach the most critical point in this chapter: adding styles to our product pages and shopping cart!

There is a fair bit of work to do, but we will also (in the spirit of continuous improvement) make a few changes to the markup at the same time. Okay, leaving that aside, let’s move on with making those changes, beginning with Product.svelte.

Styling – Part 3C: Products and Product Pages, Cart

We have a few changes to make to the product, products, and cart files, so let’s make a start:

1. 1.

   First, go ahead and open product.svelte in your file editor, and then wrap the entire HTML block with <section></section> tags.

    
2. 2.

   Next, add a couple of blank lines before that opening <section> tag, and then add the styling code from styling – product page.txt, in the code download accompanying this book.

   Although we have a Back to Shop element on the page, we’re not going to style it here. We already have styles in the global.css file that will be sufficient.

    

1. 3.
   Next, we need to add in a hack for the navigation – I will explain why later, but for now, go ahead and add this before the closing </script> tag:

   let getShopMenuItem = document.querySelector("nav > a:nth-child(2)");

   if (individualURL.indexOf("/product") != -1) {

     getShopMenuItem.style.borderBottom = "5px solid #552200";

   } else {

     getShopMenuItem.style.borderBottom = "none";

   }
    
2. 4.
   At the same time, we can also improve on the markup – I know this isn’t strictly related to styling, but in the spirit of continuous improvement, we shouldn’t let that stop us! Scroll up to the start of the <script> block, and then comment out the highlighted lines as indicated:

     const addToCart = (product) => {

     //    for (let item of $cart) {

       //     if(item.id === product.id) {

       product.quantity = 1

       $cart = $cart;

       //       return;

       //     }

       //  }

       $cart = [...$cart, product]

     }
    
3. 5.

   At this point, we’ve finished making changes in Product.svelte, so go ahead and save the file and close it.

    
4. 6.

   We can now turn our attention to Products.svelte – leave a line blank after the closing </script> tag, and then add the code from styling – products page.txt in the code download for this book.

   As before, I’ve compressed the styles for space reasons – the code download for this book shows the styles in an uncompressed format.

    

1. 7.

   We need to make a couple of changes to the markup. Look for the start of the #each block, and then replace it with the code from the code download that accompanies this book.

    
2. 8.

   Save the changes to Products.svelte, and then close the file.

   We have a couple more changes to make – this time they are in Cart.svelte.

    
3. 9.

   Go ahead and open this file, and then scroll down to the closing </style> tag.

    
4. 10.

   Leave a line blank, and then add in the styling code from styling – cart.txt in the code download accompanying this book.

    
5. 11.

   Save the file and close it – we’ve completed the changes required in this exercise.

    
6. 12.

   Go ahead and browse to http://localhost:5000, assuming, of course, you have your Svelte development server running! Click Shop | any product name, and you should see something akin to the extract shown in Figure 7-3, with that product added to the cart, in Figure 7-4.

    

That was a lengthy exercise, but we can now celebrate: our site is pretty much now done! Although we’ve focused on styling (which should be pretty straightforward in itself), there are a few things we should cover off; let’s pause for a bit to review the changes made in more detail.

Breaking Apart the Code Changes

Over the last few pages, we’ve made a fair few changes to our code – most of it has been styling, but we’ve also taken the opportunity to tidy up some of the markup at the same time.

This last exercise may have only covered three elements of our site. Still, it was the largest by far – we started by adding all of the relevant styling for the product page, including borders, font-weight, and general alignment.

We then added a hack for our navigation to get around an issue with displaying the product page. If you take a look back at App.svelte, you will see that we put a <Route...> element to help route requests to this page. The problem is that there isn’t a corresponding entry for it in the <Link to="..."> block just above; it means without this hack, we end up with a navigation bar that resizes each time we click a product link. Not a good experience!

Next up came some changes to the <script> block – we commented out some of the condition checks in the addToCart event handler. We lifted and shifted the code from the products page, but as was discovered while writing this book, it meant the items had to exist in the basket first, which wouldn’t always be the case! This way, products will be added, whether they already exist or not, in the basket. It does mean that we would have to implement some better checking to ensure we add valid items, but that would be for another day.

We then turned our attention to the products page – this time, we added styling and updated the #each block in the markup to improve the overall appearance. To round out the demo as our last step, we applied styling for the Cart.svelte component before previewing the results in our browser.

Using a Style Preprocessor

A question – hands up if you’ve used or are familiar with the terms “preprocessing,” “Sass,” or potentially “superset.” Sounds familiar?

Some of you will recognize these terms as being associated with preprocessing CSS. For the uninitiated, it’s about applying a dash of JavaScript-esque variables, simple math calculations, and a few other tricks to create well… valid CSS!

Okay, that’s probably a little glib, but Sass is an excellent tool for writing CSS styles more effectively. Imagine the person who asks you to change the color of every single button on your website, and you know full well that the styles used on the said site are well, shall we say, not the most efficient. To add insult to injury, it’s also 5 pm on a Friday, and you know there is a pint of beer with your name all over it, getting slowly warmer and warmer. If you’ve not had that at some point, you’re not a web developer!

Sass allows us to use a mix of variables and other tricks to avoid the need for multiple updates, so you no longer need to do a tiresome search and replace. You set up variables, so a simple change means every button has the change applied to it. A 30-second change and 5-minute rebuild later, et voilà! Button styling changed.

Okay, I digress – back to reality. As a concept, preprocessing CSS works perfectly with Svelte; we use the svelte-themes-preprocess plugin, available from https://github.com/NikolayMakhonin/svelte-themes-preprocess. It uses “Dart Sass” as a dependency in the background, so we will need to install that too. To see how it works, let’s make a start on our next exercise.

Setting up Postcss

To set up preprocessing, follow these steps:

1. 1.

   First, open a Node.js terminal session, and set the working directory as our project area (if it isn’t already).

    
2. 2.

   At the prompt, enter npm install svelte-preprocess sass and press Enter.

    
3. 3.

   Next, go ahead and open rollup.config.js, and then add this line after the last import statement:

   import { scss } from 'svelte-preprocess'
    
4. 4.
   Scroll down a little further, until you see this in the export block:

   Plugins: [

     svelte({

       compilerOptions: { dev: !production },
    
5. 5.
   Immediately after that last line (and before the closing }),), go ahead and add in this block:

     preprocess: [ scss() ]

   }),
    
6. 6.

   Save the file and close it – the changes for this file are complete.

    
7. 7.
   We have one more chance to make – for this, open a new file and add this code, saving it as svelte.config.js:

   // svelte.config.js

   const preprocess = require('svelte-preprocess');

   module.exports = {

     preprocess: preprocess(),

     // ...other svelte options could go here

   };
    
8. 8.

   It’s time to test the process – we will adapt the existing code for this purpose. Open this file in your editor, and change the opening <style> tag to this:

   <style type="text/scss">
    
9. 9.
   Next, change the last few lines of the style block to match this:

     margin-top: 10px;

     &:hover,

     &:active { background-color: #000000;  color: #ffffff;  box-shadow: 1px 1px 6px rgba(0, 0, 0, 0.26);  }

   }
    
10. 10.

    Go ahead and save the file, then switch back to a Node.js terminal session. At the prompt (and make sure it’s in the project folder!), enter npm run dev and press Enter.

     
11. 11.

    If all is well, we should still see the button on the product page, as indicated in Figure 7-5 – it won’t look any different, but we will serve it from a Sass stylesheet.

     

If you’ve made it this far, then congratulations – you now have a working system for Sass!

Granted, we had to make a few changes to accommodate this feature, but the good thing to note is that they are all pretty much a one-off; we can now focus on just adding styles as we see fit with the changes in place. This demo was a valuable exercise for those familiar with Sass or interested in knowing more about how we can incorporate it when using Svelte – let’s take a more in-depth look at the changes we made to see how it all hangs together.

Taking Things Further

Over these last few pages, we’ve focused all of our efforts on styling our site, but it does raise a few questions, of which one is – once we finish adding our initial styling, how could we take things further if we wanted to?

We can do a few things, such as use CSS-in-JS options like styled components (www.styled-components.com/) or a preprocessor such as Sass. We should also consider how we architect our CSS – should we in-line it or run it from external files? Or is that even an option? These are all interesting questions; we will take a look shortly at how we might use a preprocessor such as Sass as our next exercise, but for now, let’s explore answers to the other two: should we in-line or run externally? And what about using CSS-in-JS solutions?

I would say that the answer is really “it depends”! Yes, I know you’ve probably seen that answer given for dozens of different questions in all manner of contexts, but there is good reason here.

There are a few limitations, particularly around optimization and sharing code, but these the developers hope to address in future versions of Svelte.

Here’s where things get controversial – I would strongly recommend not using CSS-in-JS solutions unless necessary!

With increasing emphasis on speed, CSS-in-JS solutions will add extra weight to the page; we can achieve pretty much all with standard CSS, without the excess baggage that comes with CSS-in-JS options. It doesn’t preclude us from importing styles from libraries such as styled components (www.styled-components.com) or even from third-party NPM modules. Still, we should give serious consideration to whether we can achieve better results with pure CSS, or circumstances are such that we must use third-party libraries in our code.

There are a couple of interesting articles on writing CSS in Svelte that might be of interest at this point – take a look at https://css-tricks.com/what-i-like-about-writing-styles-with-svelte/ and https://svelte.dev/blog/the-zen-of-just-writing-css.

Summary

In the late 1990s/early 2000s, the general theme was to build a website as one giant monolith, with styling coming last. It seemed a long time ago, but the styling stage was (at least for me) a good indicator that we’re coming to the end of a build process and that it won’t be long before we see the results of our work, out in the wild.

We may use a more modular, component-based approach, but the basic principle is still the same – once we reach the styling stage, it won’t be long before we see the results of our work. We’ve taken the same approach in this chapter by focusing on styling each component or page in turn – let’s look back at what we’ve achieved in this chapter.

We started by making a few adjustments to our markup – we talked about this being something of a less conventional approach, but still important if we consider it a form of continuous improvement.

Next up came a quick look at the basic premise of how we should style components in Svelte; we revisited this at the end, with a brief discussion on the merits of why this approach is preferable when using Svelte over alternatives such as CSS-in-JS or external files.

We then moved onto the crux of this chapter, which is styling the individual elements of our site – we started with global changes before focusing on pages, header, footer, buttons, shopping cart, and pages in that order. We rounded out with a quick discussion on some of the ways we could develop styling further but equally considering that many of these ways will mean losing some of the benefits when using single-file components in Svelte.

We’ve covered a lot, but we’re almost done! We still have plenty to explore – next up is probably one of the more essential tasks. It’s time to get testing and finally deploy our website.

Deciding Our Strategy

We could use a host of different testing tools when it comes to testing – do we do unit testing, end-to-end testing, acceptance testing, or something else? So which package do we use – Jest, Mocha, Chai, Cypress, WebDriver, or something completely different? Heck, where does one start?

Well, one might hope things should be straightforward, but based on my research, it would seem not! Several packages are available, such as Svelte Testing Library or Jest (both with additional support for Svelte), but I struggled to get either to work – not a good sign. In the end, I decided to go with Cypress as it has worked very well for me in the past. Of course, there are some limitations, but for this chapter, they are not an issue.

So, with that in mind, this is the strategy I’ve decided to use: we will use Cypress 6.8.0 and the NPM package cypress-svelte-unit-test. It’s not the latest version, as support for Cypress 7 in cypress-svelte-unit-test isn’t available yet.

Cypress is available from www.cypress.io, with documentation at https://docs.cypress.io/. The cypress-svelte-unit-test package is available at https://github.com/bahmutov/cypress-svelte-unit-test.

Out of curiosity, what other packages exist that offer support for testing elements of Svelte?

Okay, now we have our strategy in place. So let’s crack on with the first step: to set up Cypress and the cypress-svelte-unit-test plugin.

Browser Support

Before we do so, I want to consider one critical question, which I am sure will be on your mind when it comes to unit testing: what browsers do we use?

We touched on what is an important point there – some might think we have to test in multiple different browsers, ideally in ones that match those that our customers use. However, at face value, this could present an issue when using Cypress; Cypress does not support IE browsers, for example!

It is less of a concern if we focus on testing just functionality; acceptance testing should come later once we have completed the initial development. With that in mind, it’s worth noting that Cypress supports recent versions of Chrome, Edge, Firefox, Brave (a Chromium derivative), and its in-built browser, Electron.

We can switch between different browsers from within the Cypress GUI (top-right corner); it will display options for any it can find installed and supports, along with an option for Electron.

Focusing on just testing features will, of course, place greater emphasis on testing the site thoroughly when it comes to performing acceptance testing – but I’m sure you would do that as a matter of course, right?

Setting Up the Test Environment

One of the great things I love about Cypress is that it is a single install, but it incorporates a host of different toolsets into a unified GUI. Before Cypress came along, we would have to install several tools such as Mocha, Chai/Expect.js, and Webdriver; Cypress includes all of the necessary tools as standard.

Cypress itself is easy to set up: we can download a version to install, but it’s simpler to install it using NPM. However, to get it installed and set up to support Svelte components requires a few steps – let’s look at what’s involved in the next exercise.

Installing and Configuring Cypress

To get Cypress set up and configured to work with Svelte components, follow these steps:

1. 1.

   First, we need to install Cypress – for this, fire up a Node.js terminal, and change the working folder to our project area.

    
2. 2.

   At the prompt, enter npm install cypress @6.8.0 cypress-svelte-unit-test and press Enter.

    
3. 3.
   Cypress takes a few minutes to install, so while that’s happening, crack open the cypress\plugins\index.js file, and then replace the code with this – we use it to tell Svelte to bundle spec files:

   files:module.exports = (on) => {

     const filePreprocessor = require('@bahmutov/cy-rollup')

     on('file:preprocessor', filePreprocessor())

   }
    
4. 4.
   Please save the file and close it. We now need to turn the (experimental) component support on in cypress.json (located at the root of the project folder). So go ahead and replace the contents of that file with this:

   {

     "experimentalComponentTesting": true,

     "componentFolder": "./src/components",

     "testFiles": "**/*spec.js"

   }
    
5. 5.
   Save that file, and then switch to package.json in your editor – go ahead and modify the scripts block to include this extra line:

     "scripts": {

       "build": "rollup -c",

       "dev": "rollup -c -w",

       "start": "sirv public -s",

       "start:dev": "sirv public --dev -s",

       "cypress:open": "node_modules\\.bin\\cypress open"

     },

   This last (highlighted) line is written for Windows – please adjust to suit your operating system if you are not using Windows.

    

1. 6.

   We have one more change to make – fire up your file manager, and then browse to the \cypress\integration folder in your project area. Move all of the files to another location outside your project folder for safekeeping.

   This step is voluntary but recommended – it makes for a cleaner view when we open the Cypress GUI, as we will only have our tests visible, not a bunch of examples! However, if you’re new to Cypress, then it’s worth taking a look at the examples separately to get a feel for how to write Cypress tests.

    

1. 7.

   At this point, all changes are now complete – save the files, and then close them. We can now open Cypress by entering npm run cypress:open at the prompt and pressing Enter.

    
2. 8.

   If all is well, we should see something akin to the screenshot shown in Figure 8-1.

    

Getting our testing environment set up is a big step forward and arguably the most complex part – we can now start testing! The message we see when firing up Cypress for the first time might seem a little scary, but something we should expect to see: we’ve not yet written any tests, which will come later in this chapter. In the meantime, we’ve covered some essential points in the approach and setup of our testing tool, so let’s spend a few moments going through what we’ve covered in the last exercise in more detail.

Creating an Example Test

Over the following few pages, we’re going to use our new setup to test that Cypress works, so we can get a feel for what to expect. First, I will focus on using an example that is not part of our project; we will switch to adding tests for our demo front end later in this chapter.

We will choose an easy target for this test – I can’t think of a more appropriate one than Svelte’s website itself! As this is a public website, we will keep the test simple to keep demand low; we will test for the three colored boxes on the page and that they all have different colors.

Testing Svelte Website

Writing tests in Cypress is easy, thanks (at least in part) to the natural language syntax. To see how easy, go ahead with these steps to create our first test:

1. 1.

   Fire up your text editor, and then create a new document – save it as example1.spec.js in the \cypress\integration\ folder.

    
2. 2.
   In that document, go ahead and add this block first:

   beforeEach(() => {

     cy.visit("https://svelte.dev");

   })
    
3. 3.
   Leave a line blank, and then add in the first part of our tests – this takes care of counting the right number of boxes present on the page:

   describe('Testing Svelte website front page', () => {

     it('shows 3 boxes', () => {

       cy.get('.box').should('have.length', 3);

     })
    
4. 4.
   This next text checks the background color of each box as expected:

     it('each box is of a different color', () => {

       cy.get('.box:nth-child(1)').should(

         'have.css',

         'background-color',

         'rgb(255, 62, 0)'

       )

       cy.get('.box:nth-child(2)').should(

         'have.css',

         'background-color',

         'rgb(64, 179, 255)'

       )

       cy.get('.box:nth-child(3)').should(

         'have.css',

         'background-color',

         'rgb(103, 103, 120)'

       )

     });

   })
    
5. 5.

   Save the file, and then switch to a Node.js terminal session – make sure that the working folder is our project area.

    
6. 6.

   At the prompt, enter npm run cypress:open – give it a couple of minutes to allow the Cypress GUI to appear.

    
7. 7.

   Go ahead and click the name of the test – it will fire up a new window, and then load and run the test.

    
8. 8.

   If all is well, we should see something akin to the screenshot shown in Figure 8-2, where the results show a successful test.

    

A simple test, but one that shows the power of Cypress – I will bet that if you read the code carefully, you could probably work out what each step does without too much prompting! That said, it’s worth taking a few minutes to work our way through each step in more detail; let’s break down the code before moving onto the second of two of our demo tests.

We started by creating our test file – Cypress can work with different file extensions for writing tests, but the usual convention is to end each file with .spec.js as the preferred format. Next up, we added a before statement, which acts as a precondition where we visit the site first before running the tests. We then added tests: the first checked that the box count has a length of 3. In the second test, we checked the CSS property of background color for each to confirm what colors they had (in effect, making sure all are different).

We then rounded out the demo by running that test in the Cypress GUI – we confirmed it completed successfully, which means our testing installation works as expected.

One thing to point out, though – our test uses the URL route to verify the state of each box; this works perfectly well but isn’t always ideal. A better approach allows us to test a component in isolation: it requires a change to our file structure, so let’s dive in and explore what this means for us in more detail.

A Note About File Structure

At this point, you might be wondering why I’m making particular reference to the file structure – there is a good reason for this, though: it has to do with how we are testing our components.

In these two demos, we’ve tested using the URL for the page – you will see that in subsequent tests, we will test by mounting the component directly and test it in isolation.

The usual convention is for tests using the URL method usually go in the \cypress\integration folder, although we can change this setting in the cypress.json file. However, when we create tests that mount components directly, we will put these inside a subfolder that sits in the \src\components folder, which is a prerequisite for the cypress-svelte-unit-test plugin.