1 00:00:02,000 --> 00:00:03,000 Now we made good progress 2 00:00:03,000 --> 00:00:07,000 before we explored as change Password feature 3 00:00:07,000 --> 00:00:08,000 and all of that. 4 00:00:08,000 --> 00:00:10,000 There is a little optimization, which you could 5 00:00:10,000 --> 00:00:12,000 consider implementing, especially if you had 6 00:00:12,000 --> 00:00:14,000 a bigger Application. 7 00:00:14,000 --> 00:00:18,000 At the moment, we're using this session 8 00:00:18,000 --> 00:00:21,000 functionality in a couple of different components. 9 00:00:21,000 --> 00:00:22,000 To be precise we use use session 10 00:00:22,000 --> 00:00:26,000 in the Main Navigation component. 11 00:00:26,000 --> 00:00:27,000 Now, one problem we have 12 00:00:27,000 --> 00:00:32,000 with that is that if we are authenticated 13 00:00:33,000 --> 00:00:37,000 and I reload whilst on this profile page 14 00:00:37,000 --> 00:00:40,000 then we figure out whether the user is authenticated 15 00:00:40,000 --> 00:00:45,000 or not in that get service side props function of that page, 16 00:00:45,000 --> 00:00:48,000 here, this function runs, 17 00:00:48,000 --> 00:00:53,000 and then after the page was loaded, does use session hook 18 00:00:53,000 --> 00:00:56,000 which we use and Main Navigation. 19 00:00:56,000 --> 00:00:59,000 We'll technically also, again, run some logic to find 20 00:00:59,000 --> 00:01:02,000 out whether we have a session or not. 21 00:01:02,000 --> 00:01:05,000 And we see this here in the Network tab. 22 00:01:05,000 --> 00:01:08,000 If I reload, you see there is a request being 23 00:01:08,000 --> 00:01:12,000 sent to /api/auth/session. 24 00:01:12,000 --> 00:01:17,000 That request is actually sent by that use session hook. 25 00:01:18,000 --> 00:01:21,000 And it's sent to check Whether that session cookie 26 00:01:21,000 --> 00:01:23,000 which had found is valid, 27 00:01:23,000 --> 00:01:25,000 because we can't validate that 28 00:01:25,000 --> 00:01:29,000 with client site JavaScript for security reasons. 29 00:01:29,000 --> 00:01:31,000 Hence that cookie needs to be sent to an end point 30 00:01:31,000 --> 00:01:35,000 which then determines whether it is valid or not. 31 00:01:35,000 --> 00:01:38,000 So that's why this request is being sent. 32 00:01:38,000 --> 00:01:40,000 There is nothing wrong with this request, but 33 00:01:40,000 --> 00:01:44,000 since we already checked our session here in 34 00:01:44,000 --> 00:01:46,000 getServerSideProps. 35 00:01:46,000 --> 00:01:48,000 when we loaded slash profile 36 00:01:48,000 --> 00:01:51,000 we already know that we are authenticated. 37 00:01:51,000 --> 00:01:54,000 So this is actually a redundant request 38 00:01:54,000 --> 00:01:56,000 which is being sent here. 39 00:01:56,000 --> 00:01:58,000 And we can avoid it, 40 00:01:58,000 --> 00:02:00,000 by using a extra component offered 41 00:02:00,000 --> 00:02:05,000 by next off in our _app.JS file. 42 00:02:05,000 --> 00:02:08,000 So in this file which wraps all our page components, 43 00:02:08,000 --> 00:02:10,000 which are being rendered. 44 00:02:10,000 --> 00:02:15,000 We can import the special Provider component from 45 00:02:15,000 --> 00:02:18,000 next-auth/client. 46 00:02:19,000 --> 00:02:20,000 This is a wrapper 47 00:02:20,000 --> 00:02:24,000 which we can wrap around all our other components. 48 00:02:24,000 --> 00:02:27,000 So around the layout and de nested components 49 00:02:29,000 --> 00:02:30,000 and then Provider 50 00:02:30,000 --> 00:02:35,000 once a session prop, and here we simply set, 51 00:02:36,000 --> 00:02:39,000 any session data, which we might already have. 52 00:02:39,000 --> 00:02:41,000 Now, the interesting thing is 53 00:02:41,000 --> 00:02:44,000 that here in this root app component 54 00:02:44,000 --> 00:02:48,000 we don't just get the page component that should be loaded 55 00:02:48,000 --> 00:02:51,000 but all of the Props for that page. 56 00:02:51,000 --> 00:02:54,000 So the Props determined by get static Props 57 00:02:54,000 --> 00:02:56,000 or getServerSideProps, 58 00:02:56,000 --> 00:02:59,000 and at least for our profile page 59 00:02:59,000 --> 00:03:02,000 these Props will contain a session key 60 00:03:02,000 --> 00:03:07,000 with the session we validated inside of getServerSideProps. 61 00:03:08,000 --> 00:03:11,000 So we are setting this session Prop 62 00:03:11,000 --> 00:03:15,000 on this profile page and we are setting it to this session 63 00:03:15,000 --> 00:03:17,000 which we already loaded 64 00:03:17,000 --> 00:03:20,000 and validated with that service side code. 65 00:03:21,000 --> 00:03:25,000 That means that not all our pages, but some pages 66 00:03:25,000 --> 00:03:28,000 in this case, the Profile page we'll have a session 67 00:03:28,000 --> 00:03:31,000 Prop with session data. 68 00:03:31,000 --> 00:03:33,000 So we can set the session 69 00:03:33,000 --> 00:03:38,000 for this Provider component equal to pageProps.session. 70 00:03:38,000 --> 00:03:41,000 In most cases, this will be undefined 71 00:03:41,000 --> 00:03:44,000 because most pages don't have this Prop 72 00:03:44,000 --> 00:03:48,000 but our profile page, for example, does have it. 73 00:03:48,000 --> 00:03:51,000 And then the session is already set to this already 74 00:03:51,000 --> 00:03:53,000 loaded session. 75 00:03:53,000 --> 00:03:58,000 And that then allows next off to skip the extra session 76 00:03:58,000 --> 00:04:01,000 check performed by use session. 77 00:04:01,000 --> 00:04:01,000 If we already have the session from our 78 00:04:01,000 --> 00:04:05,000 getServeSideProp function. 79 00:04:06,000 --> 00:04:09,000 Now, if we loaded number of component, where does this not 80 00:04:09,000 --> 00:04:12,000 set session is on the find and use session 81 00:04:12,000 --> 00:04:16,000 We'll still do its thing and check it manually. 82 00:04:16,000 --> 00:04:19,000 But in cases where we already know that there is a session 83 00:04:19,000 --> 00:04:22,000 we can save some performance and a wide 84 00:04:22,000 --> 00:04:25,000 some redundant HTTP requests. 85 00:04:25,000 --> 00:04:28,000 And that's never a bad thing simply by wrapping our 86 00:04:28,000 --> 00:04:32,000 Application with this extra provider component 87 00:04:32,000 --> 00:04:36,000 and utilizing the information which we already have, 88 00:04:36,000 --> 00:04:39,000 now here in my case, I actually still see this extra session 89 00:04:39,000 --> 00:04:42,000 request being made here thereafter. 90 00:04:42,000 --> 00:04:44,000 Next off will have its reasons. 91 00:04:44,000 --> 00:04:49,000 Nonetheless, using this provider wrapper, is a recommended 92 00:04:49,000 --> 00:04:53,000 pattern because it theoretically or practically allows next 93 00:04:53,000 --> 00:04:57,000 off to optimize itself internally, 94 00:04:57,000 --> 00:04:59,000 and skip certain checks 95 00:04:59,000 --> 00:05:01,000 and possibly HTTP requests. 96 00:05:01,000 --> 00:05:04,000 Even though we unfortunately don't see that here 97 00:05:04,000 --> 00:05:06,000 nonetheless, adding this extra wrapper is 98 00:05:06,000 --> 00:05:09,000 a recommended optimization 99 00:05:09,000 --> 00:05:12,000 which idea for, of course also a wanted to show to You.