Electron, React, Fluxを使ってアプリケーションを作った - Qiita
Electron勉強会 #1で発表した、Electron, React, Fluxを使ってアプリケーションを作る話について解説する。 位置づけとしてはElectronのremoteでプロセス間通信を高レベルに扱うの続きにあたる。 概要 ElectronアプリケーションにFluxアーキテクチャを利用することは、レンダラプロセスの内部で処理が解決する場合において有効である。レンダラプロセス間で状態を共有したい場合、メインプロセスとレンダラプロセスでFluxアーキテクチャを二重化することでこの課題を解決できる。 しかしユーザ操作によってレンダラプロセスが終了された場合、Fluxアーキテクチャそのままでは正しくActionを通知することができない。複数のレンダラプロセスを立ち上げることに適応できるよう、Fluxアーキテクチャに変更を加えなければならなかった。 成果物 MisumiRize/GHCa
Electronのremoteでプロセス間通信を高レベルに扱う - Qiita
Electronでipcを使ってプロセス間通信を行うの続き。 概要 Electronではメインプロセスと個別のBrowserWindow上で走るプロセス（レンダラプロセス）の間はプロセス間通信でメッセージのやりとりができ、ipcモジュールとして提供されている。 remoteではプロセス間通信ををラップした高レベルな機能が提供されており、レンダラプロセスからメインプロセスのAPIを、あたかもレンダラプロセスのAPIとして存在しているかのように扱うことができる。 前提 BrowserWindow（レンダラプロセス）を立ち上げてHTMLを表示する部分までは終了しているものとする。 var app = require('app'); var BrowserWindow = require('browser-window'); app.on('ready', function() { var cur
NodeでInfratasterっぽいことができるTasteSpoonというNPMモジュールを作った - Qiita
TasteSpoon 動機 Infratasterは素晴らしいGemで、インフラの振る舞いをコードで表現できることはこの上なくありがたい。ただ、使っていると不便に感じるところもいくつかある。 RSpecにロックインされる RSpecの大量に存在するマッチャAPIで消耗する RSpec2からRSpec3で構文が変わって非本質的な部分で消耗する RSpec上で併用することの多いServerspecとコンテクストが混ざる RSpecでは待ち合わせの概念が入ると途端にコードがダサくなる 最後の「待ち合わせ」だけ補足すると、これはWebSocketなどの通信が確立することを確かめたい場合が例としてあげられる。infrataster-plugin-socket.ioを作った際、通信が確立できることを確かめるのに、こういうダサいコードを書くことになった。 タイムアウトの概念が存在して、マッチャAPIがシ
狭義のVirtualDOMと広義のVirtualDOM - Qiita
TL;DR VirtualDOMを狭義と広義に分けて定義すると、 狭義のVirtualDOMとは、実際のDOMを表象する構造体 広義のVirtualDOMとは、狭義のVirtualDOMに加えてdiff, patchメカニズム とすることができ、React.js（及びVirtualDOM実装と呼ばれるMatt-Esch/virtual-domやsegmentio/deku）がシンプルなのは後者を実装しているからである。 Ractive.jsとReact.jsはどう違うか、という話 なるほどRactive.jsのリポジトリにはvirtualdomという名のディレクトリがある。このvirtualdomディレクトリの中では、構造体をDOMへと投影するような実装がされている。このことを根拠に、Ractive.jsはVirtualDOMと呼ぶこともできる。 Ractive.jsにおける実際のDOM変
FluxをJest以外でテストする - Qiita
var mockRegister = MyDispatcher.register; var mockRegisterInfo = mockRegister.mock; var callsToRegister = mockRegisterInfo.calls; var firstCall = callsToRegister[0]; var firstArgument = firstCall[0]; var callback = firstArgument; Jestは基本全てがモックされるので、要は「Dispatcherのregisterに与えられた引数が観測できるから、Storeのcallbackを捕捉してテストしたい内容に合わせて適宜実行せよ」ということである。 この動作、SinonのSpyにも同じような実装がある。spy.firstCallやspy.getCallが定義されており、n度
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
