LoginSignup
1

More than 5 years have passed since last update.

FormikでFastFieldを使うとレンダリングが減る件

Last updated at Posted at 2019-02-28

背景

FormikにはFastFieldって便利なコンポーネントがあったことを最近知った。
(何故か公式ドキュメントを数ヶ月前から眺めていたのに気づかなかった)

Formikとは

Build forms in React, without tears.

「Reactでのフォーム作成にもう悩まない!」
的なニュアンスですかね??

Reactでのフォーム作成を手伝ってくれるコンポーネントです。

FastFieldは何が便利なのか

Fieldの場合

例としてFormikのFieldに自作したコンポーネントを渡してやるとします

<Field component={TextInput} name="firstName" />

おそらくこうやって自作したコンポーネントを使うことが多いかと思います

で、その中身にはこんな感じでレンダリング判定してチューニングしてたりすることが多いかと思います
下はstateが変更した時のみレンダリングが走るように判定をさせてます

TextInput.tsx
    /**
     * コンポーネントを際描写する必要があるかを判定
     *
     * @param {ITextInputProps} nextProps
     * @param {ITextInputState} nextState
     * @returns {boolean}
     */
    public shouldComponentUpdate( nextProps: ITextInputProps, nextState: ITextInputState)
    {
        return this.state.value !== nextState.value
    }

ちなみにこういった判定しないと、Form内の別パーツの変更でレンダリング走り、
結果一カ所いじるだけでアホみたいな数のレンダリングが発生しますので
Fieldを使うならば判定した方が良いです

FastFieldの場合

<FastField component={TextInput} name="firstName" />

FastFieldに変えただけですね。
これだけshouldComponentUpdateの記述はなくともshallow比較でレンダリング判定をしてくれます。

公式にも以下のように書いてありますね。

Changes to values.firstName, errors.firstName, touched.firstName, 
or isSubmitting. This is determined by shallow comparison. Note: dotpaths are supported.

最後に

その他apiについて細かくは、公式をみてください

これで基本的にshouldComponentUpdateはわざわざ記述しなくてもよくなりますが、
公式メッセージにも書いてありますが、特定のstateでは判定自体されないので、
自分で追加したstateなどについてもレンダリング判定に含めたい、などの時は
やっぱりshouldComponentUpdateが必要になってきます

まあ使えるとこは使った方がシンプルですよ、って感じです。

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
1