個人的メモ

背景

公式ガイドにある通り，Material-UIは

import { Button, TextField } from '@material-ui/core';

みたいなimportをしてしまうと，途端にbundleサイズが肥大化してしまいます．
そのため，babelのプラグインなどで解決しない場合は

import Button from '@material-ui/core/Button';
import TextField from '@material-ui/core/TextField';

みたいな感じで個別importしてやる必要があります．
僕はwebstormの自動importを普段使っているので，前者の方のimportが発生してしまいがちです．
毎回手で直すのもあれなんで，一発で変換してくれるpythonスクリプトを書きました．

変換スクリプト(python)

gistはここ

import re

if __name__ == '__main__':
    idx_import_words = ''
    while True:
        w = input()
        if len(w) == 0:
            break
        idx_import_words += w

    print()
    items = re.findall(r'\{.*\}', idx_import_words)[0].replace('{', '').replace('}', '').replace(' ', '').strip().split(',')
    lib_name = re.findall(r'\'.*\';', idx_import_words)[0].replace('\'', '').replace(';', '').strip()
    for item in items:
        if not item:
            continue
        print('import {} from \'{}\';'.format(item, lib_name+'/'+item))
    print('\n')

実行例

$ python3 convert.py
import {
  Button,
  Dialog,
  DialogActions,
  DialogTitle,
  FormControl,
  FormHelperText,
  TextField,
  Typography,
} from '@material-ui/core';


import Button from '@material-ui/core/Button';
import Dialog from '@material-ui/core/Dialog';
import DialogActions from '@material-ui/core/DialogActions';
import DialogTitle from '@material-ui/core/DialogTitle';
import FormControl from '@material-ui/core/FormControl';
import FormHelperText from '@material-ui/core/FormHelperText';
import TextField from '@material-ui/core/TextField';
import Typography from '@material-ui/core/Typography';

起動して該当のimport文入力してEnter押すだけです．
'@material-ui/icons'の方でも動くはずです．

終わりに

prettierみたいな感じで変換するツールを作ろうかとも思ったんですが，jsやtsの静的解析に明るくないのでpythonで簡単に書いてしまいました．

背景

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

Formikとは

Build forms in React, without tears.

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

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

https://jaredpalmer.com/formik/

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が必要になってきます

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

2週間ほど前からReactを学び始め、理解するほど増していく面白さにどハマり中です。しかし始める前は取っつきづらい印象があったのも確かでしたし、今までと全く異なる世界観に踏み込むのは勇気が要ると思うので、Reactを始める前に持っていた「なんとなく取っつきづらい」という印象を忘れないうちに言語化しておこうと思います。

※初心者プログラマーの個人の見解です。

誤解1.JSXがキモい

確かにぱっと見はキモいですよね。
でもなぜそんなキモい見た目になっているんでしょうか？

const listItem = () => {
  return (
    <li>
      リストアイテム
    </li>
  )
}

それは、この例で言うと
「処理の途中にDOM要素がある」
のではなく、この関数が
「DOMの設計図を返す関数」
だからです。

DOMの設計図とか言われても...という人はクッキー（焼くほう）の型を思い浮かべてみてください。

const BakedCookie = () => {
  return (
    <i class="fas fa-cookie"></i>
  )
}

<BakedCookie />
<BakedCookie />
<BakedCookie />
<BakedCookie />
<BakedCookie />

1.クッキーの型(設計図)を作る
2.同じ型でクッキー(実物)を作る
3.たくさんクッキーが焼ける

定義した関数名をHTMLのタグのように書くだけでクッキーがたくさん焼けました。
Reactはこのコンポーネントをツリー状に構成してページを作っていきます。
こう考えると、ページを再利用可能なコンポーネントの組み合わせで構築しようとした場合、非常に合理的で見た目も直感的だと思いませんか？

誤解2.関数型プログラミングに習熟していないと扱えない

コンポーネント(DOMの設計図)は入力によって出力が一意に決まる関数であるとか、状態を管理するためにセットで使われることが多いReduxの単方向データフローとか、Reactの思想や基盤が関数型的であるのは事実ですが、関数型プログラミングやその考え方に習熟していなくてもReactのルールに従っていればある程度関数型な設計になるのかな、と言う印象です。(良い書き方/悪い書き方をしっかり確認して遵守する必要はあります)
公式でもゴリゴリ関数的型な書き方はされていませんし、「関数型」というワードに怯える必要はあまりないと感じました。

誤解3.知らない用語が多くて異世界っぽい

propsとかstateとか知らない単語がたくさん出てきますが、特に新しい概念でもなくReactにおいてそういう名前なんだという程度の認識でOKだと思います。

Props.jsx

// propsはコンポーネントへの引数のようなもの
const CustomButton = props => {
  return (
    <button>
    {/* タグの中ではインライン式みたいな感じで使える */}
    {props.buttonText}
    </button>
  );
};

Props.jsx

// props.buttonText = "Purchase" 的なイメージ
<CustomButton buttonText="Purchase" />

State.jsx

// stateはコンポーネントのグローバル変数のようなもの
class CustomButton extends Component {
  render() {
    return (
      // setStateで入力時に文字をstateに格納している(直接代入してはいけない)
      // 入力した値をそのままvalueにせず、stateを通すことでバリデーションとかがやりやすくなる
      <input type="text" value={this.state.textVal} onChange={e => this.setState({ textVal: e.target.value })} />
    );
  }
};

要は何も難しくないよってことです。

誤解4.そもそも何のために使うのかわからない

これに関しては完璧にまとめあげられている記事があります。
というかこれを見ておおおすげえ...!となって始めたところもあります。笑
https://qiita.com/naruto/items/fdb61bc743395f8d8faf

誤解5.環境構築がめんどくさそう

npm install create-react-app
create-react-app myFirstReactApp

以上！閉廷！
この後npm startすると開発用サーバーが起動して、ソースを更新すると自動でトランスパイルしてリロードしてくれる親切設計になっています。

まとめ

React興味はあるけどなんか難しそうだしめんどくさそうだし...と思っている人に、その理由がここで挙げたようなものであればそんなことないよというのが伝われば幸いです。
ちなみに学習にはUdemyのこのコースを使っています。相手の立場に立つってこういうことなんだなあ(悟り)と違う意味で学ぶことがあるくらいオススメです(回し者ではありません)
https://www.udemy.com/react-redux/