再考: アプリ開発と状態遷移の管理 - ninjinkun's diary

自分が開発しているLaunchableのWebアプリがローンチされて1年半ほどになる。このWebアプリにはReduxのような状態管理ライブラリを入れないまま開発してきたのだが、今のところ困らずに開発できている。そういえば昔自分は状態管理について何か考えていたような…とブログを掘り起こしてみた。 ninjinkun.hatenablog.com このエントリは2016年にネイティブアプリを対象にして書かれているが、この後自分は2018年ごろにWebフロントエンドに軸足を移し、ネイティブアプリ開発から離れた。なのでこのエントリはWebフロントエンドエンジニアが2022年に再考した話になる。 結論としては、当時自分が管理したかった状態のほとんどは現在ApolloClientのキャッシュによって解決されている。 繰り返しになるが、自分が開発しているLaunchableのWebフロントエンドには状態

[razokulover]

自分もSWRを常用しているのでweb接続中心のフロントエンドはSWRとContextで十分と思う。Web接続の無いDesktopアプリのようなフロントエンドではRecoil系のライブラリを使うようにしてる(もうReduxは久しく使ってない)

[rawwell]

“昔「アプリはでっかいシングルトン」と書いたが、今やそのシングルトンは高性能なキャッシュに姿を変えた。我々プログラマーはGraphQL APIへのリクエストさえ書けば必要な状態は意識しなくても管理されるので、よりUI

[akymrk]

“昔「アプリはでっかいシングルトン」と書いたが、今やそのシングルトンは高性能なキャッシュに姿を変えた。”

[griefworker]

Webアプリというより、Web APIのクライアントアプリで適用できそう。

[Eiichiro]

アプリはでっかいシングルトンが、ドラゴンボールの曲に乗って再生された(笑)

[nicht-sein]

このあたり知識が追い付いていないのでちゃんと調べるかー

[Yoshiori]

マジでそれなんよ。毎回感動しながらフロント書いてる

[mizdra]

クライアント内部のキャッシュで事足りること多いわかる

[cuttoff19]

"別の視点で見てみると、ReduxあたりまではWeb接続を前提としないGUIアプリの文脈で状態を捉えていたが、GraphQLの登場によりWebと連携するアプリはそちらに特殊化する形で状態の問題を解決してしまった"

[yojik]

“今回は触れないが、Webアプリはグローバルな状態をURLに持てるのがネイティブアプリとの大きな違いだと思う”