-1

A while ago I asked this question: Javascript - Class Variables vs Class Methods - what is the difference?

It got promptly closed and misunderstood. Oh well. Now I found what the answer is.

The question is:

What is the difference between the two declarations below in JS ES6?

class C {
   doSomething = () => {}
   doSomethingElse() { }
}
Alexus
  • 942
  • 7
  • 20
  • 1
    The first is not even a standard syntax. None of ES (especially ES2015) supports it. – zerkms Jan 21 '20 at 22:55
  • @zerkms What is "the standard" syntax? – Alexus Jan 21 '20 at 22:56
  • It's not standardised (yet). It means exactly that: there is no accepted standard on how it should work. – zerkms Jan 21 '20 at 22:57
  • My only intention in asking this question was to find out. Nobody could explain back then, so I finally found out after days of struggle with my application architecture. So trying to save next person a time when they run into the same. – Alexus Jan 21 '20 at 23:00
  • I did not downvote you, I just pointed out that the first is a Stage 3 syntax proposal. – zerkms Jan 21 '20 at 23:02
  • My bad. I was hoping whoever did downvote would post a comment too. Thanks though :) – Alexus Jan 21 '20 at 23:03

1 Answers1

0

And the answer is:

Functions declared inside a class with the function keyword are added to the prototype of the object and are not copied with the spread operator {...}.

Functions declared inside a class as arrow functions, are copied over with spread operator and are present on the object level.

In case you are using Redux, and classes inside the state, write your classes with the arrow functions.

class C {
  doSomethingFunc() {
      console.log("Name is name")
  }

  doSomethingVar= () => {
     console.log("Last name is")
  }
}

const originalInstance = new C();
const newInstance = {...originalInstance};

originalInstance.doSomethingFunc() 
originalInstance.doSomethingVar() 
newInstance.doSomethingVar() 
newInstance.doSomethingFunc() // ERROR: prototypal functions are not copied with spread operator.
Alexus
  • 942
  • 7
  • 20
  • Your conclusion is wrong. If you use class instances inside the state, *don't use spread syntax* on them. – Bergi Jan 21 '20 at 23:38
  • @Bergi I don't advocate for such an approach, but that exposes the difference between the two syntaxes. Ideally, I would love to leave classes behind, but our system has a lot legacy stuff that can't be rewritten at the moment. – Alexus Jan 22 '20 at 00:28
  • If you just want to expose the difference, calling `instance.hasOwnProperty("doSomething")` would be enough. Or running `Object.keys(instance)`. Or more importantly, comparing `instance1.doSomething === instance2.doSomething`. – Bergi Jan 22 '20 at 00:31
  • I just need to create a completely new object and return that instead but retain the state... now that I am describing it to you, I realize how horrible this sounds. But none the less. We must move through this iteration with legacy wrapping... :( – Alexus Jan 22 '20 at 00:37
  • If the state of your instance doesn't change, there's no reason to copy it. If your instance *does* change, it should do so by calling a method on it, which returns a new immutable instance with the new state. – Bergi Jan 22 '20 at 00:39
  • Right, this would have been the ideal. Currently the way this class is implemented is it just modifies the data witing itself. – Alexus Jan 22 '20 at 00:43