Save the resume configuration

[00:00 - 00:13] We have given the user many configuration options for their resume as well as the ability to edit all the text. In the previous lesson, we gave the user the ability to export the resume as a PDF.

[00:14 - 00:28] The only thing we still need for a great app is the ability to save the resume. The user might not want to export the resume right away, for example, because they still have to decide on which skills to include in the resume, or which colors to choose.

[00:29 - 00:39] We have to give the user the ability to save the current state of their resume. For that, we will add a button that will save the configuration in the local storage.

[00:40 - 00:57] The local storage of the browser, not to be confused with the session's storage , can save information even after a tap or window is closed. Once the user reopens the page, they will find the resume to have the same exact text, sections and configuration as it did when they saved it.

[00:58 - 01:08] This approach is very privacy friendly. The resume contains sensitive data, such as name, phone number and address, and we don't want this data to reach the wrong hands.

[01:09 - 01:24] By saving it and the user's browser, there is no chance of someone getting access to that data. The data saved in local storage can only be accessed within the same browser, that it was saved and only within the same website that started there.

[01:25 - 01:33] One limitation is that the persisting and accessing of the data does not work across browsers. That is because each browser has its own local storage.

[01:34 - 01:50] If you save data on Chrome and then open the page in Safari, Safari won't know about the configuration saved in the local storage of Chrome. Likewise, when the user saves the data in a cognitive mode, the data is automatically cleared when the user closes the private browsing session.

[01:51 - 02:08] The data in local storage has a size limit of 5 to 10 megabytes depending on the browser, but this won't be a problem for the resume configuration data. To trigger the action of saving the current resume state to local storage, we first add a button above the resume.

[02:09 - 03:49] We can use our custom button component for that. Since we want to store the entire configuration object, we must convert it into a JSON string first.

[03:50 - 04:01] We can access the reactive data object from within the component with this dot dot our sign data. Let's inspect this value first in the console.

[04:02 - 04:38] As you can see, the data object as a JSON string gets locked. We will store this value in the local storage with the key resume.

[04:39 - 04:59] You can see the value stored in the local storage with Chrome DevTools and the applications tab. As you can see, the configuration was saved.

[05:00 - 05:17] The second part of this is that upon opening the page, we want our app to check if there is a configuration pre-safe, and if so, replace the default configuration with it. We want to run this logic ideally before the page renders the default configuration.

[05:18 - 05:32] To hook into this early phase of the components lifecycle, you provide life cycle hooks. View components have a life cycle that determines the sequence of events they go through, from initialization to the structure.

[05:33 - 05:46] These lifecycle methods allow us to hook into specific points in a component's life and run code. In the view documentation, you see which lifecycle hooks are available.

[05:47 - 05:59] We want to hook an early in the application lifecycle. The first hook available to us, since we are using the options API, is the created hook.

[06:00 - 06:16] This hook gets executed before the mounted hook, which is when the component gets added to the DOM. Since our requirement is that we want to update the components data before it gets rendered, this hook should work for us.

[06:17 - 06:28] We use the created hook by adding a method to our component with the name of this hook. Be careful, this method does not go into the methods object though.

[06:29 - 06:39] I will add it at the very top of our component. The code inside that method will then be executed when the created hook is caught.

[06:40 - 07:07] In the created hook, we retrieve the configuration from the local storage and save the value to our saved resume variable. If this value is not null, we want to pass the JSON string to get the configuration object.

[07:08 - 07:34] We want to encapsulate the process of parsing the JSON data and loading it into the components data object within a try and catch statement. This ensures that we can gracefully handle parsing errors that might occur during this operation.

[07:35 - 07:57] This is not the error, but feel free to show the user a warning message if an error occurs. We will load the configuration object into the data object with the method load into data, which we will define in the next step.

[07:58 - 08:21] We add the load into data method to our methods object. This method takes the saved configuration object as an argument.

[08:22 - 08:49] We want to iterate through each key of this object and check if the key exists in our components data object. If it does, we want to set the value of that data property equal to the value of the respective configuration object's property.

[08:50 - 09:06] With the method has on property, one can check if an object has a property. We cannot use this dot has on property because our component instance is not equal to a JavaScript object instance and does not have this method.

[09:07 - 09:37] Instead, we can call it has on property under this dot dot our signed data variable, which contains our data object. Let's test it out by changing the configuration a bit, closing the browser window and reopening the page.

[09:38 - 10:50] As you can see, the state of the configuration is saved and we can continue editing where we left off. [Music] [Music]