【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>409
redux学習中だけどRxJSと組み合わせると何が幸せになるん？ RPとFRPの区別がついてない奴を馬鹿にして粋がれるとか >>411
RxJSのメリットは非同期の扱いを楽にしてくれること
RxJSとreduxを組み合わせるのは
一番よく使われてるフレームワークにのっかることで
Redux向けのツール類やノウハウなんかでそのメリットを享受するため
>>409の1つ目のリンクはRxJSだけでreduxと同じようなことをやってる例
2つ目は組み合わせて使う例 >>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) electronというかjsでデスクトップアプリって流行ると思いますか? >>413
非同期の扱いを楽にするって観点ならasync awaitで必要十分じゃないか。
RxJSならではのメリットを知りたい。 >>415
reactnativeでデスクトップアプリが作れるようになったほうがいいと思うけどね。性能面でも。
electronで結構キラーアプリは出てるから使えて損はない。
chromeOSが復活しないかな。
アプリごとにchromeが中で動いてるのって無駄な気がするんだよね WEB+DB vol.97 の特集が、React
WEB+DB vol.94 の特集が、Kotlin, Electron RxJSをみてるとJavaScriptにPromise入れるのは
もっと慎重にやるべきだったと思うね reduxは非同期処理入れるのにミドルウエアが必要でその中の候補としてrxjsがあるってこと？
非同期処理は多用するんだからミドルウエア無しで対応しろよ 非同期の方法がたくさんあるからビルトインにしてないんだろ
RxJSが使いたい→redux-observable
generaterが使いたい→redux-saga
Promiseが使いたい→redux-promise
好きなのを選べる rxは嫌いな奴は本当に嫌いなのでデフォルトにすると人死にが出る ReactとRx同時に使ったら、サイズが大きいのが気になりませんか？ >>421
かなり慎重だったよ
当初提案のメソッドや機能も大分削ぎ落とされたし Rxってコンセプトがシンプルなのにいざ使おうとするとライブラリのインターフェースは複雑で、ｼﾝﾄﾞってならない？ >>428
でも結局Observableになるんだろ？ Fetch APIがPromiseベースなので、処理がキャンセルできなくて困ったしな。
Fetch APIの戻り値はObservableに変更すべき。 >>429
jQueryとPromise（Deffered）で関数型インターフェースには慣れていたから、
イベントでフィルタできる新しいメソッドが追加されたぐらいにしか思ってないよｗ >>430
おいおい大丈夫か？？
PromiseはPromiseで、ObservableはObservableで必要だよ
いいか？
ObがあればPrが要らないと言うのは
ジェネレーター関数があれば関数が要らないと言ってるのと同じことだぞ 関数とジェネレータ関数の関係とはちょっと違う気がするが
まあ言いたいことはわかる >>433
説得力ゼロだなｗ
ObservableがあればPromiseはいらない。
ObservableにPromiseの機能が含まれてるから promiseは単発、observableは連発
連発は単発を包含してるが最適とは限らない completeしか発生しないObservable = Promise
そもそも非同期＝時間がかかる処理なのだから、
必然的に途中でキャンセルしたくなるのが普通。
キャンセルができない時点でPromiseは片手落ち >>436
promiseは非同期処理の約束手形observableはオブジェクトの値の変化を検知する仕組み。
なんでどっちかしかいらないって話になるのか >>438
Netflixとかなら動画を取り扱うからキャンセルできたほうがいいけど、
他の案件でも必要か？適材適所でしょう。
なんでもストリームとして取り扱うRxは宣言的な記述になるけど、
それが読みやすいかというと、
俺はpromise とasync awaitの方が読みやすい。 RxのObservableと廃案になったObject.observeが混在してる件 多機能があれば単機能はいらない
そんなふうに思って(ry >>441
えっ。違うのかそれ。解ってなかった。すまぬ RxのObservableはnodeのReadable Stream (flowing mode) みたいなもん >>443
分かってなかったのかｗ
通りで話が噛み合わないわけか。
ObservableはPromiseの改良版 >>445
違う。Promiseで十分と思えるような作業であっても
実際は、処理のキャンセルや進捗状況の把握が必要になる。
だからPromiseの仕様では不十分という話 必要になるとは限らない
そもそもキャンセルの方法がないものも多い promiseでは全てのケースをカバーできない→正しい
だからpromiseはいらない→間違い でもPromiseだからこそasync awaitを駆使して同期プログラミングっポイ見た目でかけるわけで。
そこはRxではむりでしょ？そもそも宣言的な記述なウリなんだろうけども。
まぁ結局一人で開発だったらドッチもあってもいいけど
複数人プロジェクトだとRxは使いづらいわな。 Observeを束ねて全部処理が終わったら終了処理をしたいんだけど、どうやったらいいんだろう Httpリクエスト…Promise
websocket…Observable んでRx使ったやつで良いプロジェクトってあるの？
RxSwift使ってたときは良いプロジェクトが見当たらなくて
汚い設計になってしまった。 要る要らないは個人の考えや開発スタイルによるものだしなぁ つうかキャンセルだけならCancelablePromise案もあるし、
実際はキャンセルが内蔵されていると不都合があるのでCancelToken案のように
仕組みを外部に用意するのがベストだからPromiseは今のままで良いと思うよ
あと因みに例で挙がってたfetchはキャンセル出来る。
キャンセルする必要があるような重たいファイルをDLするときは
Stream使うだろうから、その場合rs側にcancelメソッドがある。 逆に言うと、もしfetchがプロミスレベルでキャンセルに対応した場合、
こういうStream何かとの兼ね合いはどうするのかって話になる。
自動でrs.cancelが呼ばれるようにするのか、それともclosed例外吐くようにするのか。
やっぱりCancelTokenのように外側から突き刺す形が一番良いよ。 なんかの勉強会でcancelable promiseの標準化は頓挫したと聞いた >>449
promiseでは全てのケースをカバーできない→正しい
だからpromiseはいらない→そんなこと言ってない
Observableでpromiseのケースをカバーできる→正しい
だからpromiseはいらない→こう言っている >>460
> なんかの勉強会でcancelable promiseの標準化は頓挫したと聞いた
そしてObservableの標準化が進んでいる promiseで十分なケースでわざわざobservable使うメリットあんのかよ >>464
promiseとobservableはインターフェースが違うから互換性がない。
だからライブラリを作るならば両方に対応しなければならない。
またtoPromise()などでobservableからPromiseに変更するなんて
面倒なことをしなければならない場合もある。
promiseとobservableの両方に対応しなくて良いのがメリットだ >>465
は？
それならobservableなんて対応しなけりゃいいだけじゃねーか
なんで両方に対応しなきゃいけねーんだよ >>467
殆どの要件でcancelは必要だから結局Fetch APIみたいに
cancelするための別の仕様が出てくる。
だから最初からobservable一本にしておけばいいという話
急ぎすぎてPromiseを標準化してしまったのは黒歴史
Promiseを使ったFetch APIも黒歴史 >>468
fetchのことしか考えてねーのかよ
fsの非同期apiはキャンセル不可だがこれobservableにする意味あんのかよ
fetchが黒歴史なのは正しい
promiseじゃなくstreamだろってsubstackも突っ込んでた > fsの非同期apiはキャンセル不可だがこれobservableにする意味あんのかよ
あると思うけど？
俺は200MBを超えるファイル×数十個を "並列で" サーバーに送信したことがあるのだが、
もしメモリに全部読み込んでいたら、マシンによってはメモリ不足になっただろう。
だから特定のチャンクごとに読み込んで送信していたわけだが、当然キャンセルもしたいし
どのファイルが何％処理完了したかの状況も表示したくなる。
そんときはループを使って、チャンクごとにデータを読み取って処理したわけだが、
もしfsがobservableであれば、メモリに全部読み取ることなく
一定のチャンクごとに処理する簡単な方法も提供されただろう。 setTimeoutなんかもclearTimeoutみたいにキャンセルするメソッドがあるし、
時間がかかるからこそ非同期にしているわけで、時間がかかる処理を
キャンセルしたいことがありえないなんてAPIが本当にあるのだろうか？ >>470
それはnodeじゃ昔からstreamでやってるやつだがその話じゃねーよ
今のnodeではcallbsckを取るfs.fstatとかの話だ >>472
俺が話をしているのはブラウザ版だ
nodeの話はしてねーよｗ >>471
時間がかかる処理をキャンセルじゃなくて、待つのをキャンセルするじゃね？ >>477
それは言い方の違いでしかないよ
nodeでcallbackを使うやつの話であれば、そもそもなんで
nodeはPromiseを使わなかったのか？の話になるだろ。
それはcallbackを使う方が速いのと、
何度もイベントを発生する必要があるものがあるからだろうな。
つまり、Promiseでは要件に耐えられないから
Promiseではなくcallbackを使ったんだよ。
fs.fstatでは何度もイベントが発生するわけじゃなくても、
何度もイベントが発生することが可能なcallbackを使っている。
それは一度しかイベントが発生しなくてもPromiseではなく
Observableを使ってよいのと同じ考えだ。 >>478
promiseの仕様がいつできたかも知らないのかよ
nodeはその前からあるんだよ
スレ違い野郎は消えろ 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に変えたって書いてあるんだぞ （JavaScriptの）Promiseはいつできたんだっけな？
前に調べたんだが忘れたな。
ここを見る限り2009年なのは間違いないが。
http://wiki.commonjs.org/index.php?title=Promises&;oldid=516 そのpromiseはes6のpromiseとは別物だ nodeでobservableに相当するのはstream
fs.fstatはstreamを使わない
それが答え
以上 >>482
それは当たり前だが、Promiseを捨てた理由は同じだ
>>483
fs.fstatはPromiseを使わない。
それが答えだろう？ｗ > nodeでobservableに相当するのはstream
ちなみに、streamを知らない人に説明しておくと、
streamが使ってるのはPromiseではなくcallback >>484
promiseを使わない理由がキャンセルできないからじゃないのは分かってんのかよ
システムコールレベルでキャンセルする方法がないのにobservableにするメリットあんのかって問いに答えてねーだろ
nodeは単発にcallback、連発にstreamで使い分けてる
大は小を兼ねるとは限らないんだよ システムコールレベルって何の話？
Win32APIとかレベルの話してるの？
独自用語で話すんなよ 何やこいつ
キャンセルする必要がない単発はPromiseでいいし、キャンセルが必要か連発ならobs使えばいいって話だろ
しゅうきょーせんそーかな？ 単発だからってキャンセルする必要が無いことにはならないんだが？
言ってる意味わかる？ Observableが得意なのはキャンセルだけじゃなくて
並列処理もなんで、fs.fstatを並列で実行したいときにも
簡単にかけるというメリットも有るな いくら君らが言い合っても、現実はかわらないでしょ？
今ある仕様がすべてで文句かるなら他の言語つかいなよで終わる話しじゃないの？
生産性のない答えもない事で争って暇すぎるだろ >>490
「キャンセルする必要がない場合は」
よく嫁 こいつもしかしてIT速報の管理人か？
転載禁止やぞ。対立煽りはNG スプーンとお玉の関係に似てる。
ジャムをすくうのにお玉を使ったら逆に不便だろ。そこは適切にスプーンを使え。
キャンセル処理がPromiseだと絶対無理というわけでもないし、Rxが必要とも思えないプロジェクトで無理やりRxを使う必要もない。 >>493
> 「キャンセルする必要がない場合は」
それはまずないだろうねｗ レスの文体からして前からJSスレに常駐してる荒らしでしょ
コピペブログ管理人もやってたのかは知らんが >>487
システムコールってwikipediaにもエントリあるのに
unix/linux系はダメなwindows君か
どうりでダメなわけだ >>498
分かってないなｗ
なんでシステムコールの話がでてくるんだってことだよ。
nodeのAPIと、OSのシステムコールを
一対一で直接結びつける必要はないっつーの
nodeのAPIは単純な一命令でも、内部の実装は
何回もシステムコール呼んだって良いわけだ。
それが分かってないから、お前はシステムコールが
キャンセルできるかどうかなんて言い出したんだろ
こっちは全部お見通しだってーの fetchはキャンセルできる必要があるが、
fetchの戻り値をObsevableにするのは駄目。
Obsevableって一様な幾つものデータを受け取るのに向いているので
fetchのように幾つかの段階で全然違うものが帰って来るのには向いていない。
単純に、Responseにabortメソッドを付けるのが良いと思う
勿論途中のStreamをObsevableにするのはとても良いと思うけど、
それを含んだ全体をするのはおかしい。 というか考えたら分かると思う。
キャンセルしたいのはfetchではなく、DLなのだから。
やっぱりCancelToken以外の解は無いと思うよ。 > キャンセルしたいのはfetchではなく、DLなのだから。
fetchはデータ送信もするんだが？
その場合キャンセルしたいのは何だよ >>500
> 単純に、Responseにabortメソッドを付けるのが良いと思う
fetchの戻り値はpromiseであってresponseではない。
responseはpromiseのthenの時に渡される。
promiseのthenが呼び出されるのはfetchの処理が完了した後。
つまりresponseを取得したとき＝fetchし終わった時に
abortするのは遅すぎる >>499
なにを見通してるのかさっぱり分からんがnodeは低水準のapiを提供するものだ
そうすれば複数のシステムコールを組み合わせた高水準apiはユーザーレベルのライブラリで実現できる
だからfsモジュールは意図的にposixの薄いラッパーになっていてキャンセルはない >>505
> nodeは低水準のapiを提供するものだ
どこにそんなことが書いてあるのか？
nodeの立場はブラウザと同じだ。
JavaScriptの実行環境だ。
お前の理屈だと、ブラウザは低水準のAPIを提供するものということになる。 >>505
> だからfsモジュールは意図的にposixの薄いラッパーになっていてキャンセルはない
じゃあ、例えば、fs.lstatSync は posixのどの薄いラッパーなのか言ってみ >>506
> 仕様にはstreamが追加されてる
どっちみち仕様を加えるなら
Observableにした方がいいだろうな。 しかもPOSIXは非同期I/Oをキャンセルする機能あるじゃんｗｗｗ
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/aio_cancel.3.html
aio_cancel - 完了していない非同期 I/O リクエストをキャンセルする
POSIX.1-2001, POSIX.1-2008. ■ このスレッドは過去ログ倉庫に格納されています
