For this next lesson, I went ahead and converted the project to next. Let's first take a look at the new structure. The PIA plugin of last lesson has been moved to the PIA directory because the plugins directory is reserved for next plugins. In here we register pia, our persisted state plugin and our own toast plugin. The router has been replaced by file-based routing of next. So if you look inside the pages directory,

The router has been replaced by file-based routing of next. So if you look inside the pages directory, we'll see our homepage being the index. We'll see our checkout page, the login page, profile page, register page, and our thank you page with an order ID. In the URL I defined a default layout in the layouts directory where I added a teleport for toaster. Another change is the middleware that now lives in its own directory. We have two files. We have our auth middleware and as

that now lives in its own directory. We have two files. We have our auth middleware and as before, our auth middleware will check if we have a User and if not, we'll redirect to the login page. If we check the profile page. In here, we define our page meta and we instruct nooks that the middleware auth needs to be applied before viewing this page. And we have a special new middleware called inITUserStore.

And we have a special new middleware called ITUserStore. But because we give it a global post fix, it gets loaded automatically in this middleware. We will simply initialize our UserStore as before our PStores are unchanged and will still work as before. If we take a look at our project, everything still works as before we have our shopping cart we can check out, we can sign in And we can

before we have our shopping cart we can check out, we can sign in And we can confirm our order. And as you can see, the URL structure stayed the same. We can go to our profile page still, we will see our order history and we can log out. So everything functionality wise still works. Now the big reason for converting our product to next is because next has great server site rendering or SSR compatibility and that's what we'll be covering now.

because next has great server site rendering or SSR compatibility and that's what we'll be covering now. Enabling SSR in next is pretty simple. You open nodemon config.ts, you find SSR and you will say true, but this is where things will start to go wrong. We get an error that states localStorage is not defined and it makes sense if you think about it, localStorage is a browser specific feature and when next is trying to render the page on the server,

local storage is a browser specific feature and when N is trying to render the page on the server, it'll fail because local storage is not available on the server looking for us. PIA persisted state has built in support for next and all we need to do is update the next config as follows. In here, we'll say modules, plugin persisted state slash next. Next we open our plugins, PIA plugins, and we remove pina use PIA plugin, persisted state.

Next we open our plugins, PIA plugins, and we remove pina use PIA plugin, persisted state. There we go. And where we refresh, we'll still get an error. And that's because in our user store we still call localStorage manually. Let's convert our user store to PIA plugin persisted state. Now together, let's add an option, persist enabled through and let's pick authToken. There we go. Now if we go to init, we'll see we get our token from localStorage,

There we go. Now if we go to init, we'll see we get our token from localStorage, but we cannot do that anymore. So we'll say if this authToken, we'll say this setToken. With our token we can remove our localStorage.setItem as follows, and this should be enough to remove our error. And there we go. Our page now renders again. Cool. Now let's log in. We can see we are logged in.

Now let's log in. We can see we are logged in and when we refresh, we stay logged in. So that's cool. And if you go to our profile, we'll see our order history is not loading, so let's pop up the inspector and refresh the page and we see a 401 even though we are seemingly authorized. Now why is this happening? If you take a look at our middleware in App\Http\Middleware\Authenticate and we say console.log, we are ting uh,

in IT User store and we say console.log, we are ting uh, the user store and let's put it here. Let's take a look at our console. We refresh and we see SSR. We are knitting the user store. So this happens on the server. And if we open our dev tools, we go to user. We do see the out token being present in the state as well. If we jump into our user store in it and we continue to set token in here,

If we jump into our userStore in it and we continue to set token in here, we set our authorizationHeader on Monday. And even though our state gets hydrated in the client from the server or Monday instance is not gonna be the same. The fix for this is actually pretty simple. We cut this and we paste it here. We can actually say if userStore.authToken, we'll say the userStore.authToken and else we'll say and delete our authorizationHeader.

the User store auth token and else we'll say and delete our authorization header and we can clean this up. There we go. Now the User store gets initialized on the server and we are setting up our Monday default both on the server and on the client. And now when we visit the profile page, we'll see our order history gets loaded as expected. Now if you open up our Product store, we can actually make some changes here.

Now if you open up our app.vue, we can actually await the fetching of the products. So now when we refresh the page, we'll see the products are loaded instantly in an SSR.

So now when we refresh the page, we'll see the products are loaded instantly in an SSR context or simple caching mechanism doesn't really make sense anymore and that's the reason we can get rid of it. If you take a look at our source code and we look for pizza for example, we can see the products are rendered in the HTML as well. In the front end, the products will already be loaded because the server already fetched them and the state will copy over from the

because the server already fetched them and the state will copy over from the server to the front end. Now state management in next goes beyond pina. We can for example, also leverage cookies directly. Let's add a toggle to the nav bar to toggle between US dollars and euros. Let's open up the N bar. We can add a new button. I'll copy the classes here and let's say currency.

I'll copy the classes here and let's say currency. And when we click on it, we'll say toggleCurrency. Let's go to our script. We'll say const currency equals a useCookie currency. We can add a default of US dollars and there we go. And const totalCurrency equals we'll say currencyValue equals euros. If the currencyValue equals dollars And otherwise, let's say the currency.

If the currency value equals dollars And otherwise, let's say the currency equals dollars again, and our default should actually be a function, we'll say default return US dollars. Now in our never we'll have a $ sign and when we click it, it turns into a Euro sign and vice versa. Finally, let's open up our format function. And in here we'll read from the cookie.

Finally, let's open up our format function. And in here we'll read from the cookie. We'll say $currency equals use cookie $currency, and we'll say return US dollars and we'll say $currency value. And now when we change the currency to euros, the currency will change throughout our entire application. And the cool thing is when we refresh because we use cookies, the currency will still be set to euros.

because we use cookies, the currency will still be set to euros. If we open up the dev tools and we go to application cookies and we click on our frame, we can see our currency cookie being added here. If we delete it, it falls back to our default being the US dollars. As you saw, pinya and Nux play along very nice, and because of that, adding SSR support to our project was actually pretty easy by using.

because of that, adding SSR support to our project was actually pretty easy by using. Next, we can also use cookies directly using the useCookie composable and cookies are available both on the server and on the client. And with that, I'll see you in the next lesson.