ブラウザアプリケーション以外のプラットフォームでのReduxはtoo muchか?

@Nkznとかが最近よく言ってるReactNativeではReduxじゃなくていいんじゃない?って話。Electronでも同じような議論が可能だと思うので、さらに一般化して「ブラウザアプリケーション以外のプラットフォームでJSで動くGUIアプリケーションでReduxは必要なのか?」という話をします。

結論から先に言うと、わたしも「ブラウザで動くわけじゃないなら、Reduxである強みってそんなになくなるよね」という立場です。

まず、前提として、Fluxは「状態管理パターン」で、Reduxは数あるそのパターンの実装のひとつである。ということを確認しておきましょう。

その上でReduxの特殊性は

  • Stateがピュアなオブジェクトで表されている
  • Stateの更新はイベントを契機に常に同期的に行われる
  • 以上2点により
    • いつでも状態のスナップショットをシリアライズ/デシリアライズ可能な形で取得できる
    • イベントを積み重ねれば常にそのスナップショットを再現できる

という利点を持ちますね。その結果として非同期なオペレーションと同期的なオペレーションでコードが全然異なってきてしまうというデメリットも同時に引き受けているわけだけれど、今回はそこについては詳細には触れません。

ところで、状態のスナップショットがシリアライズ/デシリアライズ可能であるという利点は「サーバー側で最初に状態作って、HTMLレンダリングして、シリアライズされた状態もクライアント側に渡したい」みたいなときにめっちゃ効いてくるので、SSRやるならReduxに乗っとくってのはかなりいい戦略になると思います。

しかし逆の見方をすると、Stateがシリアライズ/デシリアライズ可能であるという点がうまく効いてこないような場合にはReduxである必要は本当にあるのだろうか? という疑問が湧いてくるわけです。そして、SSRが必要ない、ブラウザアプリケーション以外のプラットフォームでは、あまりこのStateがシリアライズ可能であるという特性は活きてこないんじゃないか?というのが、わたしの考えです。

となると、今度は「Reduxならみんな書けるでしょ(ほんとか?メンテナブルなReduxアプリケーションをほんとにみんなが書けるのか?破滅してる現場結構あるっぽいぞ?)」を取るのか、「別のやりかたをイチから検討しましょう」のコスト支払ってRedux以外のやり方探すのかっていう話になってくるかなと思います。

というわけで、掲題の「ブラウザアプリケーション以外のプラットフォームでのReduxはtoo muchか?」については、わたしの立場としては「Reduxはtoo muchかどうかはともかくブラウザアプリケーションを取り巻く環境に対して too adaptive である。とは言えFluxパターンの実装として枯れてるしよく使われてるし、そういう"長いものにMackerel"的な良さはあるんじゃないですかね。」というあたりに落ち着くのでありました。

わたし個人的には「SSRみたいな特殊な事情がないなら、古き良きレイヤードアーキテクチャのようなやり方のほうが見通しがいい気がするねえ」くらいの立ち位置ですが、それぞれメリット・デメリットあると思うので、このあたりを出発点にチーム内で議論できるといいですねと思います。