FluxにはModelがないのではないかと思った覚書 - ナカザンドットネット
Fluxを使い始めると「おっ、MV＊に比べて頭が悪くても状態が壊れないぞ？」という感想になる人が多いと思うんだけど、その理由がふたつあるような気がしてきた。 ModelやViewModelについてはコンテキストが違う人から「それ違くない？」と言われそうな書き方になるかもだけど、思いつきを書きなぐってるだけなので勘弁してください。 1. 単方向データフローが分かりやすく、コードの複雑さの低下に寄与している これは全くポジティブな要因。 2. FluxはMV＊のModel相当の要素が図に含まれていないので考えることが減った MV＊は「Modelって書いてあるからには何かをModelと呼んでデータを突っ込まなきゃいけない」という意識が生まれやすかった（その責務分割が適切だったかは別として）と思う。 でも、FluxにはStoreとかいうViewModel*1みたいなものしかない*2と私は思っていて
FluxのStoreがViewModelかって話からのMVWとかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
StoreがViewModel相当かどうかってことそれ自体はたぶんあんま本質じゃないんだけど。 blog.nkzn.info これについてです。 わかる。StoreがViewModelってのはちょっとだけ違和感あって、ぼくは ViewModelが読むためのクエリ用モデルくらいに思ってるけど、どちらにせよクリーンアーキテクチャ的な考えで言う「外側」のものだよねという点ではたぶん認識一致してると思う https://t.co/IMQADHGwUb— 猫型🐱蓄音機 (@shinpei0213) 2018年5月15日 べつにStoreが ViewModel相当なのかクエリモデル相当なのかってのはじつはどうでもよくて、あのクリーンアーキテクチャの同心円の外側に位置するものだってことがたぶんこの記事の本質。で、クリーンアーキテクチャは同心円の層の数を定義してなくて、— 猫型🐱蓄音機 (@shinp
Androidアプリ開発にFluxアーキテクチャを導入したら保守性も品質も上がりました - ZOZO TECH BLOG
こんにちは。フロントエンドエンジニアの茨木（@niba1122）です。 弊社のAndroidアプリ開発ではMVVMアーキテクチャを用いています。日々肥大化・複雑化していくViewModelが保守性や品質を担保する上で課題になっていましたが、Fluxアーキテクチャの導入により改善することができました。 本記事では、実際どのようにFluxアーキテクチャを導入したのかを、設計やコード例を交えながらご紹介します。 今までのMVP・MVVMの限界 アプリ開発ではMVP・MVVMといったアーキテクチャがよく用いられます。弊社のAndroidアプリ開発でもMVVMを用いています。これらのアーキテクチャはビューとドメインロジックを分割するのに役立っています。しかし、昨今のUIには多くのイベントや状態があり、更にそこにAPIリクエストなどの非同期処理が絡んできます。これらが関わるプレゼンテーション層のロジッ
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する Androidアプリの開発において悩ましいアーキテクチャの選定。本記事では選定する意味を改めて整理し、 MVP・Clean Architecture・MVVM・Fluxといった最新の実例を紹介します。 はじめまして。Androidエンジニアの藤原聖（ふじわら・さとる／@satorufujiwara）です。 現在は株式会社サイバーエージェントで、エンジニアリングマネージャーを兼任しています。2017年で35歳になり、定年を迎えました（プログラマの定年については「体型を支える技術」などを参照）。 Androidアプリ開発には2010年から携わっていますが、今現在の関心事は何といっても公式開発言語に採用されたKotlin。そしてもう一つが、Androidの
React.jsとFlux - Qiita
今回はReact.jsとも関わりがあるFluxについて紹介したいと思います。 Flux is Architecture ↑の図はfacebookのfluxのリポジトリにあるものですが、Fluxは上記のようなArchitectureの名称です。facebook/fluxのrepositoryに行ってもらうとわかるのですが、実装としてはDispatcherの部分があるだけです。 Unidirectional data flow 先ほどの図を見てもらうとわかる通り、Fluxではアプリケーションの複雑さをなくすため、データの流れを一方向にします。 そのため全体の処理の流れはわかりやすくなりますが、Angular.jsなどで書くときに比べて冗長に感じることもあるかと思います。 しかしながら単純なデータの流れを作ることで、ある程度の規模になってアプリケーションが複雑化してもデータやイベントの流れがスパ
GitHubで人気なFlux(とMVI)のAndroidアプリのコードを読んでみるメモ - Qiita
MVPやClean Architectureはなんとなくは雰囲気をつかめてきましたが、全くFluxやちょっと話題のMVIがわからないので調べてみました。 lgvalle/android-flux-todo-app ★1,170 flux androidでGitHubで検索すると一番スターが多いリポジトリです。 しかし、2015年に作られたということでRxJavaなどが利用されていないなど、多少古い気がしています。 https://github.com/lgvalle/android-flux-todo-app より 起動してADDボタンを押したときの動きを追ってみます。 View -> Action まず普通にActivityがあり、そこでイベントリスナのセットなどを行っています。 resetMainInput()メソッドはただEditTextの中身をsetText("")して空にするもの
結局FluxやらReduxやらって何なのか個人的なまとめ - Qiita
FluxやReduxがまた分からなくなったので、個人的なまとめをしました。 「これ間違ってるぜ！」ってのがあればコメント等でご指摘していただけると嬉しいです。 また何か気付きがあればちょこちょこ更新入れることもあります。 Fluxって？ Facebookが提唱しているアーキテクチャで、JavaScriptのデータの流れを分かりやすく整理するために使われます。 JavaScriptはイベントドリブンなため、様々なデータの流れがあり複雑化しやすくなっています。 そのためFluxではその流れを一方向にまとめよう！といったことをやっています。 Dispatcherを通して状態を変化させていく様子はデザインパターンのオブザーバーパターンと同じような形ですね。 基本的には以下の様な流れです。 またユーザーの行動によってViewから新たにActionを発行し、Dispatcherへと伝搬させることも出来
トルテにおける新規Android
アプリ開発の技術選定について - Speaker Deck
「トルテにおける新規Android アプリ開発の技術選定について」CA.apkにて利用した発表資料になります。以下は資料に記載している選定技術やツールの一覧です。(選定技術・ツールは2017年1月12日時点のものです。) * 設計 - facebook/flux: https://github.com/facebook/flux - Flux de Relax :) // Speaker Deck: https://speakerdeck.com/ogaclejapan/flux-de-relax * 主要ライブラリ - google/dagger: https://github.com/google/dagger - square/okhttp: https://github.com/square/okhttp - square/retrofit: https://github.com/
Android で RxJava を利用して Flux してみた - Qiita
Flux とは Facebook が提唱したアーキテクチャの名称で、最近のフロントエンド(JavaScript)界隈でアプリケーションの状態の複雑さに対応する為のアプローチの一つです。 https://facebook.github.io/flux/docs/overview.html 旧来の MVC2 もしくは Observer パターンに Action Dispatcher Sotre というコンポーネント名を定義し Flux という名称をつけたもの、と考えてもよいかと思います。 なぜフロントエンド(JavaScript)界隈で今このアーキテクチャが取り上げられているかと言うと React の仮想DOMの登場がきっかけになっています。アプリケーション開発でおおざっぱに状態(Flux でいうと Store)から View 全体を再描画するコードを書いても、仮想DOM側で差分でレンダリング
FluxとDDDの統合方法 - かとじゅんの技術日誌
おはこんばんにちは、かとじゅんです。 久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。 さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。 Fluxって何？ まず基礎ということで、Flux i
RxJava + Flux (+ Kotlin)によるAndroidアプリ設計 - Qiita
Introduction Androidにとってアプリ設計は永遠の課題だと思います。 Activityが独特のライフサイクルを持っているのがさらに課題を複雑化します。 設計についてはMVCやMVP、MVVM、Clean-Architecture、DDDなどが最近の主流でしょうか。 上記にあがった設計手法に関しては素晴らしい記事がいくつもあるのでとても参考になると思います。 AndroidではMVCよりMVPの方がいいかもしれない http://konifar.hatenablog.com/entry/2015/04/17/010606 [ Android ] - これからの「設計」の話をしよう https://tech.recruit-mp.co.jp/mobile/android-architecture/ AndroidオールスターズでClean Architectureについて発表し
Android Data Binding + Flux が良すぎると自分の中で話題に - mobiledev日記
2015-06-16 Android Data Binding + Flux が良すぎると自分の中で話題に プログラミング Android 予想はできてたんですが、 Android Data Binding と Flux の相性が良すぎました テキトーなサンプル組んでみて、「あ、これいいわ」と直感。 StoreをBinding対象とすれば、 Store更新後に自動でViewの更新が走る んですよね。これが楽。 Reactだとデータ更新通知からsetState必須でしたからね。ここが自動化されてるのはうれしい。 あとJavaだと型周りをがっつりコンパイラがチェックしてくれるのも大きいです。「このActionはどういう情報をもっているのか」もクラスにまとめることで分かりやすくなりますし。 これは癖になりそう。はよData Bindingの正式版きてほしい 必要な部分のみまとめてライブラリ化した
10分で実装するFlux
10分で実装するFlux 自己紹介 azu @azu_re Web scratch, JSer.info Flux /flˈʌks/ Fluxとは Facebookが提唱したSmalltalk MVCの焼き直し CQRS(Command Query Responsibility Segregation)と類似 データが一方通行へ流れるようにするアーキテクチャ ウェブUIについてそれを適応する 今日の目的 小さなFluxの実装を作りながらFluxついて学ぶ Fluxの特徴: Unidirectional data flow 本当にデータが一方通行に流れるのかを確認する Fluxでよく見る図 登場人物 何か色々いる Action Creators, Dispatcher, Store, React Views... Dispatcher = EventEmitterと今回は考える もっと実装的
なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita
追記: 情報が色々と古くなったため、2020年に書き直した版へのリンクを張っておきます。 この記事は VirtualDOM Advent Calendar 2014 - Qiita の初日です。 初日ということで、基調講演風に、Virtual DOMとはなにか、なぜ僕はこんな興奮しているのか！という話から。 Virtual DOMとはなにか 既存の概念で当てはめると、JavaScriptのMVC, MVW(Whatever)フレームワークのViewに位置します。が、その程度では終わりません。仮想DOMとは世界を革命する力であり、このjQueryのDOM操作で汚れきったフロントエンドを救う救世主なのです。 現時点で自分が知っている限りは、以下の実装を指します。 facebook/react 最も使われてるFacebookの実装 Matt-Esch/virtual-dom Altenative
FluxもMVCも不要？コンポーネント指向Webプログラミング - Qiita
（※2016/07追記： redux使ってみたら悪くなかったので宗旨替えしました。こちらの記事とかをどうぞ。http://qiita.com/uryyyyyyy/items/7d4b0ede3f2b973d6951 ） タイトルは半分くらい釣りですが、半分くらい本気です。 目的 Fluxわからん Facebook公式の例の図を見て、「うっ、複雑だ。。。」って受け付けなかった人は僕だけじゃないと思ってます。 そのわりにはメリットもピンとこないし実装も乱立していて、正直『MVC』『オブジェクト指向』のようにバズワード化してる印象を受けています。 そのうち、「やっぱりお前らのFluxは間違ってる」とか、「お前の言うFluxはどこのFluxだよ」とか言い出すんじゃないかと思ってます。 そもそもFluxとかMVC要らなくね？ また、「ReactはViewしか提供しない」という意見がありますが、個人的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
