Reduxと愉快な仲間たち

前提

スライド形式じゃないものはこちら

若干内容異なるけど

このスライドは今後更新されないけど、↑は更新していくと思う

このスライドはざっくりしているので、詳細な話は

各リンクの中を見るか、そこにある参考リンクを参考にしてください

タイトルは釣りです

大雑把なアジェンダ

GUIアーキテクチャパターンとかの話

Reduxの話

Reactの今後とか

まとめ

動機

Elmという言語を触った

そういえばReduxあまりわかってないな..ってなった

2年ぐらい触っているけど、意義を知らない

Elmとは

関数型のAltJS

つまり、関数型言語でフロントエンドを書ける

コンパイルすると、HTML, CSS, JSに変換される

事実上一切の実行時例外が起こらない

コンパイル時に全てのコーナーケースを潰す

雑に言うと、ReactとReduxの概念を一つにしたような言語

React, Reduxと似ているところ

Reactっぽい

Reduxっぽい

実は「っぽい」の順番が逆(後述)

Elmのviewの部分のサンプルコード

各htmlタグは関数

div関数、button関数、input関数, etc.

code:elm

view : Model -> Html Msg

view model =

div []

]

ここでは使ってないが自作コンポーネントのようなものも作れる

JSXとの比較

皆さんおなじみのJSX

code:JSX

<div onClick={alert}>こんちわ</div>

先程も見たElm

code:elm

各要素は関数であり、こんな感じの型

div : List (Html.Attribute msg) -> List (Html.Html msg) -> Html.Html msg

Reactの実体もメソッドだし同じような感じではある

code:JSX

// JSX

<div onClick={alert}>こんちわ</div>

↓↓↓↓↓

code:js

// 本物のReact

React.createElement("div", {onClick: alert}, "こんちわ")

ここまではElmの話

ここからはアーキテクチャパターンの話

https://upload.wikimedia.org/wikipedia/commons/thumb/a/a0/MVC-Process.svg/1200px-MVC-Process.svg.png

Controller→Model→Viewの一方通行のモデル

入力、データ処理、出力を分けることが目的

Viewは出力だけに専念

データのロジックとか永続化については考えなくていい

https://cdn.journaldev.com/wp-content/uploads/2018/04/android-mvvm-pattern.png

2005年ぐらい

Model, View, ViewModelの3つのコンポーネント

ModelとViewの密結合を解決した

ViewModelが中継する

ViewとViewModelを書くチーム、専門性、言語が異なっていたので分解できるようにした

View↔ViewModel、ViewModel↔Modelの関係は多対多になる

Webサービスがでかくなってきて、、、

複雑じゃね？？？？？これ無理だわ、ってなった

MVVM

一つのViewを修正するときに、複数のViewModelを修正しないといけない

どれとどれが対応してたんだっけ...

一つのModelを修正するｔ(ry

MVC

Facebookさん「MVCまぢむりｗ」

https://res.infoq.com/news/2014/05/facebook-mvc-flux/en/resources/flux-react-mvc.png

https://cz-cdn.shoeisha.jp/static/images/article/10499/10499_001.png

Action、Dipathcer、Store、Viewの4つのコンポーネントからなる

結合関係を単一にする

多対多からの脱却

データフローが一方通行

複数のStoreを持つ

Stateはmutateである

発表したのはアーキテクチャパターンであり、実装は伴わない

Fluxフレームワーク戦争勃発

Fluxxor

Fluxible

NuclearJS

Alt

etc.

参考

閑話休題

ちょっとReactの話から逸れる

アプリケーション全体の状態を一つのImmutableなStateとして保持する

ViewはCursorsを通じてstateを参照する

Undo/RedoのできるWebアプリケーションが簡単に実装できる

Fluxに影響を与えた

通称「TEA」

Elmでは基本的に全てこれに則ってアプリケーションを実装する

フレームワークは使わない、言語思想自体がこれ

https://miro.medium.com/max/2100/1*dZFJ9fnMH-2c3B8byqrDmw.gif

Model, Update, MsgとViewからなる

名称は違うがReduxとほぼ同じ

一方通行のデータフロー

言語機能がこれなのでReact, Reduxよりもめちゃくちゃ簡潔に書ける

次回に話す

CQRS

コマンド(更新系)とクエリ(参照系)の責務分離

コマンドのみが副作用を扱う

イベントソーシング

状態の永続化ではなく、全てのイベントを永続化する

commitをイベントと捉えるならGitはこれ

https://gyazo.com/a558dbe9497c8b568d7e2a70deb104b7

Fluxに今まで見てきたような概念を導入した

Action, Reducer, Store, (Middleware)とViewからなる

Reduxの原則

Single source of truth

Fluxと異なる点

Om, TEAっぽい

State is read-only

Om, TEA, Fluxっぽい

Changes are made with pure function

TEAっぽい

TEAやんけ！！！

知らんけど

Reduxさん「Elm Archtectureええやん」

ReduxはFluxの概念にElmの概念を混ぜ込んだアーキテクチャパターン

ReduxとFluxの比較

アプリケーション全体で一つのStateをImmutableに持つようにした

複数のStore

mutateなState

StoreをReducerとStoreに分離した

ReducerはActionを受け取りデータを更新(Write)

ActionCreatorの返り値はvoidなのもミソ

ReduxのStoreは最新のStateをViewに渡す(Read)

CQRSっぽい

ActionCreator, Reducerは純粋関数

各コンポーネント(FC)も純粋関数

middlewareのみが副作用を持つ

副作用がある部分を一箇所に追いやった

全ての処理はActionの積み重ねである

イベントソーシングっぽい

デバッグ時などにタイムトラベルができる

Reduxは関数型の概念を持ち込んだ

予測可能な形でコードが構造化されている

GUIではなくコードを読んで処理を理解できる

代わりに記述量は多い

ちなみにElmだと簡潔になる(しつこい)

MVCとかReduxとかなにがしたいのか

GUIをプログラミングすると秒で複雑になっていくのでどうにかしたい

ドメインロジックとViewの処理の分離

さらにこいつらの依存性も減らしたい

TEAとかReduxとか何がしたいのか

さっきのに加えて関数型由来の概念を持ち込んだ

副作用が入ると理解しづらくなるのでどうにかしたい

Reduxは主に上がる問題が記述量なぐらいには完璧に近づいたアーキテクチャなのでは

しらんけど

ここでHooksの登場

Redux「Stateは一箇所で管理してコンポーネントはPureにするで」

React「各コンポーネントを強くするで」

対立しているように見える

疑問

Reactが望んでいるアプリケーションのアーキテクチャとはなんなのか

個人的にReactの思想に乗っかっていきたいが、まだ見えていない

まとめ

Elmすごい

Reduxすごい

Reactやばい

次回

同じアプリケーションをいくつかのパターンで記述して比較する

Elm、従来のRedux、ReduxHooksを使ったもの、ReactHooksだけ

アーキテクチャの話から徐々にHooksの話に移っていく

最終的にはHooksを用いた各コンポーネントの設計の話をしていく

つもり