So now that we know the difference between sharing stateful information into the direct state of our page and sharing it globally for the view instance,

there's a third option that we can introduce here as well, and that's a full-blown global. So let's take the same approach as we did before. Let's create an instance of a full-blown global and see where exactly it propagates.

As you probably expect, it's gonna be everywhere. To start out with though, we need to introduce a new start file. And if you recall, start files are registered during the boot process of our application. Now, the reason that we want it

to be during the boot process is that it's going to be shared across all view instances that we create. So whenever we introduce it during the boot process, it can register it appropriately

and make use of it throughout all of our instances. First, we need to create a new file within our start directory. And to do that, we can use the ACLI. So let's go and stop our server, clear a terminal out,

and let's do node ace list to find our options. We're gonna be taking a look within the make section here. And the particular one that we're looking for this time is make preload.

This will create a new preload file inside of our start directory. The reason it's called preload is because it's a file that's preloaded during the boot process of our application.

So it's a great place to register information for our application. So we'll do node ace make preload, and let's call this globals

because this is where we'll define our EdgeJS globals. Hit enter on that. It's gonna ask, do you wanna register the preload file in the .adonisrcts file? And so that it's actually registered

during the boot of our application, we will want to hit yes for that. And now it's created our global file and altered our .adonisrc.ts file, adding our global into our application's preloads.

So if we open our text editor back up, the first thing we'll see is that we do indeed have our globals within our start directory. We'll take a look at that here in a second. First though, let's inspect our .adonisrc.ts file.

So we left off within the provider section of this file. If we scroll down a little bit more, we're gonna see preloads. And particularly, we're gonna see the start globals that it added within here.

If I give this a save, it's gonna break those down into separate lines, thanks to the linter's auto formatting that we set up within our Visual Studio Code lesson. We'll see that within the preloads, we have our start routes.

So this is where it's registering our routes file. We have our start kernel. That's where that's being registered as well. We haven't quite taken a look at that yet, but we will hear in a little bit.

And there's our new globals file right there. Just as we described, there's a comment here noting that this is a list of modules imported before the start of our application.

If we go ahead and dive into our new global file, it's just gonna be an empty file. So let's start out by typing out edge and hitting tab to auto import that from edge.js.

With edge, we have the option to create a global. This is a simple method. It accepts in a name as the first argument and a value as the second.

And the value can really be anything that we want. It could be a string, or as I show it in the example here, it could also be a function, could be an array, so on and so forth. We'll stick with the naming example

that we've been going with so far. This one will be our global example, and our value will just be a simple string, global info. If we give this a save,

let's add this to all of the inspect calls that we have so far. So we have our state example, share example, and now our global example here as well. I'll give this a copy once more,

and we'll wanna dive into our navigation and overwrite this one, and dive into our card and overwrite that one there as well. Cool, now that we have that in place, let's dive back into our terminal

and start our server backup. So npm run dev. Once that's booted, we can dive back into our browser and take a look at what we have. So here's our global example, and we can see that we have global info

within our navigation inspect, and it's also within our page inspect. And if we scroll down to our components inspect, it's there as well. Remember, our state example is there

only because we're explicitly passing it in to that component. So if we dive back to our homepage, we're passing it into that component right here. If we were to take that away, our state example will go back to undefined

within our components. So our global example is working almost identical to our share example. As we said though, the main difference between the two

is that our global is shared across all view instances, whereas share is specific to the view instance for this particular request,

meaning share is great for user-specific information, and global is great for application-specific information. In addition to that, if we go ahead and hide our browser back away,

within our movies controller here, if we were to even attempt to try and use global within a particular view instance, so view. You'll see that global just doesn't exist within this context

because we're already within a specific view instance. So if you do happen to get the two confused, know that EdgeJS has your back and will only let you share on instances

and will only let you set global on EdgeJS itself. Whenever we set globals, EdgeJS will use that global anytime that it creates a new view instance and that property will be automatically shared

directly onto that instance. And globals can really be whatever you need it to be as well. You can even pass your model into here as well. So if we wanted to, we could switch this global example to movie

and provide our movie model in here. We'll need to import that just like so. Give that a save. I have an unsafe change within our movies controller. Yep, definitely wanna get rid of that.

Let's go ahead and get rid of our view shares here as well. Let's get our state information back to just movies. And while we're at it, let's go ahead and get rid of our inspecs. So we'll get rid of inspect there within our navigation

and within our card component as well. Now, since we're sharing our movie model as an EdgeJS global called movie, what we could do, not necessarily saying that you should do it,

but what you could do is we could comment out our movie.all call, get rid of that from the state for our page. And inside of our page up at the top,

we could do @let movies equals await movie.all. Give that a save, jump into our browser and look at that. Everything's still working a-okay

because we have movie accessible now anywhere within EdgeJS where we can call all and we can do whatever we need with that particular model directly inside of EdgeJS

since it supports JavaScript expressions, including but not limited to fetching information for our page. Cool. So I don't wanna leave it like that. So let's go ahead and undo what we just did right there.

Let's get rid of that global just like so. We'll go ahead and go back a couple of steps just so that we leave something in this file as an example, even though we're not using it anywhere on our page.

And then let's dive back into our movies controller and bring our movies back from there. Cool. Let's verify that we left everything in a working state. Jump back into our browser, give it a refresh.

Sure enough, there's our movies and dive into them still. That's working a-okay. We can dive into another one. Oh, that was the same one. There we go. Now we can dive into another one. There we go. Okay, cool. So everything seems to be working a-okay.

We're leaving it in a working state and we're ready to move on.