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.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!