LoginSignup
15
9

More than 3 years have passed since last update.

React書き方変わりすぎ問題

Last updated at Posted at 2019-07-03

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

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

要約

触ってみた。試してみた系のコードには冗長な記述が目立つので、ついカッとなって書いた。反省はしていない。
フロントエンドは日々進化が激しいので、追いかけ続けないと1年前、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」のブログ

React.Fragment の活用タイミング

Losing .bind(this) in React

15
9
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
15
9