【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/04/11(月) 16:28:34.52

pythonやrubyやPHPと同じ土俵でjavascriptが使えるようになりました。
サーバサイドjavascriptについて語りましょう。

node.js - googleが開発したV8エンジン上で実行できる処理系
http://nodejs.org/
io.js - node.js 互換で Joyent の影響からの脱却を目指す処理系
http://iojs.org/
Rhino - JVM上で実行できる処理系
https://developer.mozilla.org/ja/Rhino

io.js の経緯
http://stackoverflow.com/questions/27309412/what-is-the-difference-between-node-js-and-io-js
javascriptはrubyと比較してもかなり速い
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&;lang=v8&lang2=yarv
基礎から学ぶNode.js
http://gihyo.jp/dev/serial/01/nodejs
node.jsの概要とアプリケーション開発の準備
http://gihyo.jp/dev/serial/01/realtimeweb/0002

前スレ
【node.js】サーバサイドjavascript 3【io.js】(c)2ch.net
http://echo.2ch.net/test/read.cgi/tech/1419673207/
【node.js】サーバサイドjavascript 2【Rhino】
http://peace.2ch.net/test/read.cgi/tech/1358937029/
【node.js】サーバサイドjavascript【Rhino】
http://toro.2ch.net/test/read.cgi/tech/1310087535/

**デフォルトの名無しさん** · 2017/04/02(日) 19:13:35.17

>>397
自己解決しました

**デフォルトの名無しさん** · 2017/04/02(日) 20:42:34.04

nodeたのしんでる？

**デフォルトの名無しさん** · 2017/04/02(日) 22:53:02.06

まだ勉強し始めなんだけどコールバック地獄を抜けたらPromiseラップ地獄が始まってる気がするゾ

**デフォルトの名無しさん** · 2017/04/02(日) 23:49:36.07

その先にはasync地獄が待ってるから早く進め

**デフォルトの名無しさん** · 2017/04/02(日) 23:55:00.71

Rxで脱出できるよ

**デフォルトの名無しさん** · 2017/04/03(月) 00:08:15.13

RxのAsyncSubjectってPromiseと比較してどんなメリットがあるんだ？
async/awaitで使えないから不便と思う

**デフォルトの名無しさん** · 2017/04/03(月) 00:37:17.85

callback地獄なんか近づかずにpromiseとasync await始めたほうがいい。
promise抑えてからじゃないとasync await使えないから、promiseは必須な

**デフォルトの名無しさん** · 2017/04/03(月) 00:44:19.88

rxはreact nativeあたりと組み合わせるとどうなんだろうね？
coldとhotって概念があったり意外とつまずきやすい。全てがstreamという概念は素敵そうだけどreactとうまく組み合わせられるんか？

**デフォルトの名無しさん** · 2017/04/03(月) 00:47:12.84

async使い出すとやってくるtry catch地獄

**デフォルトの名無しさん** · 2017/04/03(月) 00:50:42.75

コールバック地獄って無名関数でしか渡してないから問題なだけじゃね？

**デフォルトの名無しさん** · 2017/04/03(月) 01:10:13.39

fs.readdir(source, function(err, files) {
if (err) {
console.log('Error finding files: ' + err)
} else {
files.forEach(function(filename, fileIndex) {
console.log(filename)
gm(source + filename).size(function(err, values) {
if (err) {
console.log('Error identifying file size: ' + err)
} else {
console.log(filename + ' : ' + values)
aspect = (values.width / values.height)
widths.forEach(function(width, widthIndex) {
height = Math.round(width / aspect)
console.log('resizing ' + filename + 'to ' + height + 'x' + height)
this.resize(width, height).write(destination + 'w' + width + '_' + filename, function(err) {
if (err) console.log('Error writing file: ' + err)
})
}.bind(this))
}
})
})
}
})

**デフォルトの名無しさん** · 2017/04/03(月) 03:42:09.46

React + RxJSで興味ある人はこの辺でも見て
http://rudiyardley.com/redux-single-line-of-code-rxjs/
https://www.slideshare.net/jayphelps/rxjs-redux-react-amazing

**デフォルトの名無しさん** · 2017/04/03(月) 03:53:47.87

>>408
fs.readdir(source, func1)

var func1 = function(err, files) {
if (err) {
console.log('Error finding files: ' + err)
} else {
files.forEach(func2)
}
}
var func2 = function(filename, fileIndex) {
console.log(filename)
gm(source + filename).size(func4)
}
var func3 = function(width, widthIndex) {
height = Math.round(width / aspect)
console.log('resizing ' + filename + 'to ' + height + 'x' + height)
this.resize(width, height).write(destination + 'w' + width + '_' + filename, function(err) {
if (err) console.log('Error writing file: ' + err)
}
var func4 = function(err, values) {
if (err) {
console.log('Error identifying file size: ' + err)
} else {
console.log(filename + ' : ' + values)
aspect = (values.width / values.height)
widths.forEach(func3)
}.bind(this))
}
}

**デフォルトの名無しさん** · 2017/04/03(月) 15:48:27.07

>>409
redux学習中だけどRxJSと組み合わせると何が幸せになるん？

**デフォルトの名無しさん** · 2017/04/03(月) 19:33:34.98

RPとFRPの区別がついてない奴を馬鹿にして粋がれるとか

**デフォルトの名無しさん** · 2017/04/03(月) 21:16:06.10

>>411
RxJSのメリットは非同期の扱いを楽にしてくれること

RxJSとreduxを組み合わせるのは
一番よく使われてるフレームワークにのっかることで
Redux向けのツール類やノウハウなんかでそのメリットを享受するため

>>409の1つ目のリンクはRxJSだけでreduxと同じようなことをやってる例
2つ目は組み合わせて使う例

**デフォルトの名無しさん** · 2017/04/03(月) 21:22:08.20

>>410
少し訂正。問題は適切な名前をつけるのが難しいところにあると思うね。

var func1 = function(err, files) {
　if (err) {
　　console.log('Error finding files: ' + err)
　} else {
　　files.forEach(func2)
　}
}
var func2 = function(filename, fileIndex) {
　console.log(filename)
　gm(source + filename).size(func3)
}
var func3 = function(err, values) {
　if (err) {
　　console.log('Error identifying file size: ' + err)
　} else {
　　console.log(filename + ' : ' + values)
　　aspect = (values.width / values.height)
　　widths.forEach(func4.bind(this)))
　}
}
var func4 = function(width, widthIndex) {
　height = Math.round(width / aspect)
　console.log('resizing ' + filename + 'to ' + height + 'x' + height)
　this.resize(width, height).write(destination + 'w' + width + '_' + filename, func5)
}
var func5 = function(err) {
　if (err) console.log('Error writing file: ' + err)
}
fs.readdir(source, func1)

**デフォルトの名無しさん** · 2017/04/03(月) 23:44:03.74

electronというかjsでデスクトップアプリって流行ると思いますか?

**デフォルトの名無しさん** · 2017/04/03(月) 23:49:14.81

そもそもデスクトップアプリが今日日流行らんような

**デフォルトの名無しさん** · 2017/04/04(火) 00:42:57.27

>>413
非同期の扱いを楽にするって観点ならasync awaitで必要十分じゃないか。
RxJSならではのメリットを知りたい。

**デフォルトの名無しさん** · 2017/04/04(火) 00:47:36.02

>>415
reactnativeでデスクトップアプリが作れるようになったほうがいいと思うけどね。性能面でも。

electronで結構キラーアプリは出てるから使えて損はない。
chromeOSが復活しないかな。
アプリごとにchromeが中で動いてるのって無駄な気がするんだよね

**デフォルトの名無しさん** · 2017/04/04(火) 01:25:34.52

WEB+DB vol.97 の特集が、React

WEB+DB vol.94 の特集が、Kotlin, Electron

**デフォルトの名無しさん** · 2017/04/04(火) 01:35:05.25

>>417
>>409の2番目のリンク先を見て

**デフォルトの名無しさん** · 2017/04/04(火) 03:08:30.98

RxJSをみてるとJavaScriptにPromise入れるのは
もっと慎重にやるべきだったと思うね

**デフォルトの名無しさん** · 2017/04/05(水) 00:42:45.34

reduxは非同期処理入れるのにミドルウエアが必要でその中の候補としてrxjsがあるってこと？

非同期処理は多用するんだからミドルウエア無しで対応しろよ

**デフォルトの名無しさん** · 2017/04/05(水) 01:59:50.23

>>422
違うyo

**デフォルトの名無しさん** · 2017/04/05(水) 02:29:41.05

非同期の方法がたくさんあるからビルトインにしてないんだろ
RxJSが使いたい→redux-observable
generaterが使いたい→redux-saga
Promiseが使いたい→redux-promise
好きなのを選べる

**デフォルトの名無しさん** · 2017/04/05(水) 09:43:00.09

rxは嫌いな奴は本当に嫌いなのでデフォルトにすると人死にが出る

**デフォルトの名無しさん** · 2017/04/05(水) 18:20:05.80

猫は炬燵で丸くなる

**デフォルトの名無しさん** · 2017/04/05(水) 20:06:36.76

ReactとRx同時に使ったら、サイズが大きいのが気になりませんか？

**デフォルトの名無しさん** · 2017/04/06(木) 14:59:39.46

>>421
かなり慎重だったよ
当初提案のメソッドや機能も大分削ぎ落とされたし

**デフォルトの名無しさん** · 2017/04/06(木) 17:23:22.82

Rxってコンセプトがシンプルなのにいざ使おうとするとライブラリのインターフェースは複雑で、ｼﾝﾄﾞってならない？

**デフォルトの名無しさん** · 2017/04/06(木) 20:16:24.28

>>428
でも結局Observableになるんだろ？

**デフォルトの名無しさん** · 2017/04/06(木) 20:20:21.49

Fetch APIがPromiseベースなので、処理がキャンセルできなくて困ったしな。
Fetch APIの戻り値はObservableに変更すべき。

**デフォルトの名無しさん** · 2017/04/06(木) 20:23:20.40

>>429
jQueryとPromise（Deffered）で関数型インターフェースには慣れていたから、
イベントでフィルタできる新しいメソッドが追加されたぐらいにしか思ってないよｗ

**デフォルトの名無しさん** · 2017/04/07(金) 00:20:55.58

>>430
おいおい大丈夫か？？
PromiseはPromiseで、ObservableはObservableで必要だよ
いいか？
ObがあればPrが要らないと言うのは
ジェネレーター関数があれば関数が要らないと言ってるのと同じことだぞ

**デフォルトの名無しさん** · 2017/04/07(金) 01:10:39.92

配列があればnumberはいらない、的な

**デフォルトの名無しさん** · 2017/04/07(金) 01:27:24.68

関数とジェネレータ関数の関係とはちょっと違う気がするが
まあ言いたいことはわかる

**デフォルトの名無しさん** · 2017/04/07(金) 01:53:54.75

>>433
説得力ゼロだなｗ

ObservableがあればPromiseはいらない。
ObservableにPromiseの機能が含まれてるから

**デフォルトの名無しさん** · 2017/04/07(金) 02:08:35.05

promiseは単発、observableは連発
連発は単発を包含してるが最適とは限らない

**デフォルトの名無しさん** · 2017/04/07(金) 02:12:06.86

completeしか発生しないObservable = Promise

そもそも非同期＝時間がかかる処理なのだから、
必然的に途中でキャンセルしたくなるのが普通。
キャンセルができない時点でPromiseは片手落ち

**デフォルトの名無しさん** · 2017/04/07(金) 02:20:36.15

>>436

promiseは非同期処理の約束手形observableはオブジェクトの値の変化を検知する仕組み。

なんでどっちかしかいらないって話になるのか

**デフォルトの名無しさん** · 2017/04/07(金) 02:25:12.94

>>438
Netflixとかなら動画を取り扱うからキャンセルできたほうがいいけど、
他の案件でも必要か？適材適所でしょう。
なんでもストリームとして取り扱うRxは宣言的な記述になるけど、
それが読みやすいかというと、
俺はpromise とasync awaitの方が読みやすい。

**デフォルトの名無しさん** · 2017/04/07(金) 02:48:44.21

RxのObservableと廃案になったObject.observeが混在してる件

**デフォルトの名無しさん** · 2017/04/07(金) 02:51:12.64

多機能があれば単機能はいらない
そんなふうに思って(ry

**デフォルトの名無しさん** · 2017/04/07(金) 03:29:00.04

>>441
えっ。違うのかそれ。解ってなかった。すまぬ

**デフォルトの名無しさん** · 2017/04/07(金) 03:40:41.83

RxのObservableはnodeのReadable Stream (flowing mode) みたいなもん

**デフォルトの名無しさん** · 2017/04/07(金) 07:20:07.56

someがあればeveryは要らないって話？

**デフォルトの名無しさん** · 2017/04/07(金) 09:40:29.94

>>443
分かってなかったのかｗ
通りで話が噛み合わないわけか。

ObservableはPromiseの改良版

**デフォルトの名無しさん** · 2017/04/07(金) 09:44:07.30

>>445
違う。Promiseで十分と思えるような作業であっても
実際は、処理のキャンセルや進捗状況の把握が必要になる。
だからPromiseの仕様では不十分という話

**デフォルトの名無しさん** · 2017/04/07(金) 10:06:57.71

必要になるとは限らない
そもそもキャンセルの方法がないものも多い

**デフォルトの名無しさん** · 2017/04/07(金) 10:50:07.00

promiseでは全てのケースをカバーできない→正しい
だからpromiseはいらない→間違い

**デフォルトの名無しさん** · 2017/04/07(金) 11:38:12.33

でもPromiseだからこそasync awaitを駆使して同期プログラミングっポイ見た目でかけるわけで。
そこはRxではむりでしょ？そもそも宣言的な記述なウリなんだろうけども。
まぁ結局一人で開発だったらドッチもあってもいいけど
複数人プロジェクトだとRxは使いづらいわな。

**デフォルトの名無しさん** · 2017/04/07(金) 11:54:59.99

Observeを束ねて全部処理が終わったら終了処理をしたいんだけど、どうやったらいいんだろう

**デフォルトの名無しさん** · 2017/04/07(金) 12:16:24.62

全部zipすれば

**デフォルトの名無しさん** · 2017/04/07(金) 12:28:20.19

Httpリクエスト…Promise
websocket…Observable

**デフォルトの名無しさん** · 2017/04/07(金) 13:19:55.32

んでRx使ったやつで良いプロジェクトってあるの？
RxSwift使ってたときは良いプロジェクトが見当たらなくて
汚い設計になってしまった。

**デフォルトの名無しさん** · 2017/04/07(金) 13:59:32.72

>>449
これな

**デフォルトの名無しさん** · 2017/04/07(金) 14:44:51.56

要る要らないは個人の考えや開発スタイルによるものだしなぁ

**デフォルトの名無しさん** · 2017/04/07(金) 17:45:00.18

>>452
やってみる

**デフォルトの名無しさん** · 2017/04/07(金) 18:11:21.26

つうかキャンセルだけならCancelablePromise案もあるし、
実際はキャンセルが内蔵されていると不都合があるのでCancelToken案のように
仕組みを外部に用意するのがベストだからPromiseは今のままで良いと思うよ

あと因みに例で挙がってたfetchはキャンセル出来る。
キャンセルする必要があるような重たいファイルをDLするときは
Stream使うだろうから、その場合rs側にcancelメソッドがある。

**デフォルトの名無しさん** · 2017/04/07(金) 18:13:30.99

逆に言うと、もしfetchがプロミスレベルでキャンセルに対応した場合、
こういうStream何かとの兼ね合いはどうするのかって話になる。
自動でrs.cancelが呼ばれるようにするのか、それともclosed例外吐くようにするのか。

やっぱりCancelTokenのように外側から突き刺す形が一番良いよ。

**デフォルトの名無しさん** · 2017/04/07(金) 21:38:04.53

なんかの勉強会でcancelable promiseの標準化は頓挫したと聞いた

**デフォルトの名無しさん** · 2017/04/07(金) 21:50:33.96

終了してた
https://github.com/tc39/proposal-cancelable-promises

**デフォルトの名無しさん** · 2017/04/07(金) 23:33:00.86

>>449
promiseでは全てのケースをカバーできない→正しい
だからpromiseはいらない→そんなこと言ってない

Observableでpromiseのケースをカバーできる→正しい
だからpromiseはいらない→こう言っている

**デフォルトの名無しさん** · 2017/04/07(金) 23:33:50.39

>>460
> なんかの勉強会でcancelable promiseの標準化は頓挫したと聞いた

そしてObservableの標準化が進んでいる

**デフォルトの名無しさん** · 2017/04/07(金) 23:52:45.97

promiseで十分なケースでわざわざobservable使うメリットあんのかよ

**デフォルトの名無しさん** · 2017/04/07(金) 23:55:32.50

>>464
promiseとobservableはインターフェースが違うから互換性がない。
だからライブラリを作るならば両方に対応しなければならない。

またtoPromise()などでobservableからPromiseに変更するなんて
面倒なことをしなければならない場合もある。

promiseとobservableの両方に対応しなくて良いのがメリットだ

**デフォルトの名無しさん** · 2017/04/07(金) 23:57:21.56

>>461
そこはキャンセルしてたでしょ！

**デフォルトの名無しさん** · 2017/04/08(土) 00:03:38.77

>>465
は？
それならobservableなんて対応しなけりゃいいだけじゃねーか
なんで両方に対応しなきゃいけねーんだよ

**デフォルトの名無しさん** · 2017/04/08(土) 00:07:31.07

>>467
殆どの要件でcancelは必要だから結局Fetch APIみたいに
cancelするための別の仕様が出てくる。

だから最初からobservable一本にしておけばいいという話
急ぎすぎてPromiseを標準化してしまったのは黒歴史
Promiseを使ったFetch APIも黒歴史

**デフォルトの名無しさん** · 2017/04/08(土) 00:15:58.80

>>468
fetchのことしか考えてねーのかよ
fsの非同期apiはキャンセル不可だがこれobservableにする意味あんのかよ

fetchが黒歴史なのは正しい
promiseじゃなくstreamだろってsubstackも突っ込んでた

**デフォルトの名無しさん** · 2017/04/08(土) 00:23:48.13

> fsの非同期apiはキャンセル不可だがこれobservableにする意味あんのかよ

あると思うけど？

俺は200MBを超えるファイル×数十個を "並列で" サーバーに送信したことがあるのだが、
もしメモリに全部読み込んでいたら、マシンによってはメモリ不足になっただろう。

だから特定のチャンクごとに読み込んで送信していたわけだが、当然キャンセルもしたいし
どのファイルが何％処理完了したかの状況も表示したくなる。

そんときはループを使って、チャンクごとにデータを読み取って処理したわけだが、
もしfsがobservableであれば、メモリに全部読み取ることなく
一定のチャンクごとに処理する簡単な方法も提供されただろう。

**デフォルトの名無しさん** · 2017/04/08(土) 00:28:43.38

setTimeoutなんかもclearTimeoutみたいにキャンセルするメソッドがあるし、
時間がかかるからこそ非同期にしているわけで、時間がかかる処理を
キャンセルしたいことがありえないなんてAPIが本当にあるのだろうか？

**デフォルトの名無しさん** · 2017/04/08(土) 00:35:11.20

>>470
それはnodeじゃ昔からstreamでやってるやつだがその話じゃねーよ
今のnodeではcallbsckを取るfs.fstatとかの話だ

**デフォルトの名無しさん** · 2017/04/08(土) 00:37:42.94

>>472
俺が話をしているのはブラウザ版だ
nodeの話はしてねーよｗ

**デフォルトの名無しさん** · 2017/04/08(土) 00:38:09.39

>>470
つかてめーnodeやってねーだろ

**デフォルトの名無しさん** · 2017/04/08(土) 00:38:37.44

>>473
スレ違い死ね

**デフォルトの名無しさん** · 2017/04/08(土) 00:38:44.04

そういやブラウザではFile APIだったなｗ

**デフォルトの名無しさん** · 2017/04/08(土) 00:39:23.93

>>471
時間がかかる処理をキャンセルじゃなくて、待つのをキャンセルするじゃね？

**デフォルトの名無しさん** · 2017/04/08(土) 00:44:38.31

>>477
それは言い方の違いでしかないよ

nodeでcallbackを使うやつの話であれば、そもそもなんで
nodeはPromiseを使わなかったのか？の話になるだろ。

それはcallbackを使う方が速いのと、
何度もイベントを発生する必要があるものがあるからだろうな。

つまり、Promiseでは要件に耐えられないから
Promiseではなくcallbackを使ったんだよ。

fs.fstatでは何度もイベントが発生するわけじゃなくても、
何度もイベントが発生することが可能なcallbackを使っている。

それは一度しかイベントが発生しなくてもPromiseではなく
Observableを使ってよいのと同じ考えだ。

**デフォルトの名無しさん** · 2017/04/08(土) 00:49:22.15

>>478
promiseの仕様がいつできたかも知らないのかよ
nodeはその前からあるんだよ
スレ違い野郎は消えろ

**デフォルトの名無しさん** · 2017/04/08(土) 00:51:43.82

http://stackoverflow.com/questions/30299613/why-does-nodejs-not-use-promise-for-the-readfile-api

Node’s early iterations used Promises in its nonblocking API. However, in February 2010,
Ryan Dahl made the decision to switch to the now-familiar callback(err, results...)
format, on the grounds that Promises are a higher-level construct that belongs in “userland.”

英語わかるか？
Nodeは最初Promise使っていて、callbackに変えたって書いてあるんだぞ

**デフォルトの名無しさん** · 2017/04/08(土) 00:54:37.05

（JavaScriptの）Promiseはいつできたんだっけな？
前に調べたんだが忘れたな。

ここを見る限り2009年なのは間違いないが。
http://wiki.commonjs.org/index.php?title=Promises&;oldid=516

**デフォルトの名無しさん** · 2017/04/08(土) 00:55:18.13

そのpromiseはes6のpromiseとは別物だ

**デフォルトの名無しさん** · 2017/04/08(土) 00:56:40.01

nodeでobservableに相当するのはstream
fs.fstatはstreamを使わない
それが答え
以上

**デフォルトの名無しさん** · 2017/04/08(土) 01:03:43.79

>>482
それは当たり前だが、Promiseを捨てた理由は同じだ

>>483
fs.fstatはPromiseを使わない。
それが答えだろう？ｗ

**デフォルトの名無しさん** · 2017/04/08(土) 01:05:41.12

> nodeでobservableに相当するのはstream

ちなみに、streamを知らない人に説明しておくと、
streamが使ってるのはPromiseではなくcallback

**デフォルトの名無しさん** · 2017/04/08(土) 01:10:44.04

>>484
promiseを使わない理由がキャンセルできないからじゃないのは分かってんのかよ
システムコールレベルでキャンセルする方法がないのにobservableにするメリットあんのかって問いに答えてねーだろ
nodeは単発にcallback、連発にstreamで使い分けてる
大は小を兼ねるとは限らないんだよ

**デフォルトの名無しさん** · 2017/04/08(土) 01:24:00.13

システムコールレベルって何の話？

Win32APIとかレベルの話してるの？

独自用語で話すんなよ

**デフォルトの名無しさん** · 2017/04/08(土) 01:25:28.87

ふむ

Windows Vista での Win32 I/O キャンセルサポート
https://msdn.microsoft.com/ja-jp/library/aa480216.aspx

**デフォルトの名無しさん** · 2017/04/08(土) 01:27:17.78

何やこいつ
キャンセルする必要がない単発はPromiseでいいし、キャンセルが必要か連発ならobs使えばいいって話だろ
しゅうきょーせんそーかな？

**デフォルトの名無しさん** · 2017/04/08(土) 01:28:10.51

単発だからってキャンセルする必要が無いことにはならないんだが？

言ってる意味わかる？

**デフォルトの名無しさん** · 2017/04/08(土) 01:31:42.23

Observableが得意なのはキャンセルだけじゃなくて
並列処理もなんで、fs.fstatを並列で実行したいときにも
簡単にかけるというメリットも有るな

**デフォルトの名無しさん** · 2017/04/08(土) 01:33:57.12

いくら君らが言い合っても、現実はかわらないでしょ？
今ある仕様がすべてで文句かるなら他の言語つかいなよで終わる話しじゃないの？
生産性のない答えもない事で争って暇すぎるだろ

**デフォルトの名無しさん** · 2017/04/08(土) 01:36:49.14

>>490
「キャンセルする必要がない場合は」
よく嫁

**デフォルトの名無しさん** · 2017/04/08(土) 01:37:27.20

こいつもしかしてIT速報の管理人か？
転載禁止やぞ。対立煽りはNG

**デフォルトの名無しさん** · 2017/04/08(土) 01:45:22.63

スプーンとお玉の関係に似てる。
ジャムをすくうのにお玉を使ったら逆に不便だろ。そこは適切にスプーンを使え。
キャンセル処理がPromiseだと絶対無理というわけでもないし、Rxが必要とも思えないプロジェクトで無理やりRxを使う必要もない。

**デフォルトの名無しさん** · 2017/04/08(土) 01:49:13.35

>>493
> 「キャンセルする必要がない場合は」

それはまずないだろうねｗ

**デフォルトの名無しさん** · 2017/04/08(土) 02:25:27.18

レスの文体からして前からJSスレに常駐してる荒らしでしょ
コピペブログ管理人もやってたのかは知らんが

**デフォルトの名無しさん** · 2017/04/08(土) 02:31:02.63

>>487
システムコールってwikipediaにもエントリあるのに
unix/linux系はダメなwindows君か
どうりでダメなわけだ