Use auto-subscriptions in Svelte 3 to avoid memory leaks when using Stores

Tomasz Łakomy
InstructorTomasz Łakomy

Share this video with your friends

Send Tweet
Published 3 years ago
Updated a year ago

It's important to avoid memory leaks, and Svelte 3 is no exception. When we're using the subscribe method from Svelte store in a component, it's important to clean ofter ourselves (especially if we're going to instantiate and destroy this component many times over).

In this lesson we're going to learn how to use unsubscribe to stop subscribing to the store change in a component's onDestroy call, as well how to use auto-subscriptions to refer to the store value and let Svelte take care of cleaning after us to avoid memory leaks.

Instructor: [0:00] We have a working counter app. I can increment, decrement, and set the value of the counter.

[0:04] If I want to destroy and create this component many times over, I would have a memory leak. Memory leak will happen because I am only subscribing to the store method and we are not unsubscribing from this store method in any place.

[0:16] We can fix that. Whenever we subscribe to the store, it's actually going to return a function. This function, it would be unsubscribed. Now, we need to figure out when is the correct moment to use it.

[0:27] One way to fix that issue, it will be to import onDestroy from Svelte. Whenever this component is being destroyed, we would call the unsubscribe function. This pattern of subscribing and unsubscribing get a bit boilerplate if we were to use multiple stores.

[0:45] Luckily, there's another way to do it with Svelte. We can delete all of that. Instead, we're going to attach a $ to our store value imported from the store.

[0:55] Basically, if you have a $ and the variable name imported from the store, Svelte is going to assume that we want to refer to the value stored within the store. Right now, if I increment, decrement, and send the counter value, it's going to work as intended with much less boilerplate.

[1:11] This value is going to be unsubscribed by default whenever we destroy the component. As such, we won't have any memory leaks.