React/Fluxにおける問題とReducerが切り開く道 | FAworksブログ
私がReact/Fluxアプリケーションを書いてきて、もう1年になる。Flux開発の1年を振り返ってみると、このFluxというものが便利だと、はっきり言うことができる。過去は「こんなイベントチェーンなんて触ってないよ」という日々だった。取り組んできた全てのFluxコードベースは綺麗だったし、デバッグ可能で、メンテナンスも容易にできた。 Fluxに関しては、インタラクティブな金融チャート、リアルタイムのテーブル絞込み、いつものCRUD系のものから複雑な非同期要求チェーンにいたるまで、遭遇してきたあらゆる問題を解決することができた。Flux最大の長所の一つは、その普遍性だ。絶対的に簡潔で美しくなることは決してないが、決してハッキングすることもない。大規模コードベースにおいては良いことだ。複雑なUIに取り組む際にも、同じ考え方を当てはめると非常に効果的となる。 良いことづくめ？ もちろん、そんな
Reactive MVC and the Virtual DOM
The web frontend scene is witness to many new frameworks and ways of working. It can be quite annoying when software becomes legacy quicker than ever. But actually, it's just good old innovation happening as it should, because the opportunities for improvement are there. Frameworks come and go, but what remains are the good ideas that they brought to the world. We're going to talk about the good i
Reactを用いたアプリケーションアーキテクチャ：Fluxを再考する | POSTD
他のフレームワークやライブラリから React に乗り換える人たちは、「ReactはUIのレンダリングに関する問題しか解決しておらず、状態管理とアプリケーションアーキテクチャの選択は開発者に委ねられているのだから、どうやってアプリケーションの状態を管理したらいいのか？」 と疑問に思う傾向があります。FacebookはReactのレンダリングモデルに適している、 Flux と呼ばれるアーキテクチャを勧めています。 この記事では、UIレイヤとしてReactを用いてJavaScriptのアプリケーションの状態を管理する方法を探り、 Om のような ClojureScript ライブラリのアイデアを用いてFacebookのFluxの抽象的なフレームワークを作り変えてみたいと思います。 Fluxの核となる考えは、 データは一方通行で流れるべき というものです。これによってアプリケーションの論証が簡単
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
