アプリの外側とのやりとりを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つのドライバー
cycle.jsでのMVI分割時にどう考えてるか - ✘╹◡╹✘
実装していくうちにレイヤやシステムの境界に対する認識が変わってきたので現状を整理。 Intent アプリ外部から受け取った入力をアプリ内部で使える語彙・データ形式に変換するためのアダプタ。アプリ外部からの入力を解釈して、アプリに何をしてほしくてそれを入力したのかを判断し、その要求をModelに伝える。「xxxが起こった」という形式ではあまり良くなくて、「xxxしてほしい」という形式になるのがベストという理解をしている。 例: ボタンがクリックされたので記事を作成してほしい (DOM経由の入力に反応する例) 例: 記事が作成されたので記事を表示するページに遷移してほしい (HTTP経由の入力に反応する例) Model Intentからの入力をもとに状態の管理を行う。状態は変数に格納するとかではなくて、Observableの中に生き続ける。Elixir/Erlangやったことがある人は、Age
cycle.jsを使うアプリのコード分割方針の例 - ✘╹◡╹✘
前の記事でcycle.jsについて少し紹介したものの、いまから始める人のことを考えると日本語の情報が無くて大変だろうと思ったので、何か説明出来ることがないか探した。多分使いはじめると途中でコードの分割方法について困ると思うので、いま開発しているエディタアプリではこうやっているよというのを書く。 概観 エディタ領域のコードは重いので左側2枚のサイドバーの部分のコードだけ抜き出して書くと、現状こういう感じのファイル構成になっている。 . |-- entities | |-- sheet-group.js | `-- sheet.js |-- index.html |-- index.js |-- intent.js |-- intents | |-- load-sheet.js | `-- load-sheets.js |-- model.js |-- models | |-- panes-c
エディタの実装をcycle.jsでMVIベースにしてみた話 - ✘╹◡╹✘
最近Electronでエディタをつくっており、最初はReact.jsを使いながらゆるいFlux風の設計でつくっていたのを、cycle.jsを使いながら一部をMVI風の設計に置き換えてみた。400行程度の一画面のコードだったので3時間ぐらいで置き換えられて、前よりも責務が適切に分割されるようになったので、本体部分も次の機能追加時に置き換えようと思っている。 とりあえずプレビュー画面だけ置き換えた 置き換えたのは、編集中のファイルを別画面でプレビューとして表示する画面で、ただプレビューするだけの機能のほかに連続したスライドとして表示するプレゼンテーション機能もある。1つ前のブログ記事を見てもらうとわかりやすいと思うけれど、次の画像のようなやつ。ボタンをクリックしてモードを切り替えたりキーボードを使って移動したり、またエディタ側でファイルの内容が書き換わったりと、それっぽく言えば幾らか動きのある
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
