宣言的

• 参照透過性を極力保つ = 副作用を適切に扱う
  • 関数内部で外部の値を書き換えない → 純粋関数
  • 同じ引数なら同じ返値 → テスト容易性
  • 評価順序に依存しない → 遅延評価可能性
• 純粋関数は関数合成でき、高階関数になれる
  • JavaScriptが元々持っている性質
  • 無名関数
  • カリー化 → map/filter/reducer

関数型パラダイム

• Functional Reactive Programmingはあえて採用していない様子
  • 時系列的なイベントハンドリングがない
  • 学習コストを下げるため
  • Flux/Reduxでカバーできている
• 副作用は多数残る
  • DOM/API/console.log/ファイル/プロトタイプチェーン

コンポーネント指向

Passing Props to a Component↗

• 親子関係
• 親から子への一方向性
• propsはイミュータブル（書き換え不可）
• 関数コンポーネント

💡かつてはクラスコンポーネントが存在していた
💡今後は関数コンポーネントを使う

関数コンポーネントの例

const NumberList = (props) => {
  const numbers = props.numbers
  const listItems = numbers.map((number) => <li>{number}</li>)
  return (
    <ul>{listItems}</ul>
  )
}

const numbers = [1, 2, 3, 4, 5]
const root = ReactDOM.createRoot(document.getElementById('root'))
root.render(<NumberList numbers={numbers} />)

JSX

• 独自のDSL（埋め込み言語）
  • テンプレートエンジンではない
• HTMLっぽくJavaScriptを記述できる
• 変更があるとrender()でVirtual DOMを効率的に更新
• ReactがReal DOMを一致させる

💡元々ReactではJSXで書くことが一般的だった

JSXの例

const Example = () => {
  const [count, setCount] = useState(0)
  return (
    <div>
    <p>You clicked {count} times</p>
    <button onClick={() => setCount(count+1)}>
      Click me
    </button>
    </div>
  )
}

• HTMLっぽいものがJavaScriptに埋め込まれている
  • count変数が参照されており、値が更新されると再描画される
  • クリック時の処理が無名関数で書かれている

説明用コンポーネントの構成

• 単一のJSX実装の場合
  • 本来無関係なコンポーネントも含めて密結合になる
  • 一部の修正が他のコンポーネントにも影響する

const Page = (
  <>
    <Collapse><p>...</p></Collapse>
    <Collapse><p>...</p></Collapse>
    <Collapse><p>...</p></Collapse>
    <Modal>
      <Modal.Header>
        <strong>Title</strong>
      </Modal.Header>
      <Modal.Body>
        <h4>Some messages</h4>
      </Modal.Body>
      <Modal.Footer>
        <Button>...</Button>
        <Button>...</Button>
      </Modal.Footer>
    </Modal>
  </>
)

コンポーネントを小さくする

const ModalHeader = () => (
  <Modal.Header>
  <strong>Title</strong>
  </Modal.Header>
)
const ModalBody = () => (
  <Modal.Body>
    <h4>Some messages</h4>
  </Modal.Body>
)

コンポーネントを階層化

const ButtonCancel = () => <Button>...</Button>
const ButtonConfirm = () => <Button>...</Button>

const ModalFooter = () => (
  <Modal.Footer>
    <ButtonCancel />
    <ButtonConfirm />
  </Modal.Footer>
)

小さなコンポーネントで構成する

const ConfirmationModal = () => (
  <Modal>
    <ModalHeader />
    <ModalBody />
    <ModalFooter />
  </Modal>
)

ページ構成も小さく保つ

ページ構成も小さく保つ

const CollapseStep1 = () => (
  <Collapse><p>...</p></Collapse>
)
const CollapseStep2 = () => (
  <Collapse><p>...</p></Collapse>
)
const CollapseStep3 = () => (
  <Collapse><p>...</p></Collapse>
)

const Page = (
  <>
    <CollapseStep1 />
    <CollapseStep2 />
    <CollapseStep3 />
    <ConfirmationModal />
  </>
)

JavaScriptで安全に状態を管理するためにどうするか？

1. グローバル変数は使う
2. 変数の直接的な変更を禁止
3. 状態を変更するための純粋関数を通す
4. 状態が変更された場合に呼び出し元に通知

