[B! flux] griefworkerのブックマーク

FluxとDDDの統合方法 - かとじゅんの技術日誌

おはこんばんにちは、かとじゅんです。久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。さて、今回のお題は﹁FluxとDDDの統合方法﹂について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。Fluxって何？まず基礎ということで、Fluxi

griefworker 2018/09/26

Store はアプリケーション層で、Store がドメイン層の集約やリポジトリを使うのか。

flux
ddd

リンク

クライアントサイドのモデルとは何か後編 ~ 単方向データフローと参照透過性 - mizchi's blog

この記事はクライアントサイドのモデルとは何か前編 ~ クライアントサイド MVC の死 - mizchi'sblogの後編。前提として、今回の出す例で、﹁Web フロントエンドで、そこまで複雑な状態を考慮するなんてそもそも間違ってる﹂という意見があると思う。これに関して、そもそも﹁SPA というものが、いかに実現可能になったか﹂という視点の話であり、また、自分の経験上﹁フロントエンドなんて雑でシンプルでいいでしょ﹂というものが、複雑な構成を取っていくのを、何度も目にしてきた、という2つの前提がある。適切な粒度に応じた適切な構成をとるべし、というのは別の話で、今回、対象が複雑なアプリケーションなのは前提とする。Flux 以前先の記事で ActiveRecord を前提にしたサーバーサイド ORM をクライアントで輸入しようとすると、クライアントでは Storage 層が存在し

griefworker 2018/05/17

react
flux

リンク

クライアントサイドのモデルとは何か前編 ~ クライアントサイド MVC の死 - mizchi's blog

前置きこの記事、本来はFlux には Model がないのではないかと思った覚書 - ナカザンドットネットとFlux の Store が ViewModel かって話からの MVW とかどうでもいいって話 - 猫型の蓄音機は1分間に45回にゃあと鳴くのアンサーとして書き始めた記事だが、前置きだけで別テーマとなったので、前後編に分割する。僕は元々がゲームクライアント屋だったときの発想を引きずってるのと、既存の Web の開発の文脈に対して距離を置いていることを明言しておく。あとこういうテーマでとある原稿書いていたので、頭の整理も兼ねて。 ActiveRecord の功罪を振り返るこのテーマを語るにあたって、まず Rails の MVC について述べなければならない。なぜなら、フロントエンドのアーキテクチャとは、サーバーサイドの MVC の模倣に始まり、破綻し、結果として

griefworker 2018/05/17

リンク

実況中継シリーズ Vue.jsで実現するMVVMパターン Fluxアーキテクチャとの距離 - Re.Ra.Ku アドベントカレンダー day 13 - Re.Ra.Ku tech blog

前説丸山です。Re.Ra.Ku. アドベントカレンダー13日目の記事です。前日はiOSアプリのUIをコードで書いてみる話でした。明日はおそらくScalaの話になると思います。さて、以前も話題にしましたが、builderscon2016が先日開催されました。チケットは3hでSOLD OUT。プラチナチケットと化した参加権ですが、発表する側ならば実質無料で参加し放題！これはいっそ申し訳ないレベルでは！？というわけで、せっかく発表したのでその内容をなるべく多くの手段で共有したい。そう思い、今回も実況中継シリーズを弊社テックブログで行います。実況中継シリーズというのは、プレゼンをブログで再現するアレです。なお、実際のプレゼンは動画になってYoutubeにアップロードされております。builderscon公式サイトのセッション詳細ページからもご覧いただけますので、よろしければそちらも合わせてご

griefworker 2017/03/23

mvvm
flux

リンク

Reduxの正しい解釈の話

2016年の課題は状態遷移の管理だったと思う。そのアンサーとして、Fluxのような実装におけるStore相当にアプリケーションの状態をほぼすべて管理させるReactのようなVirtual DOMを搭載したビューの実装を透過的なユーザーインターフェースとして扱うこの2つの組み合わせにより、アプリケーションの状態と描画される画面が (ほぼ) 参照透過的になる。というのがFluxとReact以降のパラダイムだと思う (理論として) 。このパラダイムなら、エラーの発生時にアプリケーションの状態を表現するJSONをエラー収集サービスに送るようにして、簡単にバグを再現したりできるし、状態の遷移をテストしていくことで、クラッシュするようなバグのうち大半を検出できる。Fluxの問題そこで問題が出るのが、Action(Creator) とReducer (Store#reduce())の2要素間のル

griefworker 2017/01/27

flux
redux

リンク

Walts - Angular 2向けFluxライブラリを作った - Qiita

この度、Waltsというライブラリを開発した。ウォルツとも読めるが、ここはワルツと呼んでもらいたい。View -> Action -> Store、この三角の動きを三拍子に見立てて名付けたものだ。 crescware/walts 数々の検証や他のライブラリの知見を経て開発に着手したのが、Angular2用を意識して設計したFluxライブラリ"Walts"である。他のライブラリの知見や昨今のFlux事情については前日の記事にて綴ってある。これは2016年4月に開発を始めており、それまでに私が経験してきたフロントエンドの難点や当時の案件の問題点、反省点などを数多く活かしたものとなっている。Almin.jsとも開発時期が近いようだが、全くあずかり知らぬところで開発しており、結果的にはAlmin.js側が先出しになったのでそちらも参考にしている。 DDD, CQRS, Redux, RxJS,

griefworker 2016/10/18

リンク

どうしてWaltsを開発したのか - そして昨今のFlux - Qiita

まずFluxとはなんだろうか。Fluxの解説はすでに多数掲載されているが、ここでは﹁データフローを一方向としたアーキテクチャ﹂と定義したい。そもそも、FluxというのはObserverパターンにちょっとした規則を設けて、かっこいい名前を与えたに過ぎないのだが、現代のフロントエンドはこのFluxを見事に受け容れた。なぜか。それは開発者が秩序を求めたからである。これは、拡大し続けるフロントエンド・サイドの開発規模に対して、従来のMVC、正確には複数のViewと複数のControllerが相互にデータを受け渡し合うアーキテクチャがスケールしなくなったことに起因する。︵ここではMVCを厳密に定義していない。GUIアーキテクチャについてなのかバックエンド・アーキテクチャについてなのか判然とさせないまま、俗語的に用いている︶シングルトンという名でごまかした巨大なグローバル神オブジェクトを至る所で

griefworker 2016/10/18

リンク

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

このエントリーは読者としてスマートフォンアプリ開発者とWebフロントエンドエンジニアを想定して書いています。CROSS2016に出るので、最近の自分の考えを整理しておく。最近ReduxのSwift実装であるReSwiftを使って開発している。使った感想なども最後の部分に書いたけれど、このエントリーの本題はアプリの状態管理の話。アプリは大きなシングルトン iOS、Android共にアプリを実装しようと思うと大抵シングルトンが必要になる。各ViewController内をまたがってデータを共有したいというユースケースが多いからだ。例えばユーザーのログイン情報を集約するUserManager コンテンツへのいいね情報を集めるLikesManager ブックマーク情報を集めるBookmarkManager などなど。もちろんアプリの内容によってこれらの顔ぶれは違ってくると思うけれど、大抵U

griefworker 2016/02/03

swift
flux

リンク

Fluxフレームワーク戦争の現状確認（後編） - マルシテイア

この記事は仮想DOM/Flux Advent Calendar 2015の25日目……に入れようと思ってたけどもう埋まってた……。オマケということで頼む！！！！！24日目は JavaScript - 実践‥MagJS で TodoMVC - Qiitaでした。メリークリスマス！！！！！！！！！！こんにちは id:amagitakayosi です。みなさん今月もFlux 書いてますか？僕はオレオレ実装をIsomorphic対応したけど昨日Revertしたところです！！！！！ウオー！！！今日は↓12/2の記事↓の続きを書いていきます！ amagitakayosi.hatena blog.com もくじ前回のあらすじflux-utils Container vs View Cycle.js flux-challenge Rx系 thisless-react, Yolk DDO

griefworker 2015/12/26

リンク

仮想DOMで魂が震えてから一年、仮想DOMとFluxの今 - Qiita

なぜ仮想DOMという概念が俺達の魂を震えさせるのかから一年、みなさまどのようなフロントエンドをお過ごしでしょうか。僕はひたすら過去資産をリファクタしています。需要の雰囲気色んな所に書きましたが、去年僕が仮想DOM AdventCalendar をやったのは、﹁僕自身がproductionで使いたい﹂ので、﹁Reactまあいいよね﹂的な雰囲気を作って外堀埋めるのが目的でした。そして、その目的はおおよそ果たされたと言ってもいいでしょう。ご協力ありがとうございました。僕自身はKobito for Windows でReactを使ってみて、そのノウハウを公開したり、今年前半は色々とアウトプットをしていましたが、後半はSpecificなアプリケーションドメインを記述することが多くて、あまりアウトプットする内容がなくなってました。取り敢えずは、新規のプロダクトなら採用してもよい、という雰囲

griefworker 2015/12/02

リンク

Swiftで型安全なFluxアーキテクチャを実現する - Qiita

iOSアプリ開発でもFluxしたい WebアプリケーションのフロントエンドをReact + Fluxな構成で開発すると、若干コードが増えて面倒にはなりつつも、ビューの状態やデータの流れが明示的になってとてもわかりやすいなと改めて感じてます。 iOSアプリでもこういうことがやりたいのですが、基本的にFluxは考え方に過ぎないので必要な実装は自分でやらないといけません。なので作ってみました。 https://github.com/yonekawa/SwiftFlux 使い方基本的には必要なAction protocolとStore protocolを実装したクラスを作り、DispatcherとEventEm itterを使ってView - Action - Store - View の単方向データフローを作るだけです。詳しくはREADMEをご覧ください。 //: Step 1: Actio

griefworker 2015/08/04

リンク

yahoo/fluxible による SPA + Server Rendering の概観

Single Page Application + Server Rendering yahoo/fluxible を使って、Single Page Application と Server Rendering の良いとこ取りのアーキテクチャを目指す。ある程度の複雑性と引き換えに、双方の利点で双方の欠点を打ち消し合うことができるため、全体的には良好なユーザーインタラクションを期待できる構成。なぜ Single Page Application なのか画面遷移時するたびにJavaScript/CSS のパースと評価をしなくて良くなる画面遷移時のトランジションを柔軟に適用できる画面遷移をまたがった実装が可能になる（あくまで可能になるだけ）なぜ Server Rendering するのか初期表示の Critical Rendering Path を短縮できる SEO における保守信仰

griefworker 2015/06/14

リンク

はてなブックマーク

タグ

関連タグで絞り込む (10)

fluxに関するgriefworkerのブックマーク (12)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第3週）

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス