00:02
The next new feature to Inertia 2.0 that we'll discuss is deferred props. This is another one that improves the perceived performance of our application
00:12
to our end users. The way it works is it allows us to defer one or more of our stateful properties for our page until after the page itself has already rendered.
00:22
So since our pending organization invitations are last on our organization settings page, if we wanted to defer loading the actual invitations
00:30
that we have until after this page itself has already rendered, we can use deferred props to do just that. The way it works is we have our async callback functions
00:40
on each one of these props set already within our organization settings controller. So we just need to specify that the property that we want to defer is indeed going to be deferred
00:49
using our new inertia method called defer. And once we do that, invites will now be omitted from the data for our initial page load
00:58
and then be fetched after the page itself is rendered. So if we give this a save, I also want to note that I have temporarily commented out our polling so that we don't have a bunch of conflicting network requests
01:08
that we're taking a look at. Let's right click, inspect, and jump over into our network tab. If we go ahead and refresh so that we get a fresh load of our data, we can see that when our page was mounted,
01:18
we did asynchronous requests out for our difficulty statuses and access levels. This is from the unmounted prefetching that we were working on in the last lesson.
01:26
So we can ignore those in this specific case, but then we have one more here for our organization page, specifically our settings organizations. If we take a look at the response data for this,
01:36
take a look at the props. We only got our invitations back for this. And this is the deferred loading now taking place. On the initial page render,
01:45
all of the other data was included with our server side fetch. So it didn't need to asynchronously load any of that data. It was all taken care of on the server. And then we got back the information
01:55
for the initial render directly via inertia. But then after the page itself loaded, it went back through and loaded in our invitations because we've specified it to defer its loading.
02:05
If we go ahead and minimize our dev tools down a little bit and scroll on down, we can indeed see that our pending organization invitations render and loaded successfully.
02:14
So we still see it on the page. It just improves the perceived load time because our user is able to actually get to the page without having to load in that data.
02:22
So if you have a slow query that may take a minute, you can defer that, and then it will load in after the page is already visible to the user. That's also useful in our case here
02:32
where we have some data that's lower down on the page that may not need to be loaded initially for the user itself. Now, if we have multiple props
02:40
that we're passing into our page that are deferred. So if we were to wrap our users in a defer method here as well, now both our users and our invites will load deferred
02:50
after our page is rendered. If we go ahead and refresh our page, we'll first see those three prefetched calls for our difficulty statuses and access levels. Again, we can ignore those.
02:59
And then we have our organization settings load here. This now includes props for both our users and our invitations. So now both our invites and our organization users
03:09
are loading deferred. And it's sending those back together via a single request. If however, we needed those split apart into two separate requests, similar to how our prefetching is,
03:19
we could instead apply a group to one or more of these deferred loads. So that's the second argument here. And this is the type string. We just give it some name.
03:29
So if we add invites to an invites group, now it will load our users separate from our invitations because the invites are going to be inside of an invites group call.
03:38
And then the users will be in the default grouping. We'd also apply users to a separate group as well if we wished. But since we are only working with two, that will be the default behavior here anyway.
03:48
So let's refresh our page. And now you see we have two organization calls go out. One is going to include our users and the second is going to include our invites.
03:57
Now let's say that you are actually working with a slow query and you don't want this space to be blank here on the page. So let's go ahead and mock up a slow query here
04:07
with our invites. Import setTimeout from node.js timers promises. This will allow us to await a setTimeout call
04:15
and let's just delay this by five seconds. So with this, we'll wait five seconds, then query our pending invites and return that data back. So we'll give that a save,
04:25
jump back over into our browser, give it a refresh. And now you can see that we have no pending invites. We'll wait about five seconds and then we see that load in, simulating a slow query.
04:34
If we wanted to instead show some loading indication to the user whenever that state has not yet been returned back to us, then we can go ahead and jump into our invite card
04:44
for our organization users. And from the InertiaJS Vue 3 package, we can now import a deferred component. Scroll on down to where we have this information.
04:52
So that's going to be our invites table row, or we can just wrap the whole table as well. We can wrap our table row in this deferred component, just like so.
05:02
We also want to get our VIF there so that we don't show our no pending invites in that case. Then you'll see that we have a red squiggly on our deferred.
05:10
What we need to do is define which of the props we're waiting for, for this particular deferred component. In our case, that's going to be our invites data. And if we display some loader indication
05:20
by providing in a slot called fallback inside of the deferred component. So for this, we could just do something like loading.
05:28
You could also put a loading icon there as well. Let's jump back over into our browser, give it a refresh. And there you go, we see our loading indication and then we'll wait about five seconds.
05:37
That should go away and we should then see our information. So obviously you could pretty that up a little bit more than what we have here, but that gives you a gist on how exactly it works and how you can use it
05:46
inside of your application to help speed things up for your user so that they can see the page before the data, especially if you have slow queries is actually ready.