Reduxでの状態管理の基本形

three-principles↗

Reduxでの状態管理

図引用:redux.js.org↗

Reduxでの状態管理

useState

const Example = () => {
  const [count, setCount] = useState(0)
  return (
    <div>
    <p>You clicked {count} times</p>
    <button onClick={() => setCount(count+1)}>
      Click me
    </button>
    </div>
  )
}

💡useStateだけで状態管理できる
💡ReduxでDispatch/Action/Reducer/Storeを用意して、this.state.countを使わなくてよくなった

useState

複数の状態を単一のStateで管理するときは、その方法が適切かを考える

• オブジェクトで構造化した場合
  • 取り得る状態の組み合わせを制限できる
• 独立した変数とした場合
  • 非同期に更新されるため、すべての状態の組み合わせを許容する設計にする必要がある

オブジェクトで構造化した場合

• 取り得る状態を単一のSetterで管理できる
  • 整合性の担保はアプリケーションの責務
  • 状態の組み合わせが不正にならないように設計する

const [signInFlow, setSignInFlow] = useState({
    isAuthenticated: false,
    isLocked: false,
    isTemporaryPassword: false,
    isError: false
})

独立した変数とした場合

• 個別のSetterで独立に更新できる
• 状態の組み合わせがすべて起こりえるため、許容した設計とする

const [isAuthenticated, setIsAuthenticated] = useState(false)
const [isLocked, setIsLocked] = useState(false)
const [isTemporaryPassword, setIsTemporaryPassword] = useState(false)
const [isError, setIsError] = useState(false)

setStateの評価コスト

• setStateを呼び出した時点ではすぐに値は更新されない
  • 次のレンダリングサイクルで更新される
• setした値が前回と同じであっても再評価されるため計算コストはかかる
• どこでも使えてシンプルな回避策

// 値が変化しない場合は呼び出さない
if (currentState !== nextState) {
  setCurrentState(nextState)
}

useEffect

useEffect(() => {
  document.title = `You clicked ${count} times`
})

• 副作用をReactiveに反映できる

useEffect

useEffect(() => {
  ChatAPI.subscribeFriendsStatus()
  return () => {
    ChatAPI.unsubscribeFriendsStatus()
  }
})

💡マウント時にsubscribeして、アンマウント時にunsubscribeすることができる

useEffect

• 依存を明確に記述する

useEffect(() => {
  document.title = `You clicked ${count} times`
}, [count])

💡countが変更された場合にのみ再評価

useEffectの評価タイミング

• 画面をレンダリングした後に評価される
  • 依存に変化があったときに再評価される
  • コンポーネント全体が再評価されるときにも評価される

useEffect(() => {
  const filtered = items.filter(isSatisfied(deposit))
}, [items, deposit])

Propsの評価タイミング

• 親コンポーネントから渡されたpropsが変化するとコンポーネントは再描画され、変数は再評価される

// items/depositがpropsのとき、変化する度に再評価される
const filtered = items.filter(isSatisfied(deposit))

💡useEffectとProps渡しの違いは？

評価タイミングの違い

• useEffectはレンダリングとは無関係に、依存が変化したときに非同期的に評価される
  • レンダリング後にも評価される
• 計算コストが高くなく、同期的で副作用がないものは単なる変数でよい
• レンダリングに影響を与える計算コストの場合、非同期、副作用を伴うものはuseEffectの使用が適切

依存を適切に書く

• 依存漏れ
• 依存間違い
• 値は異なるが、オブジェクトは同値
• 値は同じだが、オブジェクトは異なる

依存漏れ

本来、再評価が必要な依存が漏れているため、値が更新されない、古い値を参照するなど意図しない動作を引き起こす

useEffect(() => {
  getSomething(myId)
}, [])

• myIdが最後に評価されたときの値のまま変わらないため、おかしな挙動になる可能性がある

依存間違い

無関係な値の更新時に再評価され、計算コストだけがかかる

useEffect(() => {
  getSomething(myId)
}, [workspaceId])

• 本来依存のない値の更新タイミングに依存して、適切に動いているように見えて、他の適切でない依存関係の誤りに気づけない懸念がある

値は異なるが、オブジェクトは同値

• 依存にObjectやArrayを指定する場合に注意
  • 依存漏れと同じ

useEffect(() => {
  arrayCorpIds.map(corpId => {
    getSomething(corpId)
  })
}, [arrayCorpIds])

• arrayCorpIdsの配列の中身が更新されたにも関わらず、arrayCorpIdsはオブジェクトとしては同値のため、再評価されず

値は同じだが、オブジェクトは異なる

• 同じ値を保持しているオブジェクトを再生成した場合
  • 毎回再評価されて無駄な計算コストが掛かる

useEffect(() => {
  arrayCorpIds.map(corpId => {
    getSomething(corpId)
  })
}, [arrayCorpIds])

• arrayCorpIdsの配列の中身が変わらないのに、arrayCorpIdsはオブジェクトとしては異なるため、再評価される

無限ループを回避する

• useEffectが依存する値をuseEffectの中で書き換えると起こる
• シンプルな対策としては、ガードする
  • どこでも使えて一番シンプルな回避方法
  • オブジェクト、配列の場合は比較が高コストなので注意

if (currentState !== nextState) {
  setCurrentState(nextState)
}

useReducer

• 複雑な状態管理ロジックをreducerに閉じることができる

type State = {
  isAuthenticated: boolean
  isLocked: boolean
  isTemporaryPassword: boolean
  isError: boolean
}
  
type Action =
  | { type: 'authenticate' }
  | { type: 'lock' }
  | { type: 'setTemporaryPassword' }
  | { type: 'setError' }
  | { type: 'reset' }

useReducer

• Reducerは純粋関数にできる
  • 状態に整合性が必要な場合はここで担保できる

const reducer = (state: State, action: Action): State => {
  switch (action.type) {
    case 'authenticate':
      return { ...state, isAuthenticated: true }
    case 'lock':
      return { ...state, isLocked: true }
    case 'setTemporaryPassword':
      return { ...state, isTemporaryPassword: true }
    case 'setError':
      return { ...state, isError: true }
    case 'reset':
      return { isAuthenticated: false, isLocked: false,
            isTemporaryPassword: false, isError: false }
    default:
      return state
  }
}

useReducer

• 使う側はユーザー操作と対応するアクションとして記述できる

// 認証完了時に呼び出す
dispatch({ type: 'authenticate' })

// ロック状態だったときに呼び出す
dispatch({ type: 'lock' })

// 仮パスワード状態だったときに呼び出す
dispatch({ type: 'setTemporaryPassword' })

// エラー時に呼び出す
dispatch({ type: 'setError' })

// サインアウトに呼び出す
dispatch({ type: 'reset' })

useStateかuseReducerか

• useStateの場合
  • 複数定義してもすべて独立した個別の状態管理
  • 状態が複雑な場合にロジックが分散する懸念
  • 単一の状態管理、局所的な状態管理に最適
• useReducerの場合
  • 状態管理のロジックをReducerに閉じられる
  • オブジェクト構造の状態の整合性をとる
  • ユーザー操作のアクションで状態が変わることを記述できる

derived state

propsから導出された変数をどう扱うか

• useEffectに入れる？
  • 親コンポーネントがレンダリングされるたびにuseEffectは評価されるため、useEffectで計算させると無駄な再レンダリングが非同期に走る可能性がある
• useStateに入れる？
  • 必ずしもstateに格納する必要はない可能性がある
  • 初期レンダリングを初期値で行わせ、レンダリング中にsetStateで変更し再レンダリングさせることはできる

derived state

• 単なる変数として宣言する
  • 多くの場合、単に変数として導出したいことが多い
  • 演算コストが低いなら毎回計算させた方がよい
• useMemoに入れる
  • 再計算を抑制することはできる
  • 演算コストを抑えることができるが、比較コストはある
  • 単なる変数だが再レンダリングのたびに計算させるにはコストが高い場合に有効
• useState/useEffect
  • 副作用的に値が変更される場合には使う

React Custom Hooks

• Hooksは自前で実装できる
  • useStateなどは特殊なものではなく同じものを実装できる

React Custom Hooks

• useContextとの違いは？

useCustomHook

• useCustomHookは単にカプセル化しただけなので、複製されている

useContext

• useContextはグローバルに一つのコンテキスト