React ステート管理 比較考察 - uhyo/blog
こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント（使用者）で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
[RubyKaigi 2024] Ruby Mixology 101: adding shots of PHP, Elixir, and more
状態設計から「なんとなく」を無くそう
ウォンテッドリー株式会社の社内イベント "Tech Lunch" で話した発表です。 プログラムには大小さまざまな粒度の「状態」が存在します。 状態の設計を工夫することで、コーナーケースの発生を抑止し、ユーザー体験を最適化することができます。 本発表では、私が普段どのように「状態」について考えているか、言語や環境を問わずできるだけ普遍的に使える形での言語化を試みます。本発表を通じて、「状態」をなんとなくではなく合理的に設計するためのヒントを提供します。 GoogleスライドのURL: https://docs.google.com/presentation/d/1PNzz69UV05HlKPuWGlooemnPslLbLKsyLwl3R4U_XqE/edit
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Stateのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが開発・運用しているアプリケーションのState戦略についてご紹介していきます。 全体像 アプリケーションに存在する状態（State）を以下の3種類に分類し、それぞれのやり方で管理しています。 サーバーデータのキャッシュ Global State Local State 1. サーバーデータのキャッシュ 「SPAで管理する必要のあるGlobal Stateって、そのうちほとんどがサーバーデータのキャッシュだよね。それを取り除けたら、管理する必要のあるGlobal Stateってすごく小さくなるんじゃない？」という主張を私が認識しはじめたのが2020年の初旬でした。おそらく
自分が開発しているLaunchableのWebアプリがローンチされて1年半ほどになる。このWebアプリにはReduxのような状態管理ライブラリを入れないまま開発してきたのだが、今のところ困らずに開発できている。そういえば昔自分は状態管理について何か考えていたような…とブログを掘り起こしてみた。 ninjinkun.hatenablog.com このエントリは2016年にネイティブアプリを対象にして書かれているが、この後自分は2018年ごろにWebフロントエンドに軸足を移し、ネイティブアプリ開発から離れた。なのでこのエントリはWebフロントエンドエンジニアが2022年に再考した話になる。 結論としては、当時自分が管理したかった状態のほとんどは現在ApolloClientのキャッシュによって解決されている。 繰り返しになるが、自分が開発しているLaunchableのWebフロントエンドには状態
宣言的UI
宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql
はじめに 2014年にReactを触りはじめて以降、2022年現在まで集中の度合いにバラツキはあるものの、ずっとReactでなんらかのアプリケーションを書いてきました。 その中で様々なアーキテクチャや設計に関する議論がありましたが、特に状態管理についての変遷を自身の体験をもとにまとめてみたいと思います。 多分に昔話的な内容なものの、適度に読み飛ばしてもらいつつ、Reactの状態管理のやや偏った歴史と現在地点の認識の共有になればと思います。 2014- | Reactの導入 - Flux SPA iPhone 4Sが出てスマートフォンを持つ人も多くなり、エンジニアでなくても多くの人が日常的にGmailやMapアプリケーションに触れるようになった時期だったと記憶します。 Webアプリケーションの構築でもフロントエンドへの要求レベルが高くなっていた感覚があり、JavaScriptで動的なView
はじめに 弁護士ドットコム デザイナーの林（@taka_piya）です。 弁護士ドットコム 案件管理システムでは、アプリケーションとUIの状態管理にXStateを用いたステートマシンでの管理を導入しています。 この記事では、UIデザインの考え方にステートマシンを導入し、実装まで一気通貫で行う方法と、そのメリットについて説明します。 はじめに UIは2つの要素からなっている ステートマシンを理解する 定義 状態遷移図 ステートマシンを使ったUIデザイン〜実装プロセス ステートマシンを定義する Figmaで表現する JavaScriptで表現する ステートマシンをアプリケーションに適用する UIデザインにステートマシンを導入するメリット 振る舞いに集中できる チームの共通認識として使える 変更に強い おわりに 関連ドキュメント ALPS-ASD UIは2つの要素からなっている Android
このエントリーは 一休.comのカレンダー | Advent Calendar 2023 - Qiita の22日目の記事です。 レストランプロダクトUI開発チームの鍛治です。 一休レストランのフロントエンドを担当しています。 一休レストランでは Next.js App Router Remix を採用しています。 user-first.ikyu.co.jp 昨年の終わり頃から始まった一休レストランのリニューアルですが、フロントエンドは Nuxt v2 (Vue 2) から Next.js App Router (React) に、という大きな切り替えで、不慣れだった我々は React 初心者がひっかかる落とし穴を全部踏み抜いてきました。 例えば、チュートリアルに従って useState で変化する状態を定義して、最初はそれで全てがうまくいっていました。機能追加していく過程でいつの間にか一
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
Vue___Vuex_のアーキテクチャ完全に理解した.pdf
「3種類」で管理するReactのState戦略
再考: アプリ開発と状態遷移の管理 - ninjinkun's diary
Reactの状態管理の変遷に関する自分史 From 2014 To 2022
UIデザインにおけるステートマシン - 弁護士ドットコム株式会社 Creators’ blog
一休レストランの XState 導入記 - 一休.com Developers Blog