Passive/Reactive プログラミングの違いを学ぶ - Qiita
MVI (Model-View-Intent) を学ぶために、Cycle.js の Observable のチュートリアルから Passive と Reactive の違いの解説を翻訳しました。ライセンスは原文と同じ MIT ライセンスとします。筆者の André Staltz さんが公開しているスライド (How Reactive Programming can help reduce code spaghetti ) は補助資料になるでしょう。Staltz さんは「Reactive ではデータの変更は遠くから観察される」「Passive ではデータは遠くから変更される」とも述べています (twitter、Redux と RxJS の違いは？)。 モジュール Foo とモジュール Bar があるとします。モジュールは OOP クラスのオブジェクトもしくは状態をカプセル化するためのほかのメ
アプリの外側とのやりとりをModelから取り除く - ✘╹◡╹✘
変更前 これはクライアントサイドのアプリケーションの例で、Modelの背後でWeb APIやonpopstate/pushStateを利用しており、Modelが太くなってる様子。 HTTP History | ^ | ^ | | | | v | v | .---- View <-- M o d e l <-- Intent <--. | | `----------------> DOM -------------------' 変更後 Web APIもonpopstate/pushStateもアプリケーションの外側にあり、DOMと同レイヤに存在するものであると位置づける。アプリケーションの外界とのやりとりを行う、ビジネスロジックを含まないアダプタを、ドライバーと呼んで抽象化する。ドライバーには入力を受け取る機能と出力を購読させられる機能がある。いまつくってるアプリでは以下の2つのドライバー
MVI (Model-View-Intent) と MVC との違い - Qiita
Cycle.js の MODEL-VIEW-INTENT のチュートリアルから MVI (Model-View-Intent) と MVC (Model-View-Controller) に関する説明を抜粋して翻訳しました。原文のライセンスは MIT です。 「Passive/Reactive プログラミングの違いを学ぶ」 をあらかじめ読んでおくと理解が深まるでしょう。筆者の André Staltz さんは Flux、Redux などのアーキテクチャの比較や評価を UNIDIRECTIONAL USER INTERFACE ARCHITECTURES と NOTHING NEW IN REACT AND FLUX EXCEPT ONE THING の記事で述べています。 MVI (Model-View-Intent) について MVI は Cycle.js の main() 関数を3つの
Redux っぽく Rx で実装しようとして結果的に Cycle.js に惹かれる話 - Qiita
はじめに Flux のような unidirectional なアーキテクチャに興味があって、評判のよいものに触ってみた感じです。 実際に業務でやってみたことはないので、ガチ勢の方から見たらまだまだ甘いと思われる点が多々あるかもしれません。 TL;DR (投稿から一日たって少し考えがまとまってきたので追記) Redux の印象 before 思想は分かりやすい (Three Principles) アプリケーションの状態 (state) を単一の store で管理 state は read-only (直接更新できない), 更新は action の発行を介して行う state を更新する reducer は純粋な関数 でも action.type で switch する書き方が好きになれない Rx で簡単に re-implement できるとのことなので、 switch なしで書けるように
ES6、React、RxJS、Cycle.js に関する調査 - Qiita
React と Cycle.js を学び始めると、Twitter のつぶやきを含めて、こまごまごしたことを調べる必要があり、記憶力の限界を超えたので、自分の関心の変遷を振り返りながら、情報源をまとめました。ES6 の実装の課題とおよび将来の ES.next の標準化の動きについても併記しました。 プログラミングスタイル 新しい機能をなぜ導入するのかについて振り返るために QCon Tokyo 2013 の Douglas Crockford 氏の講演を文字に起こした記事 (前編、後編)を読んで印象に残ったことを抜粋しました。 スタイルは間違いを減らすためにある スタイルは個人の嗜好や自己表現のためではなく、間違いを減らすためにある。 わるいスタイルを採用する人の典型例は勉強不足な人、古い教育を受けた人、スリルを好む人、自己顕示欲家。 めったに起きないと思っていることはいずれ起きる。 エレガ
cycle.jsでのMVI分割時にどう考えてるか - ✘╹◡╹✘
実装していくうちにレイヤやシステムの境界に対する認識が変わってきたので現状を整理。 Intent アプリ外部から受け取った入力をアプリ内部で使える語彙・データ形式に変換するためのアダプタ。アプリ外部からの入力を解釈して、アプリに何をしてほしくてそれを入力したのかを判断し、その要求をModelに伝える。「xxxが起こった」という形式ではあまり良くなくて、「xxxしてほしい」という形式になるのがベストという理解をしている。 例: ボタンがクリックされたので記事を作成してほしい (DOM経由の入力に反応する例) 例: 記事が作成されたので記事を表示するページに遷移してほしい (HTTP経由の入力に反応する例) Model Intentからの入力をもとに状態の管理を行う。状態は変数に格納するとかではなくて、Observableの中に生き続ける。Elixir/Erlangやったことがある人は、Age
エディタの実装をcycle.jsでMVIベースにしてみた話 - ✘╹◡╹✘
最近Electronでエディタをつくっており、最初はReact.jsを使いながらゆるいFlux風の設計でつくっていたのを、cycle.jsを使いながら一部をMVI風の設計に置き換えてみた。400行程度の一画面のコードだったので3時間ぐらいで置き換えられて、前よりも責務が適切に分割されるようになったので、本体部分も次の機能追加時に置き換えようと思っている。 とりあえずプレビュー画面だけ置き換えた 置き換えたのは、編集中のファイルを別画面でプレビューとして表示する画面で、ただプレビューするだけの機能のほかに連続したスライドとして表示するプレゼンテーション機能もある。1つ前のブログ記事を見てもらうとわかりやすいと思うけれど、次の画像のようなやつ。ボタンをクリックしてモードを切り替えたりキーボードを使って移動したり、またエディタ側でファイルの内容が書き換わったりと、それっぽく言えば幾らか動きのある
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
