回答編集履歴
2
訂正2
answer
CHANGED
|
@@ -32,10 +32,16 @@
|
|
|
32
32
|
いえ、1つ目は、コンストラクタ関数(Ctor)内で、state プロパティを初期化していますが、
|
|
33
33
|
2つ目は、コンストラクタ関数の[[Prototype]]に定義されたオブジェクトを**分割代入**することで、stateプロパティは初期化する必要がなくなっています。
|
|
34
34
|
|
|
35
|
+
class ブロックの書き方が変わったというのもあります。
|
|
36
|
+
1つ目はプロパティを書くシンタックスシュガーが実装されておらず、関数内で state プロパティに代入する必要があった。2つ目はその制約が解消され、分割代入の恩恵により [[Prototype]] に予め定義されている state の count(プリミティブ) を参照するだけでよくなった。
|
|
37
|
+
|
|
38
|
+
|
|
35
39
|
> 1つ目のconstructor内ではthis.stateとthisが必要であるが、2つ目ではなぜthisが必要ではないのか。
|
|
36
40
|
|
|
41
|
+
constructor内に限らず、メンバ関数内では、メンバを参照するときにthisが必要です。
|
|
37
|
-
|
|
42
|
+
2つ目の方法で、render() 内部で this.state を参照するときに thisを使っています。
|
|
38
43
|
|
|
44
|
+
|
|
39
45
|
> class fields proposal これがなにを意味しているのか
|
|
40
46
|
|
|
41
47
|
class field(オブジェクトのメンバの書き方) + proposal(提案) ということで、class ブロックの書き方（シンタックスシュガー）のルールを詰めていこうという、仕様策定されている人たちのご都合を意味しています。
|
1
訂正
answer
CHANGED
|
@@ -34,8 +34,7 @@
|
|
|
34
34
|
|
|
35
35
|
> 1つ目のconstructor内ではthis.stateとthisが必要であるが、2つ目ではなぜthisが必要ではないのか。
|
|
36
36
|
|
|
37
|
-
1つ目は関数内で state プロパティに代入するため。
|
|
38
|
-
2つ目は分割代入の恩恵により [[Prototype]] に予め定義されている state の count(プリミティブ) を参照するだけでよくなっているため
|
|
37
|
+
1つ目はプロパティを書くシンタックスシュガーが実装されておらず、関数内で state プロパティに代入する必要があったため。2つ目はその制約が解消され、分割代入の恩恵により [[Prototype]] に予め定義されている state の count(プリミティブ) を参照するだけでよくなっているため
|
|
39
38
|
|
|
40
39
|
> class fields proposal これがなにを意味しているのか
|
|
41
40
|
|