初めに
- 説明下手です
- なんだその実装は的なものがあるかもしれません
- ガチ勢からの突っ込み待ってます
PureComponentは有効なのか
v15.3にてshallowな比較を行うPureComponentが追加されました。
自分のプロダクトでもさっそく使用し、ログインにかかる時間を計測してみましたが、
Component 717.5300000000007 ミリ秒
PureComponent 876.8950000000004 ミリ秒
Componentに比べ微増という結果になりました。
その他、PureComponentを使用したことによる表示に関する不具合も発生したため、
結果PureComponentの使用を諦めることにしました。
お前の実装がク〇だから速度出ないんだよ!という突っ込みもあるかと思いますが、
コーディングスキルが均一でない現場で、
確実な効果が出るか分からないものを使うのは気が引けたのでこのような判断をしました。
shouldComponentUpdateのチューニング
import deepEqual from 'fast-deep-equal'
export default class ReactComponent extends Component {
constructor(props) {
super(props);
}
shouldComponentUpdate(nextProps, nextState) {
return !deepEqual(this.props, nextProps) || !deepEqual(this.state, nextState)
}
参考:http://sssslide.com/speakerdeck.com/masashi/spawopahuomansutiyuningusitahua
これが理想でしたが、当方でこれをやったところ動かなくなる事件が多発し断念
開発の途中でチューニングコードを入れたのがまずかったので、
最初からチューニングコードありきで動くものを作る。
それ本当にReduxに乗せる必要ある?問題
Actionがdispatchされると、Storeに登録されているReducerすべての関数が実行されます。
100個Reducerが登録されていれば100個のswitch文がブン回っているわけです。
この処理は削れるなら削っておきたいです。
APIの取得結果を複数の画面で使用する場合ではReduxの仕組みは有効だと思います。
しかし、例えば1か所で1回しか使わないデータをStoreにずっと持っておいたり、
どう考えても関係ないReducerに渡ったりするのは無駄に感じます。
そこでAPIの結果をdispatchせずにactionでreturnしてしまうという実装を割とやっています。
// HogeAction
export function getData(param) {
return async dispatch => {
const result = await callAPI(param);
// dispatchしない
/*
dispatch({
type: REDUX_GET_DATA,
result
})
*/
return result
}
}
// React.Component
class HogePage extends Component {
doSomething = param => {
(async () => {
const result = await this.props.hogeActions.getData(param);
// ごにょごにょ
})()
}
}
// 略
export default connect(mapStateToProps, mapDispatchToProps)(HogePage)
まとめ
- 最初からチューニングのコードは入れておく
- PureComponentは効果があるときだけ使う
- Reduxに乗せる必要のないものは載せない