React: Calling other static methods inside getDerivedStateFromProps

[jalkoby]

After playing with a new way of sync props & state I've found a strange behaviour of getDerivedStateFromProps. If you want to call another static method you need to use a component's name rather this(which is undefined). According to MDN calling a static methods from another static method by this is fine. Maybe it's an expected flow, so I guess a note in docs will be fine. If not here's a playground to reproduce this case https://codesandbox.io/s/23w6x19v1p

[gaearon]

In JS this depends on the caller.

Defining static methods doesn’t give them this automatically. It’s just that if you call

MyClass.staticMethod()

then you’ll get MyClass as this because that’s how it got called.

However if you call

var staticMethod = MyClass.staticMethod;
staticMethod()

Then you won’t get this there.

We decided to do an equivalent if the second way of calling in React. Primarily because it’s the only static lifecycle method so supporting this in it will confuse a lot of people.

But there is also another reason. If you want to share call methods from it you usually want them to be private. In that case it would be better to completely extract them from the class anyway. Move them into functions and call those functions from your class.

[jalkoby]

ok, I got - getDerivedStateFromProps is not a static method rather a "pure" function. In my case - will just autobind getDerivedStateFromProps fix this

[crashuniverse]

To continue the discussion, what I did in my case is to not use this or bind approaches, instead I defined a pure function doSomething outside class, and called doSomething() in static getDerivedStateFromProps. This keeps getDerivedStateFromProps pure.

[hohmanjl]

The OP is correct. Per JavaScript specification we can reference static methods from another static method using this. Precisely because it is less maintainable to maintain a reference to the named class. This is the same reason we want to use this.constructor.method, instead of MyClass.method.

Saying "we won't build it to specification because it will confuse people" is the wrong approach.

The other reason mentioned may be correct in some cases, but from an encapsulation standpoint makes zero sense. You are building methods to calculate component-specific state, those methods do not belong in "standalone functions". You are writing functionality that directly relates to your component state, which is directly tied to your component. It makes no sense to segregate component-specific state logic into external functions.

The correct way to build this is to adhere to specification and allow reference to static members of the class. To do so otherwise is a defect (unless there are implementation specific problems to this approach--ie React internals). It is unexpected (and wrong) that a static member does not have access to other static members of the same class.