【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
next.js使えるって思ったら クライアントサイドのコードとサーバサイドのコードの連携方法が不明。 expressでlistenしているサーバーの443ポートに、socket.ioをねじ込むことはできますか? httpsしか許可していないLAN環境で使いたいためです。 >>389 ありがとうございます。 別IPか別ホストに分けて起動するようにします。 レス間違えました。388ありがとうございます。 >>389 そうなんですか? どうやるんでしょう? 何分、始めたばかりで基本の知識に乏しいものでして… >>391 expressのserverをioの引数にしてlistnするだけじゃなかったっけ? >>392 ありがとうございます! 調べてやってみます。 こんな感じであっさりとできました。すげー! keysはSSLの証明書ファイルとかです。 ex = require('express'); app = ex(); ... some js ... sv = https.createServer(keys, app).listen(port, bind); io = require('socket.io').listen(sv); ありがとうございました!! Node.js@Windowsです。 spawnを使ってexpectのようなことってできないんでしょうか? 例えば以下のように、stdoutに「Y/N」が出力されたら「y」と答えるようなことがしたいのですが…。 const spawn= require('child_process').spawn; const de = spawn('del', [ '/p', 'foo' ], { shell: true }); de.stdout.on('data', (data) => { if (data.toString().indexOf('Y/N') !== -1) de.stdin.write('y'); // ??? }); next.jsってjsコードをクライアントでもサーバでも動くように書かないとだめなの? 例えば以下のような条件を入れてサーバとクライアントで処理を分岐することはできるけど typeof window === `undefined` そもそもimportについてはどうすればいいの? fsがないって怒られんるだけどサードパーティのライブラリが依存してたら使わなくてもエラーになっちゃうし。 react naitive躓きました react-naitive init hogehoge ってやってプロジェクト作ろうとするとdoneと表示されてもプロンプトが戻ってこない。 nodejsはanyenvを使って最新を入れてます。 ctrc+cで無理やり戻すと当然プロジェクトはできていないので何もできない。 まだ勉強し始めなんだけどコールバック地獄を抜けたらPromiseラップ地獄が始まってる気がするゾ RxのAsyncSubjectってPromiseと比較してどんなメリットがあるんだ? async/awaitで使えないから不便と思う callback地獄なんか近づかずにpromiseとasync await始めたほうがいい。 promise抑えてからじゃないとasync await使えないから、promiseは必須な rxはreact nativeあたりと組み合わせるとどうなんだろうね? coldとhotって概念があったり意外とつまずきやすい。全てがstreamという概念は素敵そうだけどreactとうまく組み合わせられるんか? async使い出すとやってくるtry catch地獄 コールバック地獄って無名関数でしか渡してないから問題なだけじゃね? 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)) } }) }) } }) >>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)) } } >>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)で関数型インターフェースには慣れていたから、 イベントでフィルタできる新しいメソッドが追加されたぐらいにしか思ってないよw >>430 おいおい大丈夫か?? PromiseはPromiseで、ObservableはObservableで必要だよ いいか? ObがあればPrが要らないと言うのは ジェネレーター関数があれば関数が要らないと言ってるのと同じことだぞ 関数とジェネレータ関数の関係とはちょっと違う気がするが まあ言いたいことはわかる >>433 説得力ゼロだなw 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 分かってなかったのかw 通りで話が噛み合わないわけか。 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の話はしてねーよw >>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を使わない。 それが答えだろう?w ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる