RxJSで副作用を扱うにはどうするか - Schedulerを交えて - saneyuki_s log
Rx.Scheduler RxにはSchedulerと呼ばれる主要概念がある. 値がpushで飛んでくるというRxのインパクトの後ろに隠れがちなSchedulerではあるが, これにより, 処理系のスレッドモデル（並行性）と時間軸にまつわるタイミングの制御を統一的に扱えるようにしている. 後続へのoperatorへの値の送出タイミングの制御, Observableの処理スレッドの指定, タイマーのモックへの差し替えなどがSchedulerによって実現されている. さてJavaScriptの場合, 原則的には単一スレッドの世界になる. Javaや.NETの場合とは違い, RxのSchdulerの役割は回り続けるイベントループ抽象となる. 永久に回り続けるイベントループの中で, どの時点で処理をdispatachするかがSchedulerの役目だ. JavaScriptの世界にはメモリ空間を共
銀の弾丸は川から流れて来ない - saneyuki_s log
The Evolution of Flux Frameworks — Mediumを読んだ。自分がここ3ヶ月～半年くらい考えてたことと殆ど一緒で、若干の安心感を得たり。実装論の話も概ね同意ではあるのだけれど、自分は必ずしも同意しかねる面がある。 今のメモリマネージド言語のトレンド、特にクライアントアプリケーションの存在を想定したアーキテクチャは、C#が筋道を立てた実践理論に追随してる面があるので、過程はどうあれ、彼らの先端スタイルに近づいていくことになると思うのよね。 Fluxパターンの話をすると、あれが偉かったのは「疎結合すると色々楽になるから、オブザーバーパターンにして、コマンドパターン使って、コマンドは単方向にすると破綻しにくい割に弄りやすいよ」ってのを、フレームワーク症候群に陥っていた凡百なWebクライアントサイドに、一発、投げつけた辺り（というのは半年くらい前に書いたな……）。
RxJSをもくもくしてReactivePropertyの価値らしきものを気づかされた話（仮） - saneyuki_s log
Reactive Extensions JS port（RxJS）をもくもくしていた結果、C#界隈がReactive Propertyを作り出した理由が（なんとなく）わかってきた。 Rxの流儀にのっとれば、ある値を使おうとする場合、その値を生成するObservableの結果を受けて、そのObservableも同様に……とObservableの依存関係を作っていく必要がある。 Rx.Observable.do()メソッド中に、関数外のグローバル変数などを副作用なmutateをさせてもいいが、これは基本的によろしくない。Rxで実行される各Observerが、一体どのタイミングが動作するかの順序保証が本来的には存在しないためだ。イベントループがひとつしかない & Workerは完全にメモリ空間が分割されたアクターライク & Rx.SchedulerもDOMのイベントループ原則に則るJavaScr
ES5の範囲でOption<T>型を表すライブラリ、option-t を作った - saneyuki_s log
動機 初期状態で未選択なラジオボタンがあるようなフォームを作っている場合、ラジオボタンに対応するモデルの値を「この値は未選択である」というのをJSで表現するのは結構面倒くさい。チェックボックスであれば, booleanのどちらかで状態が確定するが、ラジオボタンだと取りうる値は複数になるし、初期状態で選択されているか否かの問題が発生する。選択されていない状態を専用にフラグとして持つのは気持ち悪いが、かといって、未選択の状態を-1や9999ないしnull、undefinedで表現するのは危うい。コードを書いた本人しかわからない。 RustやScalaなどのようにOption<T>/Maybeがある言語なら、こんなまどろっこしい思いはせずに、明示的に値の有無を表現できる。 というわけで、ないなら作ってしまえば良いじゃないメソッドで作った。 Option<T>型について 私が説明するよりもわかりや
Fluxとはなんだったのか + misc at 2014 - saneyuki_s log
はじめに VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita を読んでいる前提で話を進めます。 結局”Flux”なんだったのよ 詳細については過去に自分が覚え書きを書いたのでそっちを読んでいただけると良いと思うけど、あれは 「MVCの変形亜種に、オブザーバーパターンを乗せ、データを単一方向に流すことを規定した」ものに、Facebookが命名したものでしかない。極端に目新しいものでもない。その最大の功績はアーキテクチャそのものではなく、「試行錯誤を踏む中で誰もが一度はやっていたであろう似たようなことを上手く実践法則としてまとめた上で、共通認識としての名前をつけた」こと。概念に名前をつけて共有することで、事前説明が簡略化され、本質的な問題に取り組む時間が増える。これをFacebookのブランド力でねじ伏せるように広めたことこそが重要かつ評価すべきポイン
JS界隈にIDLもしくはd.tsを併記・同梱する文化が根付いてほしい - saneyuki_s log
前置き 最近、ウェッブフロントエンドエンジニアらしく各種JavaScriptのライブラリを眺めて、調査・選定しているのだけれども、その過程を通じたこととして、多くのライブラリが、ドキュメントのAPIの説明が貧弱すぎる。 jQueryのドキュメントが腐っているというのは既に広く知られた事実であると思うし、そうでないならば積極的に既知の事実として腐っている事を広めて行くべきであると強く思うが、jQueryに限らずとも、ドキュメントが満足な形で整理されていないのをひしひしと感じる。 この手のものでよくドキュメント化されている部類だと感じるBackbone.jsですら、仮引数の名称と定義のみしか書かれておらず、肝心の引数が備えるべきメンバや、引数の型情報が明示的に記述されていない。そのため、APIを俯瞰し、自分の欲しい情報がどこに詰まっているのか・どのように取得できるのか・DOM標準もしくはECM
Web ComponentsとHTMLのセマンティクスと自分の将来予測 - saneyuki_s log
Custom Elements W3C Editor's Draft 18 June 2014を元に書いた。 昔、関連仕様のどこかで今回と似た話を見た記憶が有るんだけど、どこにあったか忘れたので、改めて自分の解釈として書いてみる。 Custom Elementで既存の要素を拡張する Web ComponentsのCustom Elementは独自の要素を定義することができるのだけど、新要素の導入以外にも、実際には既存の要素を拡張するという使い方ができる。 ElementRegistrationOptionsの、extendsプロパティというのがそう。 specの例では以下のようにp要素を拡張している（引用）： document.registerElement('x-foo', { prototype: Object.create(HTMLParagraphElement.prototype
ES6の前にES5のベストプラクティスを改めて考えたい - saneyuki_s log
歴史認識 だいたい以下のような流れだと認識している。 IE8以前を含むECMAScript 3暗黒時代があった この時代をベースにベストプラクティスが構築 + HTML5ブームが発生した 暗黒時代なんで結構つらいし、IE9じゃないとECMAScript 5使えないし、結局辛い CoffeeScriptを筆頭としたaltJS一派に救いを求めた（結局Coffeeは一過性のカフェインだったわけだけど） 気がついたらECMAScript 6が来そうになっていた ES6でのsyntaxの拡張・標準ライブラリの増強はカッコいい 気がついたらES5当たり前、ES6も使えそうな世界が来そうになっていた（希望的観測が多分に含まれているのは暗黙の了解と化している） ES6、altJSの次のナウい世界として注目を集める だいたいこんな感じで、ECMAScript 5を用いたベストプラクティス的な物が存在しない、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fluxアーキテクチャの覚え書きを書いた - saneyuki_s log