What's the difference between named functions and arrow functions in JavaScript?
jrsinclair.com
jrsinclair.com
Anyway, I'm more interested in how this site is being published. I'm on iOS and in vertical format words are cutoff with dashes properly for that format and when I switch to landscape other words are cut off that fit that format.
Is this some simple css attribute I missed completely?
"this" binding depending on the call site never made sense to me. Why do you think it became worse with arrow functions and Function.prototype.bind?
In case I'm not misunderstanding you. Tbh I haven't read the article so I'm only responding to your first sentence, since the CSS hyphens thing has been cleared up already.
By the way, CSS hyphens have been my most-wanted feature ever when I was working for a web design agency. So glad to see it gain traction over the years.
There are JS libraries for this, and of course they cause ugly page reflow and/or overhead.
Prime example of what should be in the CSS domain, and such a frequent problem when putting real content into design templates.
Arrow functions defined within a class are scoped and bound to the class automatically. Hence, arrow functions do not require calling the .bind in constructor, and you can happily use `this` inside arrow functions.
If you define
const o = { a: "Hello", b() { return this.a;} }
o.a()
while
const b = o.b; // not a.b ...
b();
This predates generator functions and classes (which are only syntax sugar AFAIK).
And it seems like a glaring omission giving the submission title.
I'm ashamed though if it's in there and I missed it.
The behavior is called "late binding".
I was replying with this because it happens without using the "class" keyword (or "constructor") at all.
Not sure what you mean with the class constructor thing, but that's on me. I still don't understand these properly:
> Named functions defined in classes are scoped outside of the class, meaning they are not bound to the class
> the habit some have in class constructors for "early binding" to try to avoid it.
You mean using sth like
this.a = //...
I guess I'm missing something here.
That can also be done after the class was declared? The class keyword is only syntax sugar.
Anyway, I might be missing something important here.
That's why I brought up an example using an object literal, which has the prototype
Object.prototype
const a = {};
console.log(Object.getPrototypeOf(a) === Object.prototype); // logs "true"
I love MDN for that.
https://developer.mozilla.org/en-US/docs/Learn_web_developme...
Late binding happens whether or not the function is a part of the Object's prototype chain or directly attached. JS is built so that's all mostly the same thing. That's why late binding exists. Maybe you copy a function from one prototype to another to create a new sort of prototype with a bit of "code-sharing", which is the same if you want to copy a function directly from one object to another. You want that function to work in all these cases, you don't want to redefine the function explicitly for a different kind of prototype or a different kind of object, you want to pick up what it is bound to by how it is called (thus late binding). Late binding is an ancient feature of JS that feels like a bug if you think `class` works like it does in OO languages like C++ or Java or C#. Late binding feels like a bug if you think of an Object's prototype as being a strongly formed contract and not a runtime object that itself can change at any time, or can be used as a lego brick to construct other types of objects and code-sharing beyond traditional class-based OOP "inheritance" models.
The difference between a "regular object" and thing constructed from a `class` in JS is effectively nonexistent. It's the same stuff, just a few syntax niceties. (In the old days, it was a lot harder to build a clean prototype, `class` makes it a lot cleaner. But that's all it does, it makes it cleaner to write, but under the hood it is entirely the same as it was.)
> in the constructor, using arrow functions?
The example above was the related but similar thing of doing `this.a = this.a.bind(this)` in a class constructor. It's very similar to using `this.a = () => …` arrow functions to early bind `this`. (Assigning a function to itself in a constructor with a `bind()` is also an idiom pattern that predates arrow functions and class syntax. Constructors predate class syntax, but they used to look a lot different. You can still write that form of constructor if you want, but class syntax is a lot cleaner.)
Late binding is an old feature that feels like a bug today, so a lot of people work very hard to early bind functions or only ever use arrow functions because they don't trust late binding.
Yes, I think we are on the same page. I did not want to include "legacy" prototype-based inheritance examples because I'm on a phone and didn't want to make complexity explode here.
Also I made a weird statement here:
> That can also be done after the class was declared?
That doesn't make much sense for binding "this" to the class that was declared, I wsd mixing up arrow function class properties inside the class declaration with adding prototype properties (which is exactly what one doesn't want for classes with many instances).
In the scope of the class declaration, all methods of adding methods to the prototype are awkward, I guess.
Regarding the "early-binding" using .bind or arrow functions in constructor, I see your points, and it's the subtle and hard-to-explain differences that are really annoying.
JS really requires some discipline and sticking to a pit of success, while it's still essential to know the basics.
> Late binding is an old feature that feels like a bug today, so a lot of people work very hard to early bind functions or only ever use arrow functions because they don't trust late binding
Yes, that's what I was going at, thanks for making clear the difference between arrow functions (lexical scoping) and using `bind` (arbitrarily fixed "this").
I was lately (no pun!! really coincidence, it just wasn't only recently) using late binding with object literals in tests with Jest and TS and had to ignore TS there, it's pretty much the major reason I'm commenting here. It was convenient and succinct for a mock object implementing an interface otherwise used by class instances to use late binding.
There is another reason: If you give a name to a function expression, the function can directly recurse on itself without the use of combinators. For example:
const factorial = function fact(n) {
if (n == 0)
return 1;
else
return n * fact(n - 1);
};