javascript questions
Hey, I have a few questions about Javascript:
1) what is the main difference between arrow functions and normal functions? Is there any benefits to using one over the other?
2) what do constructors such as
3) what is the difference between writing
let x = new Function()
or let x = new Map()
mean? Using the second example, is this just a different way of writing x.map(.. => {…})
?3) what is the difference between writing
Array.prototype.toString
for example over x.toString()
?
4) are there more to callback functions rather than them representing individual items? For example, item
would represent the individual items in the list below
I’d appreciate any help. Thank you in advance.16 Replies
1- arrow functions cant be hoisted, can't access the
arguments
variable and the this
doesnt change
2- it means you can create a new instance of the prototype
3- the difference is that Array.prototype.toString()
will always throw an exception, while x.toString()
will only throw when x
is null
or undefined
the correct way is Array.prototype.toString.call(<array comes here>, <arguments>
(either .call or .apply, depends)
that will do array-specific string transformations, which, in this case, it's the same as .join('')
x.toString()
will call whatever method is defined in the prototype of the value in x
and that goes down the prototype chain
4- there is A LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOT more
promises, regex, fetch/ajax, events, blob and canvas stuff and much much moreto add to 2: Function() and Map() are constructors, which will return an instance of a class when called with
new
. The second example has nothing to do with the array method .map
Thank you for the explanations. Just a few add-on questions from that:
what do you mean hoisted?
Why might you want to create a new instance of a prototype?
What exception would the .prototype one throw even if nothing is wrong?
.map
is (usually) a method in array, to loop through them and change the value in each "cell"Ah okay. And thank you jochem for the clarification
"hoisted" means that you can use it before it is declared, and the javascript language is smart enough to move the declaration before the use
for example:
you cant do that to an arrow function
arrow functions also dont have a name and are always anonymous
and i forgot to mention: arrow functions have an implicit return and dont need parenthesys around the arguments if there's only 1 argument
for example:
_=>_
is a function that, when called , returns the value in the first argument
(_
is usually used as a name of an argument you can ignore or no specific meaning)
"a new instance of a prototype" is what jochem said: an instance of a class
but classes are syntactic sugar for prototypes
instead of you doing something like this:
you do something like this:
the Array.prototype.toString
will throw an error because it will try to use an instance of Array
but it cant
so, it throws an error
actually, i was wrong...
this is an exception to the """"rule""""
it will always return an empty string
try Array.prototype.toString(123)
(or any other value)
to do what you want, you have to use Array.prototype.toString.call([123])
if you pass anything else other than an array, it returns the infamous "[object Object]"
(or the name of the prototype instance instead of object)also another thing about arrow fn vs normal ones, i believe is when u create methods in class,
using normal functionit doesn't duplicate the function for each instance of that class. all instances would have a reference to that function of the base class
using arrow functionit does create copies of the function for each instances now i read it while ago, so i would still suggest that u look it up again
normal functions arent copied because they are in the prototype
and the
this
then is changed to point to the current instance
arrow functions are always assigned to a variable, so, the value has to always be copiedApologies for the late reply everyone. Thank you for all the information, I’ll look more into all of these things
don't look into all these things
seriously, you shouldn't even think about prototypes
it's a massive headache and 50 grades above your level
not to say that you're bad at it, but, it gets super weird and super complicated and nuanced
just stick to classes
That’s fair enough. They’re probably something I’ll pick up along the way. I assume you don’t need to know most of these things to get by as a frontend dev right? Or do you?
you might, but you need a solid background in a lot of other stuff first. Worry about it later
So just stick to nailing the basics and understanding those concepts atm?
Well, build stuff with the basics, but yes
Usually whenever you mess with prototypes, you're either writing some package for others to use, or you're misusing Array.prototype or String.prototype to make them do something they were never intended to do
Alright that’s understandable
the only "acceptable" one is
Object.prototype.hasOwnProperty()
, which if required if you create a prototype-less object with Object.create(null)