タグ

vuexとreduxに関するalluserのブックマーク (3)

  • Vue.js と Redux が出会った | DeNA DESIGN BLOG

    あるところにプロトタイピングを繰り返した結果、1 ファイルにベタッと書かれていたソースがありました。 なんとかリリースを終えて、運用フェーズに入ったことものの、つらいソースが残されたのです。 ファイルを再利用可能にするためコンポーネント化を進めることを決意します。 最初はとても大きな単位でコンポーネントを作っていたため、大量の状態を 1 コンポーネントが抱えていました。 コンポーネントの粒度を細かくしていくと、だんだん props のバケツリレーが増えてきます。 親から子へ、子から孫へ、孫からひ孫へ…。 2way binding してるバケツリレーは、もう追っていくのがツラい! ただリレーしてるだけで、中間のコンポーネントでは使ってないものも出てきました。 1 箇所直すと、他に影響が出て怖い。 これは Flux, Redux の出番だ! HTML5 とか勉強会の資料を見て、書きたくなった!

    Vue.js と Redux が出会った | DeNA DESIGN BLOG
  • Repositoryの後ろにネットワーク越しのシステムがあることの是非からRedux的世界へ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    twitterで言ってたことを少し修正してまとめ。MVVM + Layered Architectureの文脈です。 最近、Repositoyとして抽象化しておけばそのデータがメモリ上にあるかそれともDB上にあるかネットワーク越しにあるか意識しなくていい、というのは嘘だと思ってる。パフォーマンスの観点除いても。 というのは、リポジトリが「非同期クエリ」を受け付け始めると、ReadStackの複雑性が跳ね上がるというのがあるからなんだけど、そもそもRepositoryへのクエリは必ず非同期であるというインターフェースにすればこれは問題にならないのかな リポジトリを基非同期に設計してもいいんだけど、そうすると同期的な表示を求めてくるUIプラットフォームと相性悪くなるんだよな たとえばMVVMで考えると、モデルのイベントを購読して、イベント来たらクエリ投げてモデル以下にある状態を読み出してきて

    Repositoryの後ろにネットワーク越しのシステムがあることの是非からRedux的世界へ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • ReactとRiotとVueを触ってみた感想(暫定版) - Smoky God Express

    前置き なんか新しくつくんべ、っていうときにフロントのフレームワーク(ライブラリ?)を何にするか迷ったんで調べた。 机で調べてたらわかんなかったんで書くべって言ってとりあえず3種類ざっと書いてみたのでその構成と感想を記録しておく。 特に入門記事とかではないのでコード片の類はない。 比較対象 React A JavaScript library for building user interfaces | React Riot.js Riot.js — A React-like user interface micro-library Vue.js vue.js 全部データフロー回りのライブラリの使用を前提とする。 界隈で一番スタンダードっぽいのを選んだつもりだけどRiotがわからん。 React + redux react-redux Riot + RiotControl jimspark

    ReactとRiotとVueを触ってみた感想(暫定版) - Smoky God Express
  • 1