React書き方変わりすぎ問題

※最終更新日： 2019/08/16 stateHookの例を追加。ライフサイクルのお話追加

30代半ばの中堅エンジニアのメモ代わりの書きなぐりです。

# 要約
触ってみた。試してみた系のコードには冗長な記述が目立つので、ついカッとなって書いた。反省はしていない。
フロントエンドは日々進化が激しいので、追いかけ続けないと１年前、2年前の書き方をして、「書き方が老害」になりかねません。
そのため、新しく勉強した結果と、備忘録も兼ねてこちらに書き残します。

## 前提（思想）
2行でも3行でも省けるコードは省くべきであるし、自分で書くコードは一番信用してはいけない。

しかしながら、どうしてもコードを書かなければいけない場合は前述の通り、本質とは関係のないノイズを減らし、バグの介在余地を少なくするべきである。

### constructorは基本的に書かない
もちろん絶対ではないですが、省略記法が使える場合は使いましょう。可読性も上がります。
例えば以下のようにstateを設定する場合、constructorを呼び出す必要はなくなりました。

```従来の書き方.js
export default Sample extends Component {
  constructor(props) {
    super(props)
    this.state = {
      foo: "baa",
    }
  }
  ...
  render() {
    const { foo } = this.state
    return (
      ...
    )
  }
}
```

```state設定.js
export default Sample extends Component {
  state = {
    foo: "baa",
  }
  ...
  render() {
    const { foo } = this.state
    return (
      ...
    )
  }
}
```

さらに、React16.8以降は`useState`というステートフックが使用できるようになりましたので、今まで以上にコードの本質だけを書くことに専念できるようになりました。

```useStateを使う.js
import React, { useState } from 'react'

export default const Sample = () => {
  const [state, setState] = useState(0)
  return (
    ...
  )
}

```

### 原則的にclass設計しない
上記のuseStateとも関連しますが、constで作成してもpropsも渡せますし、状態管理も可能になりました。importも普通にできます。
classを使用したコンポーネントを作成するのは、shouldComponentUpdateなどのライフサイクルを利用するときだけで十分な気がします。

※サンプルでは直接送ってますが、propsをchildrenに直接渡すのはアンチパターンです（必要なものだけ渡すのが普通）

```従来の書き方.js
export default Sample extends Component {
  constructor(props) {
    super(props)
  }
  render() {
    return(
      <View style={styles.container}>
        <Foo {...this.props} />
      </View>
    )
  }
}
```

```constで書ける.js
export const Sample = props => {
  return(
    <View style={styles.container}>
      <Foo {...props} />
    </View>
  )
}

export default Sample
```

### 古いライフサイクルを使う

サンプルコードに以下3つのライフサイクルが存在する場合、
そのコードは賞味期限が過ぎています。食べられません。
特に個人ブログやstackOverFlowなどで`componentWillReceiveProps`が多く見受けられます。


```地獄へ落ちろ.js
componentWillMount
componentWillReceiveProps
componentWillUpdate
```

### bind祭
thisthis見にくいthis

```よく見かける実装.js
constructor(props) {
  super(props)
  this.foo = this.foo.bind(this)
  this.baa = this.baa.bind(this)
  ...
}
foo() {
  // do something
}

```

```アロー関数でbindする.js
foo = () => {
  // do something
}

render() {
  return(<Foo onPress={this.foo}/>)
}
```
### divdivしてる
Reactはルール上、一つのコンポーネントをreturnすることを想定しています。だからと言ってとりあえずでdiv指定するのは愚の骨頂です。
昔からreact触ってる、なんて方に多い書き方です。コードレビューでこてんぱんにしましょう。
無駄なHTMLタグ増やすことで可読性が著しく落ちますし、メンテしずらいです。

```よく見かける実装.js
render() {
  return(
    <div>
      <Foo/>
      <Baa/>
      <div>
        <Text>aaaaa</Text>
      </div>
    </div>
  )
}

```

```公式推奨.js
import React, { Fragment } from 'react'
render() {
  return(
    <Fragment>
      <Foo/>
      <Baa/>
      <Fragment>
        <Text>aaaaa</Text>
      </Fragment>
    </Fragment>
  )
}

```


## まとめ
敵「きれいな実装より動く実装が優先だろ？」
敵「そんな時間無いです」
敵「仕様変更や」

現場には上記のような敵がいっぱいいますので、保守コストやリファクタコストを考えると、プロジェクトが始まる前にコーディング規約とかに入れておいたほうが良いですね。
途中からの参画の場合は、耐えしのぐか暴れるかの二択です。
私としては是非とも後者をおすすめします。
責任は負いませんが。

## 参考文献
[なぜsuper(props) を書くの? - React界のカリスマ「Dan Abramov」のブログ](https://qiita.com/hand-dot/items/61a4b808f110b12e4281)

[React.Fragment の活用タイミング](https://qiita.com/bayarea-techblog/items/3c43c0fb545b570ef9a0)

[Losing .bind(this) in React](https://medium.com/@nikolalsvk/loosing-bind-this-in-react-8637ebf372cf)