※最終更新日： 2019/08/16 stateHookの例を追加。ライフサイクルのお話追加
30代半ばの中堅エンジニアのメモ代わりの書きなぐりです。
要約
触ってみた。試してみた系のコードには冗長な記述が目立つので、ついカッとなって書いた。反省はしていない。
フロントエンドは日々進化が激しいので、追いかけ続けないと１年前、2年前の書き方をして、「書き方が老害」になりかねません。
そのため、新しく勉強した結果と、備忘録も兼ねてこちらに書き残します。
前提（思想）
2行でも3行でも省けるコードは省くべきであるし、自分で書くコードは一番信用してはいけない。
しかしながら、どうしてもコードを書かなければいけない場合は前述の通り、本質とは関係のないノイズを減らし、バグの介在余地を少なくするべきである。
constructorは基本的に書かない
もちろん絶対ではないですが、省略記法が使える場合は使いましょう。可読性も上がります。
例えば以下のようにstateを設定する場合、constructorを呼び出す必要はなくなりました。
export default Sample extends Component {
constructor(props) {
super(props)
this.state = {
foo: "baa",
}
}
...
render() {
const { foo } = this.state
return (
...
)
}
}
export default Sample extends Component {
state = {
foo: "baa",
}
...
render() {
const { foo } = this.state
return (
...
)
}
}
さらに、React16.8以降はuseStateというステートフックが使用できるようになりましたので、今まで以上にコードの本質だけを書くことに専念できるようになりました。
import React, { useState } from 'react'
export default const Sample = () => {
const [state, setState] = useState(0)
return (
...
)
}
原則的にclass設計しない
上記のuseStateとも関連しますが、constで作成してもpropsも渡せますし、状態管理も可能になりました。importも普通にできます。
classを使用したコンポーネントを作成するのは、shouldComponentUpdateなどのライフサイクルを利用するときだけで十分な気がします。
※サンプルでは直接送ってますが、propsをchildrenに直接渡すのはアンチパターンです（必要なものだけ渡すのが普通）
export default Sample extends Component {
constructor(props) {
super(props)
}
render() {
return(
<View style={styles.container}>
<Foo {...this.props} />
</View>
)
}
}
export const Sample = props => {
return(
<View style={styles.container}>
<Foo {...props} />
</View>
)
}
export default Sample
古いライフサイクルを使う
サンプルコードに以下3つのライフサイクルが存在する場合、
そのコードは賞味期限が過ぎています。食べられません。
特に個人ブログやstackOverFlowなどでcomponentWillReceivePropsが多く見受けられます。
componentWillMount
componentWillReceiveProps
componentWillUpdate
bind祭
thisthis見にくいthis
constructor(props) {
super(props)
this.foo = this.foo.bind(this)
this.baa = this.baa.bind(this)
...
}
foo() {
// do something
}
foo = () => {
// do something
}
render() {
return(<Foo onPress={this.foo}/>)
}
divdivしてる
Reactはルール上、一つのコンポーネントをreturnすることを想定しています。だからと言ってとりあえずでdiv指定するのは愚の骨頂です。
昔からreact触ってる、なんて方に多い書き方です。コードレビューでこてんぱんにしましょう。
無駄なHTMLタグ増やすことで可読性が著しく落ちますし、メンテしずらいです。
render() {
return(
<div>
<Foo/>
<Baa/>
<div>
<Text>aaaaa</Text>
</div>
</div>
)
}
import React, { Fragment } from 'react'
render() {
return(
<Fragment>
<Foo/>
<Baa/>
<Fragment>
<Text>aaaaa</Text>
</Fragment>
</Fragment>
)
}
まとめ
敵「きれいな実装より動く実装が優先だろ？」
敵「そんな時間無いです」
敵「仕様変更や」
現場には上記のような敵がいっぱいいますので、保守コストやリファクタコストを考えると、プロジェクトが始まる前にコーディング規約とかに入れておいたほうが良いですね。
途中からの参画の場合は、耐えしのぐか暴れるかの二択です。
私としては是非とも後者をおすすめします。
責任は負いませんが。