Now, doing this, it will look more similar to other languages.
So, in other languages,
typically, one file has its own context.
In JavaScript, by default, if we are not using modules, everything is global.
And you may have conflicts between several files using the same variable names for
example, not when we are in modules.
Make sense?
So, now that means that now we can go here and import for
from Services/store.js we need to express how do we wanna import that and
because we use default export I can just create,
If I like this By the way you can use semicolon or not it's up to you,
because I'm all right I'm used to your semi colons on JavaScript, but
you know that today's mostly if you're not going to bundle this.
Because when you bundle JavaScript and
you compress the JavaScript not using semicolons can lead to problems.
But if you're going to ship your JavaScript as it is.
I prefer to still use semicolons on this language.
There are other languages such as Kotlin or
Swift where you have semicolons optional as well.
But I am on those languages.
I don't use them, okay.
So now that we have important,
those that means that we can use them and how I'm going to use that.
For example, this store, I want the store to be global.
I wanna have one store per app, so one store for the whole app, right?
So it's right now global?
No, it's not really a global option right now.
How can we because it's a module, and because it's a module,
it's not really a global variable.
So something one pattern I'm not saying it's the best pattern, or
the only pattern.
One pattern is to put talk to the window object here,
but typically only for some special situations.
So we are breaking the module for one second.
And we can create for example, an object with a name app, or any other name.
Okay, but I work or my app or from the master app wherever name you want to use.
And then over that object you can define for
example, the store mean I don't need to do this in this way.
I can use just the JSON Syntax if you want, but
just to show you that we can create an object and then later,
hook into that object different ideas or methods or functions.
Now, every time I access app.store anywhere,
I'm accessing that singleton, okay?
So before modules, everything was global.
But with modules,
this is one way to actually pick what you want to make global.
And it's better.
It's a good practice best practice to create an object and then hook everything
to that object instead of creating a lot of global variables that you don't
know if they're going to make conflicts with browser in the future.
Okay, well, even app, you may say, well, what happens in the future?
There is a spec that is using the app keyword for something else.
Well, you can do a prefix here, so
you can use underscore, so it's up to you, okay?
So that's the first part, okay?
So, what's next so
the next thing that we may want to do is to load the data so to call the API.
Okay, so we wanna call the API.
The problem is that if I can call the API from here I can
because I imported that so I can call fetch menu.
And then it returns a promise.
So I need to await for it.
I create an AC.
I'm going to refactor this just to hum.
So you know, and then I have the menu, okay?
So I create a constant with a menu.
But I mean DOM content loaded.
What should I do with the menu?
So it's a local function.
It's an event handler.
I mean, I could render now, my menu from here.
I can do that.
And that's one way, but it's not really modular.
If I'm when the DOM is loaded, I go fetch the data and
then render the data on the DOM.
Can I do that? Yes, I can.
But we can do better and doing better means that
maybe we want to create another service that
will manage things around in this case it can be
the order things around the menu itself okay?
Things around working with my data model and
I'm not using any specific design pattern like MVC MBBM
you can use those if you want I'm not saying no, you can use those.
So for example, in this case, I can create a new.
You will finally understand why I'm doing this in this way in a minute.
I can create a new file.
It can be order, it can be menu.
You can change these names if you want, it's up to you.
In this case, I can create, I can export
a function with a name low data for the menu.
So I mean, the menu.
If you look here, I'm not creating an object as I did before,
just to show you a different way of doing things.
So API has an option, store has an option here a menu I'm
just creating a function and exporting the function
which one is better I know is different okay.
Just pick remember I mentioned it's going to be a mix of different patterns here.
So load data will actually go and talk to the API.
To talk to the API, we need to import the API.
Having mind if you're using BS code, as I used to add the import
that in the browser, you must use the full URL/ VS Code
says I want to import from API but it doesn't say .js.
So it's not going to work.
You need to add the .js when you're using Babel or TypeScript.
Those tools will actually make it work anyway.
But not directly in the browser,
we need to add the .js when we are importing the file.
So now I can call my fetch menu.
And what do I need to do with that?
Well remember that we have the store.
Well we could talk to the store, that now we have an app.store and
say that hey we do have a new menu and that menu is what
we are receiving asynchronously from the API.
And because I have a wait, I also need to upgrade my function to an async function.
I'm just separating responsibilities.
We can do everything in the DOM content loaded.
But in this way it will look better and you will see that we
will add more functions here for different usage.
So after I've done that now instead of calling the API directly I'm going to SAS.
Say hey, maybe what we want if we want to load data and
load data is a function that is available in menu js.
In case you're wondering why this import has this syntax compare
with the other one is because API and a store were using export default.
While a load data needs curly braces because it's exporting the function,
not as default and you can export more than one.
That's why it doesn't contain curly braces API and store.
I mean, so far, it looks like pretty much the same thing.
So we have, when the page loads, we are starting app.js,
we're calling load data in menu.js,
load data is calling the API, and it's storing that in the store.
Probably you're thinking, but how do I know if the store is changing?
In terms of mean that in terms of triggering
updates in the UI, we will get there okay.
So we will see how can we detect that has changed without doing it manually, okay.
We will talk about reactivity later how can we react to the menu being changed?
Okay, we will get there but for now we are just changing methods.
Nothing more than that, okay.
Nothing really interesting.
But now, if I try this.
That's where I said.
It's here. Let me pull this out.
If I refresh now, I don't see anything, which is okay.
If I inspect, and they go to the console,
I could check what my app has.
And it has a store.
And the store has an empty cart and a menu and the menu has data.
Okay, yeah, we're not rendering this yet.
We will get there okay but that's one part that it's kind of ready okay, so
we have the data that's the first step yeah it's in memory but it's there