Check out a free preview of the full Vanilla JS: You Might Not Need a Framework course

The "Loading Menu Data" Lesson is part of the full, Vanilla JS: You Might Not Need a Framework course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano demonstrates importing and utilizing the application's previously created Store and API modules. Calling the API to load the menu data is also covered in this segment.


Transcript from the "Loading Menu Data" Lesson

>> 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 old 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 imported those that means that we can use them and how I'm going to use them? 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 object 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 app will work Or myapp or Frontend Masters 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 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 async. 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 MVVM 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 object, store has an object here a menu I'm just creating a function and exporting the function which one is better I don't 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 VS 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 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 just. 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 chaining 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

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now