こんにちは、小林（@koba04）です。 本記事では、シングルページアプリケーション（以下、SPA）における状態管理について解説します。 GmailやTwitterは、SPAとして構築されている代表的なWebアプリケーションであり、スムーズなページ遷移をSPAによって実現しています。またElectronやPWA（Progressive Web Apps）の登場により、複雑なアプリケーションをWebの技術を使って構築する場面も増えてきました。 これらの複雑なアプリケーションにおいては、既存のページ単位での状態管理の考え方では対応が難しくなります。 そこで今回は、具体的なフレームワークも取り上げながら、Webフロントエンドにおける状態管理のアプローチについて紹介します。 フロントエンドでの状態管理の複雑化 ページの単位を超えた状態の保持 モデルとビューによる処理の分割 イベントの管理が複雑にな
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: When (and when not) to use Redux – LogRocket 原文公開日: 2018/01/20 著者: Christian Nwamba サイト: LogRocket 2018/03/13: 初版公開 2021/06/03: 更新 Reduxが登場するまで、複雑なタスクを組むときのステート管理は相当つらい作業でした。Reduxは、Fluxというアプリケーションデザインパターンにヒントを得て、JavaScriptアプリでステートを管理するために設計されました。ReduxはReactと併用されることが多いのですが、ReduxはjQueryやAngular、Vueといった別のフレームワークとも併用できます。 Reduxのサイズは非常に小さい（依存関係も含めてわずか2KB）にもかかわらず、アプリの各コンポーネ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに ReduxはSingle Store、immutableなState、副作用のないReducerという３つの原則を掲げたFluxフレームワークです。しかし他のフレームワークと違って提供しているものは最小限で、とてもフルスタックとは言えない薄さです。そのためすべてにおいて定番と言える書き方が定まっているわけでもなく、どうしようか迷ってしまうことも少なくありません。その筆頭とも言えるのが 非同期処理 の扱いです。コミュニティでは今でもさまざまな方向に模索が続いていますが、よく使われているものだとredux-thunk、redux-
【追記】 もうこれ古いから参考にしないでください https://t.co/mXtcc73Orf — もし Laravel が流行しなくなってこられてきてたとしたら、絶対に捨てられてこられてたと思うか (@mpyw) January 26, 2021 Redux にはその昔 connect()() とかいうクソ API と， Redux-Saga とかいう宗教がありました という考古学です — もし Laravel が流行しなくなってこられてきてたとしたら、絶対に捨てられてこられてたと思うか (@mpyw) January 26, 2021 読者対象 Tutorial: Intro To React - React Example: Todo List · Redux 「チュートリアルそれぞれ一周した！Reactは何とか理解できたが，Reduxがさっぱりわかんねぇ！」 ぐらいの人向け。自分
Flux によりもてはやされてる感のあるオブザーバーパターンですが、個人的に Flux はちょっと大袈裟すぎて疲れてしまいます。 もっとシンプルにできないものかと思って Riot.js に組み込まれてる riot-observable をラップしてちょっと便利にした Obseriot を作りました。 Riot.js での悩みを解決するために作りましたが、Riot.js( 本体 ) は不要なので何にでも合うはずです。 2016/08/01: Fluxのように使う方法を追記しました。 TL;DR Obseriot で解決したかったのは以下の点です。 使えるイベントに秩序が欲しい。定義したイベントだけを使いたい。 受け取れる値にも秩序が欲しい。常に定義したフォーマットで受け取りたい。 そこで riot.observable() の on と trigger をラップして以下のように使えるようにし
Vue.js + Vuex = Magic コンポーネント指向とFlux architectureで始めるモダンフロントエンド こんにちは、フロントエンドエンジニアの蔀です。 ここ数年のフロントエンド開発の潮流の変化は急激で、雨後の筍のように色々なフレームワークが出てきていますね。 8月末には、Mediumでこんな記事が人気になりました。 The State Of JavaScript: Front-End Frameworks と銘打たれたこの記事は、React/Angular/Angular2/Ember/Vue/Backbone といった、近年流行しているJavaScriptフレームワークに関する興味、満足度、知名度などを調査して比較してくれています。 注目していただきたいのが、「Satisfaction（使ってみて満足したかどうか）」の項目です。 近年流行しているReact.jsと
過去にJavaScript開発をやったことがある人であれば、 Redux のことは聞いたことがあるでしょう。Reactとともに一般に普及し、開発者の中には「当時のJavaScript関係で一番興奮した出来事だった」、「アプリケーションの構築に大変革をもたらした」、はては「Reduxのおかげで地球温暖化が完全に止まった」と言う人もいるくらいです。 失礼、ちょっと我を忘れてしまいました。しかし、真面目な話、Reduxはアプリケーションの構築方法に、変化をもたらしたのは本当です。この投稿では、Reduxを別のライブラリの Immutable.js と一緒に、Angular 2と統合するやり方をご説明します。 概要 この投稿では、FluxアーキテクチャとReduxの基本的な概念を考えていきます。それから、簡単な連絡先リストのアプリケーションを段階的に作っていきます。初めは基本的なセットアップを構築
EventEmitterバケツリレースタイル/フレームワークなしで小さくFluxする - Qiita これ見て最近は大体自分も同じような感じのことをしているので共通化できる最小限のコードをライブラリにしてみた。 元記事でも言ってるようにやることはとても少ないのでライブラリ使わないでもいいんだけどそのへんは好み。 Usage まず普通のステートレスなReactコンポーネントを作る。dispatchというpropsを受け取ってそれを通してイベントを発火するというのが唯一の規約。 import React from 'react'; // Stateless component export default class Counter extends React.Component { render() { return ( <div> <div>{this.props.count}</div>
この記事は仮想DOM/Flux Advent Calendar 2015の25日目……に入れようと思ってたけどもう埋まってた……。 オマケということで頼む！！！！！ 24日目は JavaScript - 実践：MagJS で TodoMVC - Qiita でした。 メリークリスマス！！！！！！！！！！ こんにちは id:amagitakayosi です。 みなさん今月も Flux 書いてますか？ 僕はオレオレ実装をIsomorphic対応したけど昨日Revertしたところです！！！！！ウオー！！！ 今日は↓12/2の記事↓の続きを書いていきます！ amagitakayosi.hatenablog.com もくじ 前回のあらすじ flux-utils Container vs View Cycle.js flux-challenge Rx系 thisless-react, Yolk DDO
名前はダークソウルのフラムト(frampt)から。FLux Minimum なんたらかんたら。 なんかTwitterで色々言ってたら naoyaさんにまとめられたので、ここに僕の考えを詳しく書いておく。 mizchi の Redux 考 - Togetterまとめ やりたかったこと 基本的なアイデアは、stateをpushする方式(setStateみたいな)だと非同期間で参照したときの値がズレて非同期の終わる順番次第では状態の遷移ステップが壊れてしまう可能性があるんだけど、前のstateをとって次のstateを返す非同期をキューに並べて順に実行することで、トランザクションみたいなものを保証することができるだろう、というもの。 軽量(pubsubインターフェースはEventEmitterそのまま) 複数の状態更新関数の待ち合わせ reduxで感じた不満の解消 TypeScriptフレンドリー
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Reactがもっと広まって欲しいと思っている今日このごろ。React EuropeでJoseph Savona氏の講演でRelayについての「モヤっと」がいっきにかなり解消された気がするので、要点を本編を翻訳しながら自分なりにまとめておきます。 私の理解が誤っている可能性は十二分にありえるので、ご指摘いただければ幸いです。 はじめに ReactとFluxって組み合わせと共によく目にするのが↓の図。 矢印は一方向にしか進まないのが特徴で、わかりやすいってのがいろんなところで書かれているんですけど、 **結局データをサーバからとってくるとこ
@armorik83 さんの記事を受けて Fluxフレームワーク Arda が気になる10の理由 - Qiita 設計思想とか指針とか残しておきます。 mizchi/arda Arda - MetaFluxなフレームワークを作った - Qiita Ardaは実践的なものを目指した 他のフレームワークは思想から入って実装されたものかもしれませんが、ArdaはFluxを意識しつつも実際のアプリで使われている画面遷移の機構を抽象化する点から開発がスタートしています。 またKobitoという比較的寿命が長い(ことを予定している)アプリの基盤にすることで長くメンテされる予定です。なのでKobitoはちゃんと使ってもらえるようなものにしたい、と思って開発しています。(この記事が宣伝兼ねてないとは言いませんが。) (自分の開発したものにしては)ドキュメントが充実していることについて 開発者の今回の様子に
2. 前提となる適用先 • 管理画面的なWebアプリケーションのリニューアル …だったもの（仮） • REST APIを前提としたSingle Page Applicationもどき （※すべてが1ページではないけど） • 機能・画面が多い • 複雑化することがほぼ確実 3. Viewへの要求事項 • 統一されたスタイルでUIとなるHTMLを生成できる • なるべく簡単に書けること（含セキュリティリスク回避） （生DOM・jQueryはあり得ない） • 業界におけるパラダイムが過渡期のため、 巨大フレームワークに乗っかりたくは無い （交換可能な部品の組み合わせでプレーンに） • 困ってもなんとか出来るための緊急ハッチも必要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
