+ JavaScript の質問用スレッド vol.122 + [無断転載禁止]©2ch.net

JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-6のテンプレを読んだ上で質問してください。次スレは>>950が>>2のテンプレ案(本スレで改善案があれば考慮)を元に立ててください

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) ライブラリ関連の質問は禁止です。関連スレにあるライブラリ質問スレで質問して下さい。
(10) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。
※前スレ
+ JavaScript の質問用スレッド vol.121 +
http://echo.2ch.net/test/read.cgi/tech/1468158373/

---

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
　1レスに収まらないならコード投稿サイトを利用してください。
　http://jsdo.it/　http://jsbin.com/　http://jsfiddle.net/　http://ideone.com/

■前スレ
+ JavaScript の質問用スレッド vol.120 + [無断転載禁止]c2ch.net
http://echo.2ch.net/test/read.cgi/tech/1463914293/

■過去スレ全集
http://www2.atpages.jp/mirror/2ch/javascript/
http://usamimi.info/~mirrorhenkan/2ch/javascript/ (閲覧のみ)

■テンプレ案
https://fiddle.jshell.net/6018r9tu/1/show/light/

■関連スレ
JavaScript ライブラリ総合質問所 vol.5 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/hp/1465399470/
JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]c2ch.net
http://echo.2ch.net/test/read.cgi/hp/1465566635/
【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]c2ch.net
http://echo.2ch.net/test/read.cgi/tech/1460359714/
(X)HTML/CSS の質問に優しく答えるｽﾚ23 [無断転載禁止]c2ch.net
http://echo.2ch.net/test/read.cgi/hp/1467511443/
Canvasについて語ろう
http://peace.2ch.net/test/read.cgi/hp/1305093769/

■FAQ
http://fiddle.jshell.net/vSqKr/44/show/light/

◆開発者ツール(Developer Tools)の基本的な使い方 (全部はhttp://fiddle.jshell.net/vSqKr/44/show/light/#Browser-Developer-Tools )
　▼諸注意
　 - 本説明では Google Chrome の開発者ツールの名称に従います。他ブラウザで使う場合は適宜読み替えて下さい。
　 - IE9- でコンソールを使うには予め開発者ツールを起動しておく必要があります(開発者ツールを起動しないと console.log() が機能しません)
　 - Safari はデフォルトで開発者ツールが無効な為、有効に設定する必要があります。
　 https://developer.apple.com/library/safari/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/GettingStarted/GettingStarted.html
　▼要素を検証
　1. ページ上で右クリックして [要素を検証]
　2. [Elements] パネルが開き、対象のDOMノードが選択される(選択対象が目的の要素でなければ [Elements] パネル上で選択し直す)
　3. 右側のサイドバーから知りたいステータス名のタブを選択する
　　　- [Styles] タブ … CSSプロパティの指定値を表示 (※カスケードによって上書きされたプロパティは取り消し線で表示される)
　　　- [Computed] タブ … CSSプロパティの算出値を表示(

■FAQ(続き)
◆JavaScriptの実行速度
JavaScriptの速度は「ブラウザ名」「ブラウザのバージョン」「PCスペック」に依存します(ブラウザのバージョン毎に最適化具合が異なります)。
速度の疑問解消の為に http://jsperf.com/ にコードをUPしてブラウザ毎に速度計測する事を推奨します。
例外として、仕様における理論上の速度が明確になっている場合があります。
例えば、正規表現によるマッチング処理を考えた場合、「RegExp#test > RegExp#exec > String#match」は ES5 仕様で保証されています。
ES5 仕様において RegExp#test が最も処理数が少なく、String#match が最も処理数が多いことが明確だからです。
ブラウザによっては RegExp#test の最適化が十分でなく、String#match の最適化が RegExp#test より十分であれば逆転する可能性はありますが、各メソッドの最適化が一律であればこの前提が崩れる事はありません。

■各種仕様 ( http://fiddle.jshell.net/vSqKr/44/show/light/#Link も参照 )
◆ Standard ECMA-262
http://bclary.com/2004/11/07/ (ECMAScript 3 HTML版)
http://www2u.biglobe.ne.jp/~oz-07ams/2002/ecma262r3/ (ECMAScript 3 和訳)
http://www.ecma-international.org/ecma-262/5.1/ (ECMAScript 5.1 HTML版)
http://tsofthome.appspot.com/ecmascript.html (ECMAScript 5.1 和訳)
http://www.ecma-international.org/ecma-262/6.0/ (ECMAScript 6 / ECMAScript 2015)
http://kangax.github.io/compat-table/es5/ (ECMAScript 5 compatibility table)
http://kangax.github.io/compat-table/es6/ (ECMAScript 6 compatibility table)
◆ HTML Standard (HTML5)
http://www.whatwg.org/specs/web-apps/current-work/multipage/
http://momdo.s35.xrea.com/web-html-test/spec/WD-html51-20130528/Overview.html (HTML5.1 部分訳)
http://www.hcn.zaq.ne.jp/___/WEB/WebStorage-ja.html (Web Storage 和訳)

■FAQ
http://fiddle.jshell.net/vSqKr/44/show/light/

◆開発者ツール(Developer Tools)の基本的な使い方 (全部はhttp://fiddle.jshell.net/vSqKr/44/show/light/#Browser-Developer-Tools )
　▼諸注意
　 - 本説明では Google Chrome の開発者ツールの名称に従います。他ブラウザで使う場合は適宜読み替えて下さい。
　 - IE9- でコンソールを使うには予め開発者ツールを起動しておく必要があります(開発者ツールを起動しないと console.log() が機能しません)
　 - Safari はデフォルトで開発者ツールが無効な為、有効に設定する必要があります。
　 https://developer.apple.com/library/safari/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/GettingStarted/GettingStarted.html
　▼要素を検証
　1. ページ上で右クリックして [要素を検証]
　2. [Elements] パネルが開き、対象のDOMノードが選択される(選択対象が目的の要素でなければ [Elements] パネル上で選択し直す)
　3. 右側のサイドバーから知りたいステータス名のタブを選択する
　　　- [Styles] タブ … CSSプロパティの指定値を表示 (※カスケードによって上書きされたプロパティは取り消し線で表示される)
　　　- [Computed] タブ … CSSプロパティの算出値を表示(

■各種仕様 (続き)
◆ Document Object Model (DOM) / CSS Object Model (CSSOM)
http://www.hcn.zaq.ne.jp/___/WEB/DOM4-ja.html (DOM Standard (DOM4) 和訳)
http://www.w3.org/TR/DOM-Level-3-Events/ (DOM3 Events)
http://www.w3.org/TR/uievents/ (UI Events)
http://www.hcn.zaq.ne.jp/___/WEB/cssom-ja.html (CSSOM 和訳)
http://www.hcn.zaq.ne.jp/___/WEB/cssom-view-ja.html (CSSOM View Module 和訳)
◆ その他のWeb関連仕様
http://domparsing.spec.whatwg.org/ (DOM Parsing and Serialization - innerHTML等)
http://www.hcn.zaq.ne.jp/___/WEB/XHR-ja.html (XMLHttpRequest 和訳)
http://www.hcn.zaq.ne.jp/___/WEB/File_API-ja.html (File API 和訳)
http://www.whatwg.org/specs/ (WHATWGの仕様一覧)
◆ MDN (Netscape/Mozilla)
https://developer.mozilla.org/ja/docs
◆ MSDN Library
https://msdn.microsoft.com/en-us/library/ie/hh828809 (Internet Explorer API)
http://msdn.microsoft.com/ja-jp/library/yek4tbz0.aspx (JavaScript)
http://msdn.microsoft.com/ja-jp/library/cc427807.aspx (JScript)
http://msdn.microsoft.com/ja-jp/library/cc409712.aspx (DHTML)
◆ JavaScript Garden (ja)
http://bonsaiden.github.com/JavaScript-Garden/ja/
◆ JSON (JavaScript Object Notation)
http://www.json.org/json-ja.html

■各種仕様 (続き)
◆ Document Object Model (DOM) / CSS Object Model (CSSOM)
http://www.hcn.zaq.ne.jp/___/WEB/DOM4-ja.html (DOM Standard (DOM4) 和訳)
http://www.w3.org/TR/DOM-Level-3-Events/ (DOM3 Events)
http://www.w3.org/TR/uievents/ (UI Events)
http://www.hcn.zaq.ne.jp/___/WEB/cssom-ja.html (CSSOM 和訳)
http://www.hcn.zaq.ne.jp/___/WEB/cssom-view-ja.html (CSSOM View Module 和訳)
◆ その他のWeb関連仕様
http://domparsing.spec.whatwg.org/ (DOM Parsing and Serialization - innerHTML等)
http://www.hcn.zaq.ne.jp/___/WEB/XHR-ja.html (XMLHttpRequest 和訳)
http://www.hcn.zaq.ne.jp/___/WEB/File_API-ja.html (File API 和訳)
http://www.whatwg.org/specs/ (WHATWGの仕様一覧)
◆ MDN (Netscape/Mozilla)
https://developer.mozilla.org/ja/docs
◆ MSDN Library
https://msdn.microsoft.com/en-us/library/ie/hh828809 (Internet Explorer API)
http://msdn.microsoft.com/ja-jp/library/yek4tbz0.aspx (JavaScript)
http://msdn.microsoft.com/ja-jp/library/cc427807.aspx (JScript)
http://msdn.microsoft.com/ja-jp/library/cc409712.aspx (DHTML)
◆ JavaScript Garden (ja)
http://bonsaiden.github.com/JavaScript-Garden/ja/
◆ JSON (JavaScript Object Notation)
http://www.json.org/json-ja.html

■諸注意
vol.115でlodashを不必要に推奨して啓蒙する行為が多く確認されており、ライブラリ系の質問はvol.116から禁止されました。
vol.115,116ではライブラリ禁止する発言が見られた直後にライブラリを許可する意図で次スレを立てる行為が確認されています。
本スレッドでライブラリ許可を求める発言が確認された場合は不要な争いを避ける為、スルーすることを推奨します。
ライブラリの質問はライブラリスレへ誘導し、誘導行為への反論はスルーしてください。

-----ここまでテンプレ-----

取りあえず一乙だけどレスポンチは他所でやってほしい

>>9
うん、それはマジですまんかった。
新しいスレ立ててもらえたようだし、ワッチョイもやってみたし、迷惑掛けた分多少なりとも貢献させてくれ。

一乙ワッチョイ乙。

個人的にはやりたいことをやればいいと思うから、
「スレを乗っ取る」のではなく、「新しいスレを立てて何かやる」のはいいと思うよ。
今回はその新しいスレが「質問スレ」と銘打っているから駄目だと思うけど。

仕様について語りたい人が多いのなら、「仕様スレ」を立てればいいんだよ。
人を集めるのが面倒だからといって、既存スレを乗っ取るのは駄目だよ。
結果的に「質問スレ」「仕様スレ」と並立した状態で、質問スレが過疎って落ちるのなら、
それは不要という意味だから、その時統合すればいいだけ。
それ以前に無理矢理方針変更するのは、ただの乗っ取りでしかない。
質問スレは単独で十分流れているわけだし。

前回何故か「仕様スレ」が放置されて落ちたでしょ。
それも含めて単独で「仕様スレ」が存在出来ないと考えて「質問スレ」としたのなら姑息だよ。
単独で存在出来ないのならそれは需要がないということでしかない。
それでも需要を掘り起こしたいのなら、ぬしって保守していくしかない。

自分では何もする気がなくて、他人が作り上げた物を横取りすることしか考えないのは、ただのクズだよ。
実際、君らには「仕様スレ」が必要なのだろう？
だったら姑息なことをせずに正面から「仕様スレ」立てて勝負すれば良かっただけの話だよ。
それが落ちたらそれまでの話でね。別に殺されるわけでもなし。

というのが今回の顛末で思ったことだね。


はい、では次の質問どうぞ。

>>11
いや、俺にそこまでの強い意図があったわけでは無いんだ。
質問スレで、間違ってる答えってのはその中で訂正、再発言されて然るべきだと思って、おかしいんじゃねえの？
って言ったのを、良くわからん理屈で訂正どころか、
間違いに間違いを重ねるから。

訂正してほしかっただけよ。後続の人のために。
売り言葉に買い言葉になっているだけで仕様を語りたいわけでは(俺は)無くて、間違ってなければそれで良いよ。どんな話してても。

訂正してほしかったじゃなくて、お前が訂正するんだよ。
正しい情報をちゃんとしたソース込みで。

相手はちゃんとソース出しているんだから、
お前がそれよりも信頼できるソースを出せない以上、
相手が正しいで終わりだろ。

>>13
平行線だろ。
こっちが、ソースやら考え方を話しても聞かないんだから。
だから説得は諦めた。

以下の言語がいいよって言われたんですが聞き取り間違えたのか検索しても出てきませんでした。
ホトリン
正確な言語名を教えて欲しいです。

kotlinじゃないかな
間違ってたらすまん

ポワトリン
年齢がわかる

ここが比較的まともだな

ガンは切らないとね。

>>19
だったら、向こうのスレでレスするのを止めなよ

>>20
あっちが閑古鳥鳴いたら来ちゃうじゃん。

>>21
構わなければあの話題に関しては自然消滅するでしょ
あっちが本スレだと勘違いする人も出てくるだろうし、スルーが一番

promiseのチェーンをn個動的につなげたいときはどうしたらいいの？

a().then(b).then(c).then(d);

これをこう書き
function run(a){
return a[0]().then(a[1]).then(a[2]).then(a[3]);
}

a[] を4個固定じゃなくてn個にしたい

>>24
Promise.all の事？

>>25
allじゃない。 thenの方。

>>23-24
PromiseはECMAScriptの範囲なので

+ JavaScript(ECMAScript)質問用スレッド vol.122 + [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1472401404/

こっちのほうがふさわしい。

>>24
var f=function (a){
var y=a.shift();
if(y) y().then(function(){f(a)})
}
で全部いけるんでないの？

>>26
処理の連続性は保証されるはずだが、Promise.all では要件を満たせないのだな？
並列処理がNGなら下記URLを参考に
http://azu.github.io/promises-book/#promise-sequence

>>26
こっちに答えがあったよ。
http://echo.2ch.net/test/read.cgi/tech/1472401404/130

>>28
前から思ってるんだけど、何でお前らそんな奇妙なコードを書くの？
そういう可変長ループはwhileが鉄板で、>>24はそれを知らないだけだろ？
関数型()でインミュータブル()なら、shift使っちゃ駄目だと思うし。(俺は詳しくないが）

そのコード自体は自前Promiseとしてarrayを持ち、途中で挿入も出来るから、
そういった用途には面白いと思うよ。
ただ、普通は>>24に対してそれはない。
というか、お前らどこで習った？或いは誰を参考にしてそのコードを書いてる？

>>24
while使って書いてみ？
正直、書くのは手間ではないのだけど、コードクレクレ君が集まるのはウザイから、
今回の質問レベルならコピペで動くコードを書く気はない。
ただ、十分なヒントだと思うから、クレクレ君でなければ書けると思うが。

>>31
while使って書くって、プロミスなのに？
順序が保証できるのならそれで良いとは思うけど。
別に、shiftでも、carとcdrに相当するものでも良いよ。
どこも奇妙じゃないと思うけど。

>>32
いや俺はPromise使ったことがないからその辺詳しくはないが、
>>24なら見た目普通に書けそうだが駄目なのか？
そもそも>>24が駄目（動かないコード）なのか？そうだったら済まんかった。

やはりcarとcdrか。
つかcar/cdrで抽象化している関数型みたいな奴って、一般的にarrayを破壊的に使うものなのか？
(lispなら最近の大富豪プログラミング以前だからそうなのかもしれんが、
多分最近の関数型なら嫌われるのでは？）

>>31
◆SEdFBOkLSw は技術レベル低いくせに
口ばっかりうるさいやつですから・・・
これまでも何度となく、意味不明なこと言ってるよｗ

うーん、一応PromiseをMDNで確認してみたけど、書けると思うけどね。
見た目、functionで入れ子になるのが嫌で、タマネギ型オブジェクトにしてみただけだろ？
まあ、俺は使ったことがないから、壮絶な勘違いをしているかもしれんが。

ちなみに>>30は「タマネギ型」であることを説明しているわけだが、
それは>>24見る限り本人は分かってると思うんだよ。
そうではなくて、「n個にしたい」って言ってるんだから、そこを答えないと意味無いだろ。
なんつーか、Promise知ってる俺カッケーな答えでしかないんだよ。>>30は。

n個にしたいなら、i < 10 の代わりに
i < n にすればいいだけじゃんｗ

だからそこを説明しろってこと。Promiseの説明全くいらんよね。

というか、これを書けないレベルの人がPromiseの使用を強制されられるところが
若干JavaScriptは歪んでる。まあこれも前から思っていることだが。

>>24本人、そしてそれ以外の人は、これでわかってるよｗ
http://echo.2ch.net/test/read.cgi/tech/1472401404/130

お前だけが分かってない。

>>33
まぁ、破壊されたものを次に渡してるし、参照型で渡ってるから気持ち悪いだけで、破壊せずに渡してもいいと思うよ。
多分嫌われるw

>>34
本質理解してないお前よりマシだけどな。
なんだあのセンス無いやつ。

>>35
thenの中はコールバック関数で遅延評価だから、whileだと終わったかどうかわかんないと思うけど、どんなソース想定してる？

>>39
いやPromiseで書くのはあくまで処理の事前予約だよな？
そこは変更不能だし、同期的に確定する。
もちろん中身の関数は実際には後に呼ばれるけど、
一般的にそれを「遅延評価」とは表現しない。

俺の想定しているコードなら、>>30をwhileに変えただけに近い。
とりあえず君の言い分が正しいのなら、>>30は間違いだということになるが、そうか？

>>40
あー、そういう事か。いや、間違ってない。面目ないな。

入れ替えると言うか、それごと変えるという事か。
それは再帰とどっちが良いのかは目的次第かもしれん。
俺は残り回数渡して再帰すると思うわ。setTimeoutで包んで。

>>41
>>23が「動的に」って言っているからそこは微妙なのだけど、
まあ初心者にそこまで厳密に言っても仕方ないからね。
多分あの質問なら単純に「可変長ループ」が分からないのだと思った。

それはさておき、>>28のコードは面白いとは思うが、
>>28を読める奴がこの質問はないだろってこと。
Promiseなら突っ込んだ時点でそこまでの処理は確定だが、
>>28なら途中の関数内で処理を変更出来る。
これを「動的に」と表現するのは自然ではあるが、
これを記述しようとする奴が>>24の質問はない。（と見た）

> setTimeoutで包んで。

またなぁｗ 余計な一言。
なんでsetTimeoutを含まなきゃならんのか。
これも何も分かってない証拠よ。

理屈はわからないけど、これやったら動いた！
正しい理解をせずに長年やったやつの末路だなｗ

んー、まあ俺は>>41の使い方ならsetTimeoutで包んだ方が妥当だと思うがな。

ただし俺はC派だからそういう余計な処理は出来るだけ入れたくなくて、
俺は実際にはほぼ直接呼び出しにしているが、その分気を使わなければならなくなる。
そういう面倒なことは無しにしようってのが昨今のプログラミングスタイルだろ。

つーか、お前も若いんだと思うが、噛み付きまくるのはやめい。
setTimeoutで包むかどうかは上位のコーディングポリシーの話だから、
「常に」どっちがいいとかいうことはないし、ここで白黒つけられることでもないよ。
むしろそこに噛み付いた時点で無知だと晒しているようなもん。
まあそれでも「技術的に」やり合うのならどうぞご自由にだが。

ご自由にされちゃたまらんわ
やり合うんだったら>>27の隔離スレでやってくれ

>>43
よく理解して実装してるにきまってるでしょ。
自分の経験書かないでよ。

>>46
いや、setTimeoutは不要でしょ
遅延処理をするわけでもないのになぜ使う必要があるのさ？

>>47
生粋のネイティブなPromiseなら、非同期になることは保証されてるけど、
どんなPromiseっぽいものかわからん現状安全側に倒すよ。
次の処理始める、ではなくて、
今もし、今回の呼び出しでキュー溜まってるならそれ終わらしてからやりたいし、
コールスタックも深くなるじゃん。

>>48
非同期の逐次処理で重要なのはコールバックでしょ
非同期処理が完了したことを確認するにはコールバックするしかない
seTimeoutはコールバックを楽に実装する機能がないわけで何の役にも立ってない

こんにちは、初歩的な話で恐縮ですが、
textareaの入力から複数行、行頭スペース・連続スペースを含む文字列を取得したいのですがJS側で何とかすることはできませんか？

>>50
できるよ

>>49
thenの中の話だが。
promiseのそれっぽいポリフィルだと、即時に関数呼び出しするから、
promiseの中でsetTimeoutしてた場合、そいつらが走る前に、次のPromiseが走るよね。
そうじゃなくて、キューイングすることで、もし何かが実行されていてもその後に実行されるじゃん。

あと、コールバックが書けない、は一番ナンセンスじゃない？
配列の最後のPromiseが、「コールバックを呼び出す」ってPromiseであれば良い。

>>50
それぞれ取りたい感じ？
valueで全体は取れるけど、あとは正規表現でマッチした部分使えば良いんじゃないかな。

取得ではなく出力の時に&nbsp;に置換するのを忘れていたことに気づきました……
お騒がせしました……

>>52
君はPromiseとsetTimeputを激しく誤解している気がしてならない

> promiseの中でsetTimeoutしてた場合、そいつらが走る前に、次のPromiseが走るよね。
そんなことはない
そもそも、非同期処理を上手く活用することを目的としているPromiseにそれが出来ないわけがないだろう
やり方は既出だが、ちゃんと理解してないのではないか？

> そうじゃなくて、キューイングすることで、もし何かが実行されていてもその後に実行されるじゃん。
君の言葉を借りるなら非同期処理に対してsetTimeputを適用したらsetTimeputの数だけキューが増えると思うんだが
setTimeputは同期処理を非同期処理にするのに有効だが、非同期処理にsetTimeputを使っても遅延処理以上の結果は得られない

> あと、コールバックが書けない、は一番ナンセンスじゃない？
「コールバックが書けない」とは誰もいってない

>>54
だからそれっぽいポリフィルだって言ってんじゃん。
日本語読めないならもう書かんほうが良いよ。
キューが増えていいんだよ。
promiseの中でsetTimeout(..,0)された物を先に動かしたいだけだから。

お前実装見ずに概念で話してない？

>>55
それはPolyfillがおかしいだけだろ
おかしなPolyfillを基準にされてま困る
setTimeoutは役に立たんという意見もスルーするし、お前の方こそ日本語を読め

>>56
あ、うん。
最初からそう言ってんじゃん。
まぁ、thenを持ったオブジェクトさえ返せば別にPromiseで無くともその辺誤魔化しつつ走ってくれる便利なやつなんだけどね。書いた関数。
なんでsetTimeoutするかの理解出来てないんだったら、同じようにcatch書いたときにどう例外オブジェクト飛んでくるか見たら？
catchで、setTimeoutしてthrowし直すとか割と普通っしょ。
コールスタックって言ったのになぁ。

そもそもpromiseってそんなに必要か？

>>57
Promiseが理解できていればsetTimeoutが不要なことがわかるはずなんだがな
「それっぽいPolyfill」とやらも具体例が皆無
必要なら完璧なzPolyfillを探すなり、自分でPolyfillを書くなりやれと
お前さんのPolyfillらしきものがsetTimeoutなのかもしれんが、無駄が多すぎだろ

>>58
ちゃんと処理が出来るならなんでも良いよ。
俺は嫌いだからeventEmittet的なものでイベント起こす。
イベントのリスナが一つとも限らんし、発火させるやつが一つとも限らんし。
そのイベントがリエントラントでさえあれば良い。

>>59
書いたでしょ。
>>48
で。
噛みつきたいだけならお前圧倒的に理解力足らんわ。

>>58
Promiseがなくてももちろん実装できる
Promiseの利点は統一されたインターフェースで非同期処理を管理できること
自分なりのコード資産があるのならPromiseを使わなくてもいい
が、他人に読ませるならPromise一択だな

>>61
>>48のどこに「ポリフィルっぽいもの」の具体例がある？
余所様のPolyfillが使用できないなら自分で書けばいいのにな

>>62
error,resultほうが余程そして統一されてるんでは？

>>63
逆じゃん。
生粋のものであれば、の方でPromiseの定義してるでしょ。
もちろん使うなら内製はするだろうけど、基本的にはポリフィル自体を使わんよ。

>>58
自分では使わないが、
意識高い系APIが返してくる場合はどうしようもないだろ。

◆SEdFBOkLSw お前はポリフィル使ったらだめだよ。
中身が違うだろ？ｗ

>>65
> 生粋のものであれば、の方でPromiseの定義してるでしょ。
そんなことは聞いてない

> promiseの中でsetTimeoutしてた場合、そいつらが走る前に、次のPromiseが走るよね。
こんなおかしなPolyfillがあるならそのPolyfillをDL出来るURLを出せ、って事だ
正直、そんなPolyfillがあるなら「Promise」と呼ぶのもおこがましいレベルだが、
実際のところは君が書いているPromiseのコードがおかしいだけでPolyfillに罪はないと思ってるよ
どうせsetTimeoutをPromise化してないんだろ？

promiseの中でsetTimeoutしたらその先まで面倒見るのは
promiseの仕事じゃない気がするんだが

どんなコードを前提にしてるのかさっぱり分からん

◆SEdFBOkLSw がPromiseを理解してないってことはわかった

>>69
Promiseの中でsetTimeoutした場合に、その先まで面倒見るかどうかは使う側の問題なのでどちらとも言えない
Promise自身は内部で何をしているかに関わらず、resolveまたはrejectが呼ばれるまで次の処理に進まずに待つだけだ

setTimeoutの処理を待ちたいならsetTimeoutの中でresolveを呼べばいいし、待たないならsetTimeoutの外でresolveを呼べばいい

Promiseなんてちょっと賢いコールバックの仕組みでしかなく、正しく使えるかどうかは使う側の問題
まあそのちょっと賢いに慣れてしまうとわざわざ他を使おうなんて思えなくなるぐらい便利なんだがw

>>71
ありがとう

setTimeoutの中でresolveを呼んでる場合
引数を受け取らずに次が走るって状況が想像付かんのだわ

一つ教えて下さい。
Promiseで実行指定した処理群内部では
タイマー関連を使えないのでしょうか？
これが使えないならば、WebWorkerでも極力使わない方が良い様に思います。

理解してない、というか理解したつもりになってる人が、
それでよいと盲信して使っているが故にこうなる見本じゃん。

>>74
鏡

>>75
おまえに必要なもんだな。

ここでも◆SEは能力不足だって指摘されてるなｗ

向こうのスレでは ID:EZVA2rF2 が頑張ってるな

>> はい、で？お前は何がブラックボックスだって？
> うん、得体のしれないポリフィル、に対して言ってた。
> 読めば良いだけ、なら、そんな工数無駄なので、作れば良いだけ。
この人(◆SEdFBOkLSw )、他作製コードは全く使わんつもりなのかな
このポリシーではライブラリ系が全く使えん
それとも、jQueryやらReactやらは盲目的に信頼するタイプなのか
信頼の多寡をはかる指標の問題だろうが

>>79
ブラウザはソースコードを全部読んで
ライブラリは全部自分で作るらしい。
コストは全部客持ちだから何も痛くないだってさｗ

>>80
> ブラウザはソースコードを全部読んで
> ライブラリは全部自分で作るらしい。
わざわざブラウザのソースコードを読む理由が分からんのだが、実装依存な挙動を確認する目的？
実装依存に頼るコードは様々な対策をやりきってどうしようもないときぐらいしか出番がないわけで
定常的にはWHTWG HTMLやECMA262を読む方に時間をかけると思う
(まあ、その辺の仕様書を読まないからわざわざソースコードを読みにいっているのかもしれないが)

>>81
> わざわざブラウザのソースコードを読む理由が分からんのだが、実装依存な挙動を確認する目的？

◆SE曰く。全く同じ動作をしていて同じコードが動いてテストコードを使ってテストしていても
中身が違えば、ブラウザごとに違うテストが必要になるって思ってるらしいよｗ
挙動じゃなくて中身のコードが同じかどうかで考えてる。

だからES6という言語で書いたソースコードをそのまま動かす（テストにも通る）のと
babelを使ってES5にして動かす（もちろんこちらもテストに通る）のとで
動きが全く一緒だけど、それはbabel用の言語（？）だって言い張ってるｗ

>>79
全くじゃないけど、基本的には使わんなぁ。
jQueryは検証しまくったし、パッチもだいぶ出したから使うけど、それでも割と古い。
Reactは使わんねぇ。個人的にはRiotが使いたいけど。
似たようなのはあるが、仮想DOMでは無いんだよなぁ。

>>81
どっちも読んでるよ。
ブラウザ見るときは、例外として何という文言で飛んできてくるか、とか。
ログに落としてたりするから。
FireFoxはmessageにスタックトレース飛んでこないしね。
例外が起こる、とだけテストしても無意味だし。

>>83
仕様書を読めるならPolyfillを書けばいいのになぜ書かないんだ？
いつまでも古いES用のコードにしがみつく理由が分からん
そのやり方なら動作保証している最も古いブラウザに合わせたコードしか書けないだろうに

setTimeoutを使ったコード例が欲しいな(setTimeoutはPromiseの代替にはならないと思ってる)

> setTimeoutを使ったコード例が欲しいな(setTimeoutはPromiseの代替にはならないと思ってる)
当たり前。

Promiseは終わったと言うイベントを通知するだけ。

setTimeoutでいえば、setTimeout(function() {・・・}, 1000)の
「function() {・・・}」この部分の代替。
別スレッドでn秒待つとかいうことはできない。

>>84
しがみついてるわけではなくて、要件定義で絞れるならネイティブにそう書くよ。
ポリフィル使う意味もあんまないと思うわ。
それなら、ライブラリ作ったほうが余程建設的だと思う。
ライブラリ自体の実装を、どれ用、で分ける事はあるだろうけど、面は同じにしとくよ。

>>86
例えば、ES3、IE8対応の自作ライブラリを永続的に使うとしよう
ライブラリ依存から抜け出さないし、ES7→ES8と機能が増えていく度にES5,6,7,8を全て自作ライブラリで担当するのでライブラリの負担は増えていく
社内チームで作っていくなら自作ライブラリを更新する度に制作したあなた以外の人に教えるコストがかかる
ドキュメントも作る必要があるだろうし、後に入社する新人は膨大な自作ライブラリを覚えなければならない
あなたのスタンスは自分一人で作って自分一人で保守している感覚なんだよな…

で、setTimeoutのコードはスルーするんだな

>>82
前半3行は意味が分からんのだが、「中身」とは何を指してるんだ？

> 動きが全く一緒だけど、それはbabel用の言語（？）だって言い張ってるｗ
Babelは可能な限りES6に似せてトランスコンパイルするが、同じではないと思うぞ
Polyfill可能な機能は大部分を同じに出来るが、構文が異なる機能を完全に同じにするのは難しい
トランスコンパイルされたコードを想定して書くのはおかしなことではないかと

>>85
俺に何を説明したいのかよくわからんが、>>84で書いたようにsetTimeoutがPromiseの代替にならないのは理解している
Promiseはコールバックで非同期処理完了を検知するわけだが、Promiseを使わなくともコールバックで完了を検知するしかない
だから、自作ライブラリで実装するならコールバックを管理する形になるはずでそこにsetTimeoutの出番はない
少なくとも、発端となった>>23-24にsetTimeoutを勧める理由はないはずだ

>>88
> Babelは可能な限りES6に似せてトランスコンパイルするが、同じではないと思うぞ
同じものと、不完全なものの二通りある。
ポリフィル用語では前者はshim、後者はshamと呼ばれているものだよ。

> 構文が異なる機能を完全に同じにするのは難しい
babelは構文を置き換えるのだから、構文の違いはまったく関係ない。
完全に同じにできない理由は、JavaScriptの内部の機能に依存するから。

同じゃない部分っていうのは動きが違うわけじゃなくて一部が実装されてない（できない）
だから動く部分に関しては完全に同じだよ。

> トランスコンパイルされたコードを想定して書くのはおかしなことではないかと
想定する内容は「一部の機能を使わない」ようにするということだけ。

でもこれって難しい？
だってそもそもブラウザだってES6のすべての機能をサポートしているわけじゃない。
babelを使わなかったとしてもお、普段からブラウザで動くJavaScriptコードを書いている人がやってることだよ。
このブラウザでは使える機能だっけ？って調べながらコード書いている。

トランスパイルできないコードを想定して書くのも
ブラウザが対応してないコードを想定して書くのも大きな違いはない。
むしろ多種多様なブラウザを想定するよりもbabelがブラウザの違いを吸収して
ブラウザ間の違いを減らしてくれる方が「想定する必要」が減って楽でしょ？

> Babelは可能な限りES6に似せてトランスコンパイルするが、同じではないと思うぞ

ここは完全に間違ってるから訂正ｗ

babelはES6に対応していないブラウザで実行できるように、
ES6のコードを可能な限りES5のコードに変換するもの
他の言語からES6やES5のコードに変換するわけじゃない。

>>87
前半はわりとそうかな。
アーキとしてチームで作るし、教育もドキュメンテーションもするし、規約もQAも書くよ。
一人じゃ無いよ(笑)どんな会社だよそれ。。

setTimeout解決してない？なんか誤読してるのかもしれないし、何がひっかかってるの？

>>89
うん、そういう意図では使わんのだが。本来のコードに勧めてるわけでもない。
何故二人が、あってもいいって発想で、お前だけ絶対に無しだって発想なのか、どこが差なんだろ。

>>90
関係あるんじゃ？構文の違い。
確か、いくつかが言語仕様上変換しようがないから、
意味合いの変わるコードになるよ、一般解においては結果は同じだけど、とテヘペロしてたような。
またリポジトリ見てくるか。

>>93
質問していい？

babelで変換したコードはリポジトリに入れたり
変換したコードは必要ない限り見たりテキストエディタで
修正したりしないんだけどそれはわかってる？

>>92
Promiseっていうのはthenでつなげるためには
Promiseオブジェクトを返さなきゃいけないと思ってるのかもしれないけど、

Promise.resolve(1)
　.then(i => Promise.resolve(i+1))
　.then(i => Promise.resolve(i+1))
　.then(i => Promise.resolve(i+1))
　.then(i => console.log(i))

こういう書き方も問題ないんだよ。

Promise.resolve(10)
　.then(i => i+10)
　.then(i => i+10)
　.then(i => i+10)
　.then(i => console.log(i))


setTimeoutはそれを入れる明確な理由があるのであれば
（「念のため」は明確な理由ではない）入れるべきだが、
理由がない場合は入れない。単なる無駄な処理。

あんたがディスられてるのは、理由をいわずに
setTimeoutを持ち出してきたから。

>>94
うん、同じコンパイラが確保できること、納品としてbabelかけたあとのものを納品しない、が前提であれば、わかってるけどそれがなにか？
>>95
知ってるよ。
中で、一連のJSが走り終わってから走ってほしいという意図で、setTimeoutやら、setImmediateを使われていたら、
こちらはその意図に合わせて、非同期に呼んだらないとね、って話で、だからこそレベル低いポリフィル引き合いに出して、ネイティブなら、って言ったんだけど。

理由が理解できてないだけだったか…

>>96
> 中で、一連のJSが走り終わってから走ってほしいという意図で、setTimeoutやら、setImmediateを使われていたら、

そんな話全くしてないよね？
何先走ってるのさｗ

いつsetTimeoutを使う必要があるかを考えて見ればわかると思うんだけどな（苦笑）

まずPromiseを使うときって言うのは、通常は非同期処理を行うAPIを使う時、
同期処理であればそもそもPromiseを使う必要が無い。

非同期処理を行うAPIを使うならば、非同期処理のAPIがsetTimeoutと
同じ効果をもたらすのでsetTimeoutを使うまでもなく一連のJSが
走り終わってから実行になる。

つまりsetTimeoutを使う必要があるのは、
「Promiseを返す関数の中で非同期APIを使ってない場合」に
限られるということ。

何も考えずに付け加えれば万事OKみたいに扱うものじゃない。

>>98
>>48でも、もし、キューが溜まってるならって言ってるし、
>>52では同じこと言ってるんだけど、
憎さのあまり読んでなかったのかな。もしくは「キュー」が何のキューなのか理解できてなかったのか。

付け加えてもなく、最初から俺はそうってるし、
「使っていない」なんて元にはないんだから、
「安全側」って言葉が出てくんだけど。

あまり「安全側」という言葉を遣うなよ。

理由を明確に示していない「安全側」というのは
とりあえずこうしておけばうまくいくんじゃね程度の
浅い考えでしかない。

なかなかいいサンプルを思いつかなかったが
やっと思いついた。

var p = Promise.resolve(1);
setTimeout(function() {
　// 1秒も待っているので、pは確実にresolveされたPromise
　console.log('start')
　p.then(i => console.log(i))
　console.log('end')
}, 1000);

この場合、start -> end -> 1 の順で表示される。
ChromeとFirefoxと有名なポリフィルのBlueBirdで確認した。

ここからわかるのはthenを使って呼び出されるのは必ず非同期になるということ。
つまりPromiseを作る段階でsetTimeoutが不要であるということを意味する。

世の中にはPromiseの仕様通りに動かないバグが有るブラウザやポリフィルが
存在するかもしれないが、そんなものに対応するのは「安全側」とはいわない。
問題が確実にあると分かってる場合にだけ問題に対処せよ。

もしかしたら世の中の何処かにバグが有るのでは？という可能性に対応するのであれば
for文にすらバグがあるかもしれないって話になるだろｗ

>>102
そうじゃない、何故1秒も待つのに使うものと、setImmediateと比べんのかわからん。
DOM弄って0待つ(DOM構築待ち)とか、そういうのじゃん。
getElementById("hoge").innerText=xxxxxx
setTimeout(function(){
//hogeの大きさ見たりする処理
},0)
みたいなやつ。

>>102
thenを使ったら必ず非同期になる、なんて言語仕様に書いてあるのにそういう検証してなんの意味があんのかわからん。

>>102
問題があるとわかってから対処はその通りだね。
ただ誰のどんな環境かわからん質問への返答としては、安全側としか言いよう無くない？

> thenを使ったら必ず非同期になる、なんて言語仕様に書いてあるのにそういう検証してなんの意味があんのかわからん。

だからsetTimeoutはいらないだろ？

> setTimeout(function(){
> //hogeの大きさ見たりする処理
> },0)
> みたいなやつ。
お前が俺が書いたコードの意図がわかってないだけ。


> ただ誰のどんな環境かわからん質問への返答としては、安全側としか言いよう無くない？

誰のどんな環境が分からないというならIE6の可能性もあるが？

なんで誰のどんな環境変わらんと言っておきながら
「Promiseが使えるが仕様通りでなく、その仕様通りでないというのは、
Promiseのthenが同期的に動くと言うバグがあること」という
自分の都合のいい環境に限定してるんだって話なんだが？

どんな環境かわからないなら、仕様通りの環境を前提にするべきだろ。

仮にPromiseが仕様通りに動かないブラウザが有ったとして、
仕様通りに動くBluebirdを使えば、
すべてのブラウザで同じ挙動になるわけさ。

仕様外のブラウザがあることを懸念するならば、
素直にポリフィルを使ったほうが良い。

promise実装に問題があるならコールバック地獄に書き直せば良いだけの話じゃ無いの
奇策使ってまで残す理由が分からん

素直に、読んでませんでしたと何故言えんのだろうか。

>>105へのレスをお願いします。

>>107
Promise使わないと死んじゃう病気なんだろ。
典型的な「手段と目的の混同」でしかないけど、割とどこの界隈でもいると思うが。

>>110
これは「コールバック"地獄"」と書いてあるところから
ジョークと受け取って欲しいってことだと思ったがｗ
いや君が分かってやってるのなら良いんだけどさ。

以下のHTMLがあるんですが上のclass="a"のDIVを上のtitle内に、
下のclass="a"のDIVを下のtitle内に入れたいのですが
Jqueryでどのように書けばよいでしょうか？
どなたか教えて下さい

<div>
<div class="title"></div>
<div>
<div class="a">111</div>
</div>
</div>
<div>
<div class="title"></div>
<div>
<div class="a">222</div>
</div>
</div>

$('.title').append(function() {
return $(this).next().find('.a');
})

素晴らしいです
ありがとうございました！

良いってことよ。でもまあjQueryのスレはこっちだからな

+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/hp/1465566635/