Angular's reactive signals provide a way to manage state, but you may also want to persist that state across page refreshes or browser sessions.
This can be achieved by synchronizing the signal's value with the browser's local storage using an effect
[00:00] Create a new effect which is going to synchronize the value of the item signal with local storage. But first, let's assign the effect to a new property synchronize items effect. What we need to do whenever the item signal value change, we need to [00:20] write it to local storage using the local storage dot set item. Our key is going to be for instance items and the value is JSON dot stringify where the value is going to be this dot items. And that's all we need to write. Now whenever the value of [00:40] the item signal change, the entire effect is going to reevaluate. So let's see what is the value that we've got in local storage. So local storage dot get item, and let's put the items key. We can see that is a stringified array including the three [01:00] elements which we've got over here. So let's see what happens if we go back to actually clearing the items array. So when we run clear items, let's see what we've got in the items in local storage that's empty. Also, when we add a new element [01:19] which is Dan, we can also see that the new items in local storage is Dan. Now, if you want to make the synchronization the other way around, we would have to remove the initial hard coded value from the signal creation so that when the signal gets created, it would [01:39] actually read the value from local stories. So let's copy the code that reads the stringified items value, but we would also have to JSON parse the stringified value. So after pasting the code, we can see that TypeScript is throwing 2 compilation errors though. The first one is [01:59] going to be the null here. And that's because TypeScript cannot guarantee that the key items exist in local storage. In case it didn't exist, it would return null. So we're just going to quickly hack TypeScript. We're not going to put any type guards and any runtime checks. So that's the first [02:19] thing. However, the second error is that parse is going to return any because types of cannot guarantee what could be a stringified value that we're going to parse. And for this reason, we would quickly create the type for the item. In our case, that's ID of type number and name [02:39] of type string. And since we want the value of the signal not to be of type any, let's just make a type assertion that we guarantee that whatever was inside the local storage is going to be item. So we can see that here. We've got Dan. [02:59] So this is the initial value. However, if we create Elia and we add the new item, This is basically a array including 2 elements which are already synchronized with the local storage. And now if I refresh the page, we can also see that the two [03:18] values, one within the signal and the other one within the local storage gets synchronized both ways.
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!