10分で実装するFlux
10分で実装するFlux 自己紹介 azu @azu_re Web scratch, JSer.info Flux /flˈʌks/ Fluxとは Facebookが提唱したSmalltalk MVCの焼き直し CQRS(Command Query Responsibility Segregation)と類似 データが一方通行へ流れるようにするアーキテクチャ ウェブUIについてそれを適応する 今日の目的 小さなFluxの実装を作りながらFluxついて学ぶ Fluxの特徴: Unidirectional data flow 本当にデータが一方通行に流れるのかを確認する Fluxでよく見る図 登場人物 何か色々いる Action Creators, Dispatcher, Store, React Views... Dispatcher = EventEmitterと今回は考える もっと実装的
どうしてWaltsを開発したのか - そして昨今のFlux - Qiita
まずFluxとはなんだろうか。Fluxの解説はすでに多数掲載されているが、ここでは「データフローを一方向としたアーキテクチャ」と定義したい。 そもそも、FluxというのはObserverパターンにちょっとした規則を設けて、かっこいい名前を与えたに過ぎないのだが、現代のフロントエンドはこのFluxを見事に受け容れた。なぜか。それは開発者が秩序を求めたからである。 これは、拡大し続けるフロントエンド・サイドの開発規模に対して、従来のMVC、正確には複数のViewと複数のControllerが相互にデータを受け渡し合うアーキテクチャがスケールしなくなったことに起因する。（ここではMVCを厳密に定義していない。GUIアーキテクチャについてなのかバックエンド・アーキテクチャについてなのか判然とさせないまま、俗語的に用いている） シングルトンという名でごまかした巨大なグローバル神オブジェクトを至る所で
クロージャってどんなときに使うの？ ～ 利用場面を ３つ 挙げてみる - Qiita
結論を先にまとめると、以下の３つです。 1. グローバル変数の宣言をなるべく減らしたい場合 2. ユーザが引数を与えてカスタマイズ可能な自由度の高い「関数」を生成したい場合 3. 前回、呼び出されて実行されたときの演算結果（値）を内部で保存して、次に呼び出されたときに、前回の結果（値）に対して、さらに同じ処理（演算）を行う関数を生成したい場合 以下、「クロージャ」の定義から、頭の整理まで、分かりやすい参考ウェブサイトへのリンクを張りつつ、見ていきます。 【 定義 】クロージャ takeharuさん Qiita記事（2013/07/22）「JavaScriptでクロージャ入門」 「自分を囲むスコープにある変数を参照できる関数」 Wikipedia 「クロージャ」 引数以外の変数を実行時の環境ではなく、自身が定義された環境（静的スコープ）において解決することを特徴とする。関数とそれを評価する環
【翻訳】リッチなWebアプリケーションのための7つの原則 - from scratch
はじめに この話はGuillermo Rauch氏が書いたhttp://rauchg.com/2014/7-principles-of-rich-web-applications/ という記事の翻訳です。許可を得て翻訳しています。 ここ最近Web業界を賑わしているSingle Page Applicationの必要性、HTTP2/SPDYといった技術、リアクティブプログラミングやIsomorphicデザインという考え方について包括的にまとめたすごく良い記事になっております。 最初に断っておきますが、ものすごく長いです。各セクションがわかれているので時間がない方はセクションごとに書かれたtl;DRとまとめを読むだけでも参考になるかと思います。 ちなみに明日のNode学園祭には、本記事を記述したGuillermo Rauch氏が見えるので、そこで詳しく聞いてみるのもいいのではないでしょうか。
Webフロントエンドに従事するお前らはいい加減高頻度イベントとレイアウトとスタイリングの付き合い方を考えろ - Qiita
もうなんかこの際マジで言わせていただくんですけど、知ってるか知らないか分かりませんが世の中にはすごい頻度で呼ばれうるDOMイベントって言うのがいくつかあるわけですよ 例えば scroll mousemove, touchmove devicemotion 辺りですよ。 で、高頻度で呼ばれるって言うことは必然的に処理量が増えるって分かりますよね？？？？？while(1) {}じゃないとはいえUIスレッドに十分影響を与えうる頻度で呼ばれる訳です。分かりますよね？？？？？？？？ そうなると当然そのイベント内で重い処理を行えば人間が認識できるレベルでのレスポンス遅延が起きるっていうのはご理解できますよね？ 重い処理っていうのはまぁ想像出来るとは思うんですが例えばよくあるのが DOMのレイアウトプロパティへのアクセス offsetTop、offsetLeft、offsetWidth、offsetHe
小さいライブラリを採用する - mizchi's blog
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
大規模 JavaScript その設計と実装と現実
ワイヤーフレームとはどういうものか？という概略 ワイヤーフレームだけでは説明しきれないところをどう補うか、が課題 Adobe XD Meeting #05での発表内容です
React.js and Dynamic Children - Why the Keys are Important
React.js and Dynamic Children - Why the Keys are Important … and check why 5600+ Rails engineers read also this React.js and Dynamic Children - Why the Keys are Important Recently I’ve been building a pretty dynamic interface based on google analytics data for one of our customers. There was a bug that I couldn’t quite figure out because of my wrong understanding of how react works. In the end it
Why does React scale? - JSConf 2014
min(Time To Find Root Cause) We want to reduce the number of bugs in the system but it’s not really actionable Instead, we found that focusing on minimizing the time to find the root cause of bugs was a better proxy to meet our goal Once you have a repro case, you want to know what code was being used to generate this value To do that, you are going to right-click/inspect element and look at it in
OSCON - React Architecture
型付け力を強化するための Hoogle のすゝめ / Boosting Your Type Mastery with Hoogle
ストリーム表現とその変換 - ✘╹◡╹✘
データをストリームとして表現する方法と、ストリームを変換する方法を紹介する。 ストリームはメッセージが流れる川である Pub/Subメッセージングモデルでメッセージを流すためのオブジェクトのことをストリームと呼ぶことにする。ストリームにはメッセージをPublishでき、またメッセージを受け取ったときの処理をSubscribeできる。例えばキーボードからの入力をPublishして、内容をコンソールに出力するような処理をSubscribeできる。 kamo.jsでストリームを表現する ストリームについて説明するために、kamo.jsというストリームを表現するためのライブラリをつくった。kamo.jsは、ストリームを作成するためのkamo.Streamというコンストラクタ関数を提供する。このコンストラクタ関数から作成されたオブジェクトは、publishとsubscribeというメソッド(※プロパ
The Little Book on CoffeeScript - Classes
クラス JavaScriptのクラスは純粋主義者にとってニンニクがドラキュラに対して与えるものと同様な影響を持っていました。とはいえ、正直に言ってあなたがそのような傾倒をお持ちでしたらCoffeeScriptの本を呼んだりはしないでしょう。しかし、クラスは他の言語と同じようにJavaScriptでもとても便利であると判明しました。そしてCoffeeScriptは素晴しい抽象化を提供します。 その裏では、CoffeeScriptはJavaScriptのネイティブなprototypeをクラスを作成するのに用いています。少しの構文糖を静的なプロパティの継承とコンテキストの永続化のために用いています。開発者としてのあなたに見えるのはclassキーワードだけです。 class Animal この上の例ではAnimalがクラス名であり、かつ結果としてインスタンスの作成に用いる変数です。裏側ではCoff
(* programming -> girl -> ? *) | 業務アプリ実装にFRP使ってみた
Bacon.jsという、Functional Reactive Programming のFrameworkを使ったJava Scriptライブラリを使って業務アプリを書いてみました。関数型の考え方をふんだんに使いつつも、GUIなどのユーザ入力を伴うような処理に柔軟に対応している、マイナーながら優れたライブラリです。 実際にBacon.jsを使って実装してみて、何が良かったかなってところを、 ちょっと素人なりに色々と考えてみました。 1. 出てくるワードが直感的であるBaconでは、EventStream, Propertyなどといった独自のワードがいくつか出てきます。 ライブラリを読んで色々と使うのは大変だなあと個人的にはよく思いますが、Baconに関しては、新しい概念を取り入れているのにも関わらず、非常に直感的且つイメージがつきやすいワードを選択しているので、頭の中に構造を描きやすい仕
Bacon.jsで眺めるFunctional reactive programming - ryiwamotoのブログ
JavaScriptのFunctional reactive programming(FRP)ライブラリ「Baconjs」を使ってFRPの考え方を勉強してみたメモ。 なお、このメモはFRPの勉強のためにいくつかの資料をざっくりまとめただけなので、Bacon.jsの使い方は解説しない。 なのでBacon.jsの使い方を知りたいだけなら元記事を読んだほうが良い。 Bacon.jsのReadme Bacon.jsのチュートリアルブログ(これとかこれ) 三行で FRPでは従来のプログラミングでは間接的にしか扱えなかった「徐々に変化する値」を第一級のオブジェクトとして扱うことができる。 さらに関数型のcompositionalな性質が合わさって素敵。 Bacon.jsは良いものだ。 従来のプログラミングでは時間とともに変化する値の扱いが難しい 例えば次のフォームの例を考えてみる。 <form> <i
【翻訳】あなたが求めていたリアクティブプログラミング入門 - ninjinkun's diary
original: The introduction to Reactive Programming you've been missing (by @andrestaltz) (translated by @ninjinkun, reviewed by @ma0e) あなたはリアクティブプログラミングと呼ばれる新しい方法が気になっている。 勉強するのは大変で、良い教材がないのでさらに難しい。私が勉強を始めたときは、まずチュートリアルを探した。見つけたのは一握りの実践的なガイドだけ、しかもそれらは表面をなぞっているだけで、リアクティブプログラミングのアーキテクチャ全体像を構築しようとしてはいなかった。ある関数を理解するのに、ライブラリのドキュメントは役に立たないことがある。 これを見て欲しい。 Rx.Observable.prototype.flatMapLatest(selector,
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Facebook の決断：MVCはスケールしない。ならば Flux だ。
GitHub - azu/large-scale-javascript: 複雑なJavaScriptアプリケーションを作るために考えること
SLOBSERVER - L'actualité de Second Life