Check out a free preview of the full Vanilla JS: You Might Not Need a Framework course:
The "Router Q&A" 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 answers student questions regarding using a function for loadData and not Router, how arrow functions handle bindings, and if the menu isn't modular because it uses app as a dependency.

Get Unlimited Access Now

Transcript from the "Router Q&A" Lesson

>> 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% [INAUDIBLE]
>> Yeah, so why are we using function here and not here? I mean, the main difference here that this is an object with methods.

[00:00:21] This is not an object, which means that if I wanna convert this into an x in function, 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?

[00:00:43] So, in this case as I mentioned, I'm doing several design patterns at the same time, I'm not recommending one or the other, right?
>> I was just more curious about like I know arrow functions does binding a little bit differently than the keyword,
>> Yeah.
>> And if there's any instance where maybe it's safer to just,

>> The binding difference has to do with the disk option.
>> Yeah.
>> In this case, because I'm not in an object, it is not going to make any difference. The problem is that when you are in an object, like in this case, using arrow functions or the function keyword will change, let's say the security of this object within that function.

[00:01:29] From the outside, for example, if I take the init, I should be able to say init.bind, and then I can bind you a new this. If it's an arrow 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.

[00:01:52] 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, if you look at menu.

[00:02:18] Menu is not using, you're talking about this App, okay, I get the question now. In this case here, that's correct, how to solve the problem, abstraction layer. And again, as I mentioned before, I don't wanna add too many abstraction plays at once because sometimes you don't get what's the abstraction layer and what's the API or what's the technique.

[00:02:40] But in this case the way to solve that is to, with different design patterns such as a factory or an abstract factory and then you have 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.

[00:03:04] It can also, instead of doing this, it can just return the data so then we pass the responsibility of storing this in the store back. And yeah, that's true, but again, one of the, I don't wanna say problem, but one of the characteristics of Vanilla JS is that you're in charge.

[00:03:28] 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, it 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?

[00:03:55] Just pick the way that you prefer.