Hacker News Reader

Comment by DonHopkins | Hacker News Reader

Very cool, thanks for publishing this! I'm learning some interesting things by reading the code.

I'm curious about the three different coding styles used to define functions in domApi.js, if they have different behaviors, are meant to imply different meanings, or if they are just different styles for the same thing:

https://github.com/mbasso/asm-dom/blob/master/src/js/domApi....

  'setAttribute'(nodePtr, attr, value) {

  'parentNode': nodePtr => (

  'setTextContent': (nodePtr, text) => {

Why the single quotes around function names? Why are some normal functions and others fat arrow functions? Why omit the parens around the param of a one parameter fat arrow function -- does that define a get accessor?

View on HN

> Why the single quotes around function names?

Syntactically the same as not having them, aside from the fiddly details of string vs property name access to an object.

  thisObject = {
    usualPropertyName: value1,
    'property name with spaces': value2
  }

  thisObject.usualPropertyName
  thisObject['usualPropertyName'] // this works too
  thisObject['property name with spaces'] // you can't use the dot access style with this property name

> Why are some normal functions and others fat arrow functions?

Fat arrow functions bind "this" to whatever the surrounding context is, and if the only statement is a single object or value, it implicitly returns that.

That is to say, this:

   whatever => value

is syntactically the same as this:

   whatever => (
     value
   )

is syntactically the same as this:

  whatever => {
    return value
  }

> Why omit the parens around the param of a one parameter fat arrow function -- does that define a get accessor?

If there's only a single argument, you don't need the parentheses. This is meant mostly for the convenience of things like this:

  someArray.map(item => item.propertyName)

> Fat arrow functions bind "this" to whatever the surrounding context is

They don't actually bind `this` at all, there is a slot on the function object ([[ThisMode]] in the spec) which describes how to resolve `this` references for the function's body, for arrow function the mode is "lexical" and they simply grab the this reference from their lexical environment[0] as if it were any other non-local variable.

In fact, lexical resolution is the default, so what happens is during [[Call]][1] arrow functions will simply skip all the hard work in OrdinaryCallBindThis[2] by early-returning while the other two types (strict and global) have to resolve their thisValue then bind their local environment.

[0] https://www.ecma-international.org/ecma-262/6.0/#sec-lexical...

[1] https://www.ecma-international.org/ecma-262/6.0/#sec-ecmascr...

[2] https://www.ecma-international.org/ecma-262/6.0/#sec-ordinar...

Thank you for your answer. I just want to add a little thing to the first point.

> Why the single quotes around function names?

In this case I use quotes to prevent name mangling. I have to be sure that the uglify plugin in webpack does not mangle the names of that object because I'll call it from C++ in this way:

window['asmDomHelpers']['domApi']['createComment'](...)

Also, for the same reason, here I'm using this notation instead of this one:

window.asmDomHelpers.domApi.createComment(...)

to let know the closure compiler that I don't want name mangling.

Without quotes these two different compile processes might cause some problems

Reply on news.ycombinator.com