Svelte Fundamentals

Module Context & Debugging

Svelte Fundamentals

Check out a free preview of the full Svelte Fundamentals course

The "Module Context & Debugging" Lesson is part of the full, Svelte Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Rich demonstrates implementing and exporting context in script blocks, which will run the inside code once the module evaluates. Adding a debugging statement inside the component markup using the debug tag is also covered in this segment.

Preview
Close

Transcript from the "Module Context & Debugging" Lesson

[00:00:00]
>> So in all the examples that we've looked at so far, the script block contains code that runs when each component is initialized. And most of the time that is all that you will need. Very occasionally, you will need to run some code outside of an individual component instance.

[00:00:15]
So if you go back to our audio example from earlier. One thing about this that's not so great is that you can play, all of these tracks simultaneously, right? This is not what we want in a music player app. It'd be better if we could stop the current audio from playing when a new audio player starts.

[00:00:38]
And we can do that by declaring some module context. Inside AudioPlayer.svelte, we're gonna create a new script block, but this time we're gonna add this context = module attribute. Inside that we're gonna declare a value current. And all of the instances of audio player can see that value.

[00:01:12]
And so on our audio player, we can add an event listener. When the audio starts playing, We check if there's an existing audio element playing, and if so, we pause it. Right, if this audio element is not current, and if the current exists, pause it, and change the value of current to be the current audio.

[00:01:56]
Right, and now when we start playing these,

[00:01:58]
[MUSIC]

[00:02:00]
Each new audio player will stop the last one. We can also export things from the module context. So again back in AudioPlayer.svelte, we have this module context, and we would like to make it possible for a consumer of this component to stop all of the audio. So create a new function, stopAll.

[00:02:34]
And if there is a current audio element, we'll pause it. And then now inside our App.svelt, we can now import the named function that we just declared, just like any other JavaScript module. And we can add a new button below the audio tracks. And we click it, we just call that function.

[00:03:12]
[MUSIC]

[00:03:16]
Works as expected. So you cannot have a default export from your script context = module because the component is the default export. Yep, it's basically just a normal JavaScript module, and so you have all of the power of a normal JavaScript module. Does anyone have any questions about module context?

[00:03:38]
All right, we're getting very close, yes, Chris.
>> What was the purpose of instantiating current in a separate script block?
>> So if you were to declare current inside the normal script, this is scoped to the component instance. So inside here, we can change the value inside the component, but it doesn't impact any of the other components.

[00:04:03]
By having it up here, this is part of the module, and all of the instances of this component can read the same variable.
>> Does this affect after update? I mean, does it trigger a rerender across all of the components sharing this context?
>> No, it does not.

[00:04:21]
So the values inside the context=module, these are not reactive in the same way that variables inside the component's normal script block are reactive. This is just a regular JavaScript variable with no magic applied to it. If you do want components to be able to react to changes in this data, that's when you should use a store instead of a normal variable.

[00:04:45]
Okay, so sometimes it's useful to be able to inspect a piece of data as it's flowing through your app. You can use console.log liberally inside your markup if you want. But if you wanna add a debugger statement inside your component markup, you can do that with the debug tag with a comma separated list of the values that you want to inspect.

[00:05:05]
So in our App.svelte here, we've got a console.log of user, and when we change the value of that, it's gonna get logged to the console. This is easiest to see if I open this in a separate window. Let's get rid of all of the junk. If we start typing in here, you'll see that it does in fact get logged out.

[00:05:31]
But we can do one better than that. We can get rid of the console.log and replace it with a debug tag. And now you'll see that because we have devtools open, we've actually paused execution of the component and we can start to see these local variables. And we can interact with them and understand how the data is flowing through our application.

[00:05:56]
And that concludes parts one and two of the Svelte tutorial. You basically know everything there is to know about Svelte now. All of the features that Svelte itself has to offer. So hopefully, you've learned something during this process, whether it's entirely new things or a refresher of things that you are a little bit rusty on.

[00:06:23]
But for now, you should take a break, pat yourself on the back, and feel good about becoming a Svelte expert.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now