タグ

fluxに関するmkwtysのブックマーク (13)

  • [PDF]A Brief History of Chat Services

    8x8 Sameroom Service End of Life Back Loading. Please wait...

  • AlminでFluxアーキテクチャをやってみる

    AlminでFluxアーキテクチャについてを見ていく話です。 AlminはいわゆるFluxライブラリ的なものですが、ドメイン駆動設計(DDD)を行うにあたって既存のReduxやFluxでは上手くレイヤー分けをやりにくい部分がありました。 この辺の経緯については以前スライドやドキュメントにまとめてあるので、以下を参照してください。 azu/large-scale-javascript: 複雑なJavaScriptアプリケーションを作るために考えること 複雑なJavaScriptアプリケーションを考えながら作る話 この記事では、実際のサンプルコードを見ていきながら、Flux的なデータフローについて見ていきます。 Alminでカウンターアプリを作る このサンプルではAlminを使って次のようなカウンターアプリを作っていきます。 次に英語のチュートリアルもあるので参照してください。 Counter

    AlminでFluxアーキテクチャをやってみる
  • Reduxの正しい解釈の話

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

  • React/Fluxにおける問題とReducerが切り開く道 | FAworksブログ

    私がReact/Fluxアプリケーションを書いてきて、もう1年になる。Flux開発の1年を振り返ってみると、このFluxというものが便利だと、はっきり言うことができる。過去は「こんなイベントチェーンなんて触ってないよ」という日々だった。取り組んできた全てのFluxコードベースは綺麗だったし、デバッグ可能で、メンテナンスも容易にできた。 Fluxに関しては、インタラクティブな金融チャート、リアルタイムのテーブル絞込み、いつものCRUD系のものから複雑な非同期要求チェーンにいたるまで、遭遇してきたあらゆる問題を解決することができた。Flux最大の長所の一つは、その普遍性だ。絶対的に簡潔で美しくなることは決してないが、決してハッキングすることもない。大規模コードベースにおいては良いことだ。複雑なUIに取り組む際にも、同じ考え方を当てはめると非常に効果的となる。 良いことづくめ? もちろん、そんな

    React/Fluxにおける問題とReducerが切り開く道 | FAworksブログ
  • FluxとDDDの統合方法 - かとじゅんの技術日誌

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

    FluxとDDDの統合方法 - かとじゅんの技術日誌
  • Reactを用いたアプリケーションアーキテクチャ:Fluxを再考する | POSTD

    他のフレームワークやライブラリから React に乗り換える人たちは、「ReactUIのレンダリングに関する問題しか解決しておらず、状態管理とアプリケーションアーキテクチャの選択は開発者に委ねられているのだから、どうやってアプリケーションの状態を管理したらいいのか?」 と疑問に思う傾向があります。FacebookはReactのレンダリングモデルに適している、 Flux と呼ばれるアーキテクチャを勧めています。 この記事では、UIレイヤとしてReactを用いてJavaScriptのアプリケーションの状態を管理する方法を探り、 Om のような ClojureScript ライブラリのアイデアを用いてFacebookのFluxの抽象的なフレームワークを作り変えてみたいと思います。 Fluxの核となる考えは、 データは一方通行で流れるべき というものです。これによってアプリケーションの論証が簡単

    Reactを用いたアプリケーションアーキテクチャ:Fluxを再考する | POSTD
  • Arda - MetaFluxなフレームワークを作った - Qiita

    僕はIncrements(このQiitaの会社)に入社して以来、KobitoのWindows版を作っていて、その中枢の画面遷移と状態管理をライブラリとして抜き出した。それがArda。 基的には昨日発表した https://speakerdeck.com/mizchi/real-world-virtual-dom というスライドに書いたとおり。 mizchi/arda Ardaの概要 Ardaの目的はFluxの概念をベースに、画面遷移と状態とシーンをベースにしたヒストリ管理、その際のDispatcherのコンテキスト切り替えを行うことを主な目的としている。 CoffeeScriptでの最小構成だと次のようなコードになる Arda = require 'arda' # Arda.Component extends React.Component class HelloComponent ex

    Arda - MetaFluxなフレームワークを作った - Qiita
    mkwtys
    mkwtys 2016/05/01
  • Fluxの枠にURLルーティングを収める試行 - saneyuki_s log

    JSer.info 200回記念祭の懇親会でざっくりアイディアだけ話していた記憶(酔っ払っていたので正確には覚えていない)なんだけど、実際に必要になったので試しに作ってみたという話。 モチベーション Fluxパターンを用いた設計を行なっている場合というのは往々にしてSingle Page Applicationであるので、URLに基づくルーティングを要しない、純然たるアプリケーションなケースが多い。だが、アプリケーションの性質によっては、パーマネントリンク的な機能の再現をしたいことがあり、ルーティング機構が欲しかったりする。 で、そういう場合については語られてる事例をあんまり見かけなかったので、作ってみた。 デザイン Storeに基ロジックを閉じ込めるのは変わらない URLに基づく履歴情報は、ユーザーインターフェースの一種と捉える。ので、Viewと考える 使ったライブラリ 基要件として

    Fluxの枠にURLルーティングを収める試行 - saneyuki_s log
  • ReactとFluxのこと // Speaker Deck

    http://inside.pixiv.net/entry/2015/04/27/170944

    ReactとFluxのこと // Speaker Deck
  • Fluxで複雑な状態の変化を予測可能にするiOSアプリ開発

    Reactive Swift Meetup http://wantedly.connpass.com/event/29039/

    Fluxで複雑な状態の変化を予測可能にするiOSアプリ開発
    mkwtys
    mkwtys 2016/04/15
  • My thought about beyond flux

    My personal note about beyond flux pattern to design an application architecture.

    My thought about beyond flux
  • 8 no-Flux strategies for React component communication

    In React, one of the first big issues that comes up is figuring out how components should communicate with each other. What's the best way to tell Component1 that Component2 was clicked? If you start to dig a little, you'll get a ton of answers. Sooner or later Flux will be mentioned, which will only raise new questions. Can I solve my communication issue with the Flux architecture? Is Flux necess

    8 no-Flux strategies for React component communication
  • How to work as a Team

    autoscale: true How to work as a Team 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 目的 新規でそこそこ複雑なウェブページを作る(アプリに近い) ある程度柔軟に拡張でき、メンテできるような設計にしたい 無難にReact + 何かでちゃんと設計して作っていきたい この設計部分をどう決めていくのかという話 現状 チームにReact/Flux/Reduxを触ったことがない人が多い どれが(主にView以外の設計)ベストかは分からない Flux的な部分の話 ものごとは変わる。 混乱は変わらない 混乱の原因 情報過多 情報不足 適切でない情報 上記の組み合わせ! via P21 今日からはじめる情報設計 情報の共有 情報不足 そもそもReactなどを知らない人には知ってもらう必

  • 1