I think it was in menu, we defined a function using the keyword function.
And then in router we're using arrow functions.
I know 90%- >> What
will- >> Yeah.
>> So why I'm using function here and not here, I mean,
the main difference here is that this is an object with methods.
This is not an object, which means that if I wanna convert this into an,
in fact I need to create a variable or a constant and export that, which is okay.
This is more than React, hey, something like this, and also not equals.
And maybe I don't need the name, okay?
So this case as I mentioned I'm doing several
design patterns at the same time, like that.
I'm not recommending one or the other, right?
>> I was just more curious about like I know arrow functions as binding
a little bit differently than the keyboard.
>> Yeah. >> And
if there's any instance where maybe it's safer to do.
>> The binding difference has to do with the lease option.
>> Yeah.
>> In this case, because I'm not in an object,
it's not going to make a difference.
The problem is that when you're in an object like in this case,
using arrow functions, or the function keyword will change,
let's say the security of the this object within that function.
From the outside, for example, if I take the init,
I should be able to say init.bind, and then I can bind you and you this.
If it's a narrow function, it's not gonna work.
But if it's a function with a keyword, it will work, and I can change you the, this,
I can change you the context, okay?
That's the difference.
For this particular situation, it's not gonna make any lot of differences, okay?
Do we have any other question in the chat, I think.
>> The menu is not modular as it is right now because it uses
app as a dependency is this because of closure?
>> In this case, well, the menu if you look at menu, menu is not using,
are you talking about this app?
Okay, I get the question now.
In this case, yeah, that's correct.
How to solve the problem?
An abstraction layer.
And again, as I mentioned before, I don't wanna add too many abstraction layers at
once, because sometimes you don't get what's the abstraction layer and
what's the API or what's the technique.
But in this case the way to solve that is to like with different design patterns,
such as a factory or an abstract factory.
And then you are an abstraction layer, so
then low data doesn't need to call app store.
It can, one way to solve the problem is
through events, callbacks, DOM events.
It can also instead of doing this, it can just return the data.
So then we pass the responsibility of storing
these in the store back, and yeah, that's true.
But again, one of the [SOUND] I don't wanna say problem but
one of the characteristics of Vanilla JS is that you're in charge.
So you can make a lot of decisions here.
And yeah, if we get 10 persons to look at that code,
we will probably receive 30 different opinions, not 10,
30, on how to do this, okay?
Which is okay, and that's why I mentioned, I already warned you, that we will mix
a lot of techniques here at once because I don't wanna push you into one way, okay?
Just pick the way that you prefer.
Okay, so one more thing init that we should do is,
when we are initializing the app is to check the initial URL, why is that?
Because maybe the user is loading the app directly in /cart.
So maybe we don't wanna start always with the homescreen.
Remember that we are a single page application.
Now, even if it's the same index HTML,
maybe the user is directly because the user has has copy and
pasted the URL, or someone send you a text with a URL and it's a deep link.
And to do deep linking into a single-page application means that we
should start here, checking the current path name of the location,
that's the current URL, and asking the router to go to that URL.
So based on the current URL, it will load the homepage,
the order menu, or other sections, okay?
Make sense?
Again, this is not still doing anything in the DOM,
and that's the next step.
So the next step is you actually do something, where?
In Go, so we are going to write a lot of code here now.
And again, the code that I'm going to write is actually not reusable for
other apps.
Because I wanna go step by step, and then you can add abstraction layers,
you can create your own menu framework.
So then you can create the router that is multi-solution, multi-app.
Or you can use a library, there are a lot of mini libraries that
are solving this with just maybe 1K of JavaScript.
Instead of using a big framework, you can just take a library, just for this part.
So one of the things that we will check is that we wanna add to history.
So that's the second argument.
If we wanna add to history, we need to add to history.
And for that, we're going to use push state.
And you can see here that I was online,
that the second argument is called unused, okay?
So anyway, you can pass an empty string, or null, or anything will work.
And the first one is data.
That says any, by the way, that's kind of a TypeScript annotation, okay?
Any means anything.
So we can pass, for example, an object that will include the route inside.
And later, we can add more metadata.
For example, we can pass on a scroll position.
So then when we go back, we know where the scroll,
we can make a lot of interesting things here.
But right now we can pass just the route, and
passing this as an object, so it's more future proof.
I mean, I got both shots the route directly,
I only had object wrapping the route.
But yeah, maybe in the future we will have more things.
An empty string or no for unused.
And then the URL that is in this case the route.