If you're interested, the code is on github.com. There's the initial code and then the final code. And if you have any question, I'm here for it. Thank you.
How would you store the data? This was early on in your presentation, so think back early in your presentation. How would you store the data if a page reload occurs when using this concept local session storage or using a different store? Yes, you can use local storage in general. This is something that I think a lot of framework co-authors actually advise against, and it's the fact that, like, people very often rely on effects to do this kind of stuff. But very often, it's not needed. Like, effectively, what you can do is, like, if you want to store inside the local storage, for example, you could use an effect to synchronize. And that's actually decent to do. But the very worst thing that you can do is reassign state inside an effect. And so, whenever you do, like, what I would do is probably just create a wrapper around it so that whenever you set the state, instead of doing it in a side effect, in the same line, you can set the state and then also store it in the local storage. So, if you do something like this, like, the code is much more contained. It's much more, how can I say? Like, one line after the other, you can clearly see what you are doing. You are setting the state and storing the value in the local storage. And it's much easier to reason about instead of, oh, if I change this value, an effect in the other side of the project, sorry, the lab that was the other side of the project is changing. Clearly, that was the other side of the project. Cool. Thank you.
Can you describe one of the top complex scenarios that Svelte had to handle in the signals implementation? So, if you're asking about, like, what's the complex part of the signal-based reactivity system of Svelte, I would say that it's the unknown derived. So, the problem with signals is that you generally always have to clean up your memory. So, obviously, I didn't delve into this inside this presentation, but generally, what every signal framework do is create a root effect which is more memory efficient than the normal effect and you store, like, basically, you use that as an entry point so that at the end of the page, that effect is responsible to cleaning up all the effect that you create because otherwise, you would have a bunch of memory, like, just left there. And the problem is, like, in Svelte, for example, as long as you are inside the component, that component can handle the memory of the signals that you create inside it. But in Svelte 5, you can also create signals just in a module and a derived that is created inside a module, it's called an unknown derived because obviously, you are going to use that derived everywhere in your application, so not in a specific component. So, this means that, like, we need to do all sorts of, like, to actually clean up, like, to avoid memory leaks with the unknown derived. So, that's the most complex part of the signal-based implementation. Got it. Thank you. I thought, like, what is the most complex part about implementing anything is, like, working with others and making sure that something happens.
Comments