+ JavaScript の質問用スレッド vol.135 +
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」だけでなく「意見」を出しても良い。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。
【条件】期待する回答の条件を書いてください。
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける＝荒らしです
◆開発者ツール(Developer Tools)の基本的な使い方
▼諸注意
- 本説明では Google Chrome の開発者ツールの名称に従います。他ブラウザで使う場合は適宜読み替えて下さい。
- Edge- でコンソールを使うには予め開発者ツールを起動しておく必要があります(開発者ツールを起動しないと 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プロパティの算出値を表示("font-size: 1em" を指定していても算出後の "*px" で表示される)
- [Properties] タブ … 選択したDOMノードのプロパティを表示
▼コンソール
1. JavaScript コード上で console.log('Hello, World!'); と入力
2. [Ctrl] + [Shift] + [I] キー(IE は [F12])で開発者ツールを開き、[Console] パネルを開く
3. [Console] パネルに "Hello, World!" と表示される
(※window.alert() は String 型に変換されますが、console.log() は Object 型の中身をそのまま表示してくれます。)
◆JavaScriptの実行速度
JavaScriptの速度は「ブラウザ名」「ブラウザのバージョン」「PCスペック」に依存します(ブラウザのバージョン毎に最適化具合が異なります)。
速度の疑問解消の為に http://jsperf.com/ （githubのアカウントが必要です）にコードをUPしてブラウザ毎に速度計測する事を推奨します。
例外として、仕様における理論上の速度が明確になっている場合があります。
例えば、正規表現によるマッチング処理を考えた場合、「RegExp#test > RegExp#exec > String#match」は ES5 仕様で保証（要出典）されています。
ES5 仕様において RegExp#test が最も処理数が少なく、String#match が最も処理数が多いことが明確だからです。
ブラウザによっては RegExp#test の最適化が十分でなく、String#match の最適化が RegExp#test より十分であれば逆転する可能性はありますが、各メソッドの最適化が一律であればこの前提が崩れる事はありません。
■各種仕様
◆ 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 和訳)
◆ 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
http://fiddle.jshell.net/fH4cC/180/show/light/
■FAQ
http://fiddle.jshell.net/vSqKr/44/show/light/
■前スレ
JavaScript の質問用スレッド vol.134
http://mevius.2ch.sc/test/read.cgi/hp/1528096978/
仕様上できないのですね。
残念です。
<div id="div-a">
<input type="text" id="text-a" value="あいう">
<input type="text" id="text-b" value="abc">
</div>
var input_elems = $.map( $('#div-a > input'),
function(elem, index) {
return $(elem).attrAll(); // this === element
}
);
Cookies.set( 'input', input_elems ); // 設定
obj = Cookies.getJSON('input'); // 取得
console.log( obj );
結果
id: "text-a", type: "text", value: "あいう"
id: "text-b", type: "text", value: "abc"
Cookie のライブラリは以下を使っています。
js-cookie/js-cookie
https://github.com/js-cookie/js-cookie
$.fn.attrAll は、以下のブログで定義されています。
要素の属性を全部取得する
https://hokaccha.hatenablog.com/entry/20130819/1376895914
あとでそれを再セットするって input の数や種類に依存せずにかけませんか？
div にも input にもユニークな id が振られてます
input.type は今の所 text select と checkbox だけです
native js でも jQuery でもいいです
前スレの>>978じゃないけど、
要素の属性取るならそんなプラグイン使わないで
jQuery標準の $.serialize か $.serializeArray を使えば良いんだよ
<form>要素以下になくても使える
今回の場合はserializeArrayの方が使い勝手良いかな？
https://api.jquery.com/serialize/
https://api.jquery.com/serializeArray/
で、実はそんなのは簡単で、面倒なのはこっち
> input.type は今の所 text select と checkbox だけです
フォームの中身を全て保存して戻すってのは
以前に実装したことあるけど、
typeみてselectだったら〜checkboxだったら〜みたいな
コードを書いた記憶がある。意外と面倒くさい
input type="file"があったら面倒なことになりそうな
そうでもないか？
その質問に答える必要はない
var data = {};
$(":input").each(function() {
switch(this.type) {
case 'checkbox':
data[this.id] = this.checked;
break;
default:
data[this.id] = this.value;
}
})
データをかき集める所はこんな感じかな
idでユニークになるならserializeArrayみたいに配列で持たなくていいね。
ちなみにmultipleなselectには対応していない
こんな風にtypeを使って見分けることになるんで
> input の数や種類に依存せずにかけませんか？
に関しては、書けません。というのが答えになる。
<input type="select"> が存在しないかもしれない、と自分を疑うことから始めた方がいいよ
https://html.spec.whatwg.org/multipage/input.html#attr-input-type
時間の無駄。わかってる結論へ至る道はお前１人で勝手に進んでろ
serializeArray は、送られる属性が少ないし、
successful controls しか送られていない
使いどころが難しそう
フォームのGET・POSTで送られる情報の
全てを網羅してるぞ？
type, id が無いから、使いずらいかも
input.type には必ず、text, select, checkbox を指定しておけば良いかも
name, value を使って、name がユニークなら、コントロールを特定できるのか
ほぼ同一のformが複数あるなんてしょっちゅうあるから
汎用性なんて考えない方がいい気がする
<option>Single</option>
<option>Single2</option>
</select>
select は、input タグじゃないのか
分からない場所に突き進む道を選ぶのね、ご愁傷様
俺はそんな道に進まないって意味だよｗ
データの作成・保存はカスタムエレメントで閉じておくべき
例のvalueの問題はinputやtextareaを継承してonchangeで見てもいいが
contenteditableとして要素ごと作ればobserveも統一できるし見た目の調整もやりやすい
正しい仕様を確認するための質問を無視する→理解の放棄
HTMLはその場合の操作も定義されている
>>The type attribute ...... the invalid value default are the Text state.
そりゃそうだが、将来的にtype属性値の種類が増えるかもしれんし、わざわざ不正値を指定する理由はあるまい
俺は最初からわかってる結論へ至る道の到着点にいるぞ？ｗ
/:::::::-、:::i´i|::|/:::::::::::ヽ
/::::::,,、ミ"ヽ｀ "゛ / ::::::ヽ ＜ 一億総活躍
/::::::== 卍 `-::::::::ヽ
l::::::::／ .,,,=≡, ,≡=、l:::::::l ／.￣） 英訳は「Promoting Dynamic
|:::::l゛ .,／･＼,!.／･＼ l:::::::! / /二､.
|`:::| :⌒ノ/.. i＼:⌒ |:::::i 丿 Ｙ .i Ｙ Engagement of All Citizens」
(i ″ ,ィ____.i i i // （ ゝ' ﾉ ./ /
ヽ i / ■ .i i / ,ゝ-､_）--'-' （全国民の精力的な参画の推進）
l ヽ ノ `ﾄｪｪｪｲヽ、/´ /{ ゝ､＿_ﾊ|ﾍ
／|、ヽ `ー'´ ／ ｨ'/ﾊ＿＿＿＿ﾊ つまり国家総動員
／/l ヽ ｀ "ー−´/ ////////////ﾉ
,,ｨ''"/// | ＞＜ ／///////////{//////////／
r''"////// ..|/:::::ﾉ//////////////}/////////Ｙ
////////| /:::::{///////////////{//////////
int Number;
とか
string name;
とかは
例えばここ何年か今までintだったDOMの値が
高画面解像度デバイスのためにfloatになってきる
それは型キャストで解決できる程度の問題かな
floatを返していても型がintだったら自動的に
小数点以下切り捨てられる
むしろその方が想定しない型にならないのでいいかもね
>高画面解像度デバイスのためにfloatになってきる
どういうこと？
リキッドデザイン的なものに変わってきた、ということでは
https://www.w3.org/TR/cssom-view/#changes-from-2013-12-17
だけどChromeではまだサポートされてて
ズームしてdocumentElement.scrollTopなんかを弄ると分かる
200％以上に拡大すると分かりやすいだろうけど
特に低スピードのスクロール時にここで実際に役に立つことが分かる
http://output.jsbin.com/qedore
Javascriptの基本的な型の作り方はvarなのかなって
普段何の仕事してんの？
ニート？
ジャップのくせに
「JAP」は昔は米国新聞でも普通に使われてたただの略語というか日本の愛称だった
たかが三文字の言葉であれこれ思うのも馬鹿らしいよ
どう言うことになるか分かるか？
リアルで言えない差別用語をネットで
使って吠えてる糞野郎
意味分からん
中国人
フィリピン人
朝鮮人
普通に使うぞ
変な嫌悪感を持ってるのはそういう学校教育された中年世代だけだろ
＞米国では、多くの学生が成績向上や適性試験をパスするために、リタリンを治療以外の目的で服用しているとの報告がある。
差別主義者は薬物でも服用させなければ駄目だな
市ぬかもしれないが生きてても仕方ない奴らだからどうでもいいわ
韓国人 は入らないんか
極端な白黒思考になる
これが差別主義者
道徳ピル飲んで知能を上げるしかない
薬害で市んだら害虫が一匹消えたという事でそれはそれでおっけ
言葉で説明してくれ
だからその違いを吸収するライブラリが必要になる
原則DOM標準は後方互換性を守る
JSのライブラリはバージョンアップで簡単に切り捨てる
ライブラリを使ってるとむしろ追従が大変になる
バージョンアップで切り捨てるって旧UAを？だったら旧バージョン使い続ければ良いのでは？
あなたは数文字節約できるかもしれないけどこっちはいい迷惑。
パフォーマンスや新機能のためにバージョンアップしたくても
再設計が必要なほどAPIが大きく変わってることが珍しくないということ
YouTubeのCr以外で遅い問題もPolymerがそうだからYouTubeが追従できないから
あなたは数文字節約できるかもしれないけどこっちはいい迷惑。
> JSのライブラリはバージョンアップで簡単に切り捨てる
> ライブラリを使ってるとむしろ追従が大変になる
どのライブラリ？ AngularとかReactとかかな？
なんか更新頻度高いしね
その点jQueryは安定していていいよ。
そもそも追従するほどバージョン出てないしｗ
それ、単にそのライブラリ・フレームワークの設計が杜撰ってことじゃ
その互換性の部分以外のとこも大丈夫なのか？となりそう
偉そうな事言うのは嫌なんだけど
vueやreactの方が絶対いい
杜撰ってわけでなくJS界のトレンドなんだろうな
jQueryみたいに切り捨てられないと（それでも利用度からすれば比較的切り捨ててる方）
負の遺産化するし
jQueryは負の遺産にはならんよ。
DOM操作を短く簡潔にするためだけのものだから
使わないならjQuery1行をそのまま数行に対応付けて書き直せる
冗長になりますよってだけで誰もやらないけどね
負の遺産っていうのはAngularやReactなどの
最近のフレームワーク。違う書き方にしようとしたら
全体に手を入れなければいけない
jQueryのようなライブラリは設計構造はそのままで済む場合が少なくない（※）が使用部分が広範になりがちで書き直し量が多い
※例えばアニメーション関係をjQueryに頼っていると構造にも絡んでくる
独特な機能を提供するライブラリは関係部分だけ書き直せば済むといえなくもない
意識高い系の人がフレームワークで使って作ったサイトをサーバに乗せるのに凄い苦労した経験あり。
でいけたんだけど、element.style.width="100px"みたいにプロパティと値をわけて書くのと何か違いはありますか
element.setStyle({
"width": "100px",
"background-color": "green",
});
とかがあればいいな
prototypeいじりたくないけど
・element.styleにはCSSStyleDeclaration オブジェクトが入ってる
・element.styleに直接CSS定義テキストを代入できる
・element.styleに直接CSS定義テキストを代入した直後でも
element.styleにはCSSStyleDeclaration オブジェクトが入ってるし
element.style.width を変更することもできる
CSS定義に変更があった場合変更内容を元にelement.styleを再設定してるという感じだと思うんだけど
こういう挙動はどう理解したらいい？
より具体的には、ブラウザの実装がそうなってるというだけなのか
それとも同じような挙動をユーザがjsコードで実現できるのか
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Proxy
Object.assign(element.style,{
width: "100px",
backgroundColor: "green",
})
>>82
内部Proxyだと理解したら良い
SelectorsAPIなんてjQueryの劣化版だろｗ
単にNodeListを返すだけで、そのNodeListを扱う方法まで作らなかった
jQueryはNodeListみたいに単に要素の配列を返すのではなく
要素の配列を内包した、jQueyrオブジェクトを返すことで
要素の配列そのものをメソッドで操作できる
ここが重要な所なのに、SelectorsAPIはそれを理解せず
単に要素の配列を返しただけ
あとマウス座標取得決定版みたいなのも欲しいです
$(event)みたいにできたらいいのにな
thx
あるんだな・・・意義はわかんなくはないけど正直どうかと思うが・・・
あとでじっくり読んでみる
getContextに対応するだけでいいの？
canvas自体に対応しないとあまりメリットなくない？
jQueryになれてるなら、D3.js を使うのが良いと思う
canvas操作をjQueryライクに書くことができる
俺も普段はjQueryを使うけど、canvasを操作したい場合はD3.jsを使うよ
こんなk何時
https://codezine.jp/article/detail/7459
> D3.jsのセレクタを用いて宣言的に記述すると、以下のように簡潔に記述することができます。
> d3.selectAll("p").style("color", "white");
> コードも、d3.selectAll("p")ですべてのp要素を取得、style("color", "white")で
> 文字色を白に設定、と直観的で分かりやすくなったのではないでしょうか。
> $(event)みたいにできたらいいのにな
$(window).on('mousemove', function(event) {
console.log(e.screenX);
console.log(e.screenY);
console.log(e.pageX);
console.log(e.pageY);
console.log(e.clientX);
console.log(e.clientY);
console.log(e.offsetX);
console.log(e.offsetY);
});
× console.log(e.screenX);
○ console.log(event.screenX);
以下同じ
今だったらもしかしたらゲッターセッターになるのかもしれないけど
それらがJSに無かったころからCSSOMはあるしね
配列のlengthのようなものだよ
array.lengthを書き換えても即座に自動的に書き換えられたりしないだろう
TypedArray の様にゲッターやセッターではなく
プロパティアクセス時に0や１などと同等にフックして内部プロパティを変更してる
もはやそれActionScriptじゃねーの？
昔ES3（ECMAScript 3）っていうのがあって、その後普及したのがES5
今はES6という名前だったのがES2015に変わって、ES2016だとかES2017だとか・・・
それは良いとして、ES3とES5の間にあったのがES4
ES4の夢は壮大で、クラスベースで型もあって・・・
そのES4に完全準拠することを目標にActionScriptは開発されていた
ところがES4の夢があまりにも無謀で破綻した。
そして型などの機能を減らして現実的にしたES5ができた
ActionScriptは破綻したES4相当なんだよ。消えたES4の成れの果て
JavaScriptに準拠しつつ型を取り入れたのはTypeScript
とasync関数が繋がってるのをイメージしてください
Aから始まりEが完了すれば順にC、Bと完了してAに戻ってくるイメージです
ここで、Dの段階でBからの流れをやりたいとします
しかし、Dの次にBを続けると、
それまでのB → Cの流れの中で消費されているメモリが残ってしまいます。
もうDや過去のCやBに戻らせる必要はありません。
しかし、Dを開放してB'を開始すると、Aまで完了してしまい、それはよろしくありません。
A → B → C → D
まで来たところで
A → B → C → D → B' → C' → D'
となるのはメモリリークしやすく、チェーンが非常に長くなると色々なバグも発生しやすく
デバッグのしやすさにも関わってくるので避けたいです
とはいえ
A → B → C → D -...> B' → C' → D'と切り離すと
Aで行っている初期化・完了・例外処理から外れていってしまうため問題です
理想的には、チェーンをA → B' → C' → D'
とつなぎ直したいのです
どうしたらよいでしょうか
一応今はBで作業キューを持ってそれにCを追加する形にしていますが、
いかんせんコードがキレイではありませんし、僅かな仕様妥協が入ります
おそらくPromiseのラッパー的なとこから、根本的な非同期チェーン構造を
素朴なPromiseではなく１から考え直して別の物にすべきだと思うのですが
いいアイディアは無いでしょうか
全てのasync、async generator関数でCancelの概念と実装をしたら良いのでしょうか
全てのawait時にそれがCancelかどうかチェックして処理をするとか
それはそれで漏らせないコードが多くなりそうですし、処理が複雑になりそうです
一応今は各処理にセッションを渡すようにしていて、表に影響がある処理ではそのセッションが切れていたら何もしないことで、
特にイベント等から繋がる不要なチェーンが発動しても空回りさせることで影響がないようにしています
今はメモリの開放は時間経過やイベントをあえて見捨てたチェーンに伝わらせて
空回りを利用して自然と勝手にほぐれて、その後GCが回収してくれることに頼っています
しかし、今回は下手に空回りもさせたくないという状況です
コードを極力シンプルに保ちながらしっかりしていてかつ柔軟性も持った非同期処理構造を作るにはどうしたらよいでしょうか
例えば非同期でも、場合によっては完了を待たずに次に進みたいことってありますよね
例えば、Loadingを表示するとき
await View.fadeInLoadImage()
let file = await Network.fetchFiles( )
await View.fadeOutLoadImage()
とするとフェードイン、アウトの時間が無駄なので
View.fadeInLoadImage()
let file = await Network.fetchFiles( )
View.fadeOutLoadImage()
とすると思います。ですが、このフェードが動いているときに
コンテキストがリセットされると、色々懸念事項が生まれます
そういうのもスマートに扱える方法を知りたいです
・開示されたごく一部だけで単純な仕様ではないことがわかるのに
・全貌の情報なしに
・コードがきれいかどうかや柔軟性など曖昧な要求を回答できる人間はいない
>let file = await Network.fetchFiles( )
>View.fadeOutLoadImage()
>とすると思います。
let file = await Network.fetchFiles( )
だけやればいいじゃん馬鹿なの
具体的な細かな話は気にしなくて結構です
私が知りたいのは、皆さまが一般的にこういう問題を抱えないために使っている
オススメTask系のフレームワークだったり、普段意識してる設計パターンについての話です
コードが綺麗とか柔軟とかいうのも、厳密に定義しようとしてもらわなくて結構です
そこは私がどう感じるかではなく、皆さんが素直に自然と良いと思ってる手段を知りたいと言うだけです
> しかし、今回は下手に空回りもさせたくないという状況です
下手に空回りさせないように地道に書けとしか
F/W信奉者にありがちだが解決してくれる何かを探すのを止めてみるべき
質問が意味わからん。最初にasyncって決めつけてるのが駄目なんじゃないの？
asyncは実装なんだからそれを使うと決めるのは最後。
実装の話は忘れて、何がしたいのか綺麗にまとめたら？
あんなごちゃごちゃしてたら読む気にもならんよ
function process() {
A();
B();
C();
D();
B();
C();
D();
}
普通に書けばメモリリークにもならんし、
何が言いたいのかさっぱりわからない。
ここを出発点として、何が言いたいのかをまとめろ。
一行にまとめるとこんなかんじ？
なんかデータ読んでる最中に(let file = await Network.fetchFiles( ))
フェードイン/フェードアウトみたいなことしてるんだけど(View.fadeInLoadImage())
読み込み中止ボタンを追加したいんだが(Cancelの概念と実装)
そんなときどうしたらいいの
って質問なんだろうか?
>全てのawait時にそれがCancelかどうかチェックして処理をするとか
>それはそれで漏らせないコードが多くなりそうですし、処理が複雑になりそうで
自分で細かく書かなくてもうまいことやってくれる何かが
希望のようだが、それをハッキリと書かないところをみると
フレームワークやライブラリ推しの書き込みの準備行動じゃねーかな
地道に書くのは良いのですが
この先あちらもこちらもその場その場に書いていくと
メンテ面とか手に負えなくなって破綻してしまうかもしれないので
まだ取り返しの付く段階で場合によっては基礎システムを１から挿げ替えたほうが良いかもと思った次第です
>>105
現在Workerも使った大きく分けて十種類程度のタスクモジュールがあり、その中の関数の殆どが非同期もしくは並列に動いている状態です
最初はコールバックでも良いような規模で、その後async関数に切り替え、途中から自作イベント管理を追加し。。。。。。
という感じで大きくなるごとに対策してきました。
もう次に何かするなら、それで最後まで行きたいので相談させてもらっています
>>106
それで直ちに問題が会って動かなくなるというわけではないのですが、そうしたくないいくつの理由があります
・AからDまでの生存期間がそれなりに長い（ユーザーの操作次第、通常数分〜数時間程度）
・BからDまでは無制限に繰り返される可能性がある（ユーザーの操作次第）
・BからDまでで大量のリソースを使い得る（通常数十MB〜数百MB）
また沢山イベントハンドラやフックが残ったままになるのが気持ち悪い
（BからDまでが終われば生きた参照が無くなるのでGCによって自然と開放される）
その通りですが、最初は問題なかったけれど複雑度が上がって無理が出てきた現状を
改善できる今より一歩上の非同期取扱概念（コツ）を知りたいと言うだけです
例えばPromiseにしてもCancellableだったりCancalTokenだったり
async generatorの代わりにObservable系を使うという手もあると思います
そういうちょっとした変更やラッパーで乗り切れるのではないかと感じています
>>108
それは例です。実際はそういうコードはありません。
メインの質問は>>97です
その例で言いたいことは、フェードアウト処理が例えば大げさに10秒かかったとします
そしたらその間にもう画面がローディング画像のフェードアウトをしていて欲しくないものになってる可能性もありますよね
１つの考え方としてはView.fadeOutLoadImage()にキャンセルできる関数を返させて、
それを関数の最後まで保持しておいて呼ぶとか考えられます
実際にそういうことをしているのですが、変数の局所性が悪くなってコードが読みづらくなります
また、その関数の終わりまでしか引き伸ばせません。もう少し先までで良いという時はイベントに登録したり煩雑になってきます。
今は場合によってはキャンセル手段を返させたり、イベントを監視させたり、セッションを確かめさせたり色々やっていますが
いかんせん一貫性がないので、その点も合わせてもっとステキな方法があるのではないかなというための例です
>>109
また自分で思いつきで書いても良いのですが、私だけのコードではないので
将来メンテする人のために少しでも良い方法を知りたい感じもちょっとはあります
サンプルコード位は出せないの
俺の頭では理解できない
後は頼んだ
繋がると言うのは
async function A ( ) { ...... await B( ) ...... }
async function B ( ) { ...... await C( ) ...... }
async function C ( ) { ...... await D( ) ...... }
のときA( )と呼んでからD( )まできた状態です
Dが解決しないとCが進みませんし
Cが進んで終わり解決しないとBが進みませんし
Bが進んで終わり解決しないとAが進まない状態です
問題はここでDから仕切り直してまたB'を呼びたいというときです
感じとしてはAがOSの起動、Bがブラウザの起動、Cがページの起動、Dがその中のプログラムスクリプトだと思ってください
OSはブラウザを起動し、もし終了したら自信も終了するよう計画します
ブラウザはページを起動し、もし終了したら自信も終了するよう計画します
ページはスクリプトを起動し、もし終了したら自信も終了するよう計画します
今したいこととは、DがB'、つまりスクリプトが新しいブラウザウィンドウを立ち上げようとしている状態です
ここで、他と同様にスクリプトがそのブラウザウィンドウの終了を待機したとしましょう
ブラウザウィンドウが無数に増え得てまずそうですよね
それでは、スクリプトがブラウザウィンドウの終了を待機しなかったとしましょう
この場合はスクリプトの処理が終わり、芋づる式にページ、ブラウザと終了します
そこまでは良いのですが、それに続けてOSも終了してしまうことになり、これは問題です
なので今取っている対策としては、Bにタスクを登録できるようにするということで、
つまりブラウザをタブ化して１つのインスタンスとし、全てのタブが閉じるまではブラウザが終了しないようにしています
それで上手く言ってるのですが、このような工夫をしないといけない箇所が段々増えてきており
危機感を感じているという次第です
お前は自分が賢いと思ってるつもりの馬鹿だよ
基礎を何もわかっちゃいねぁ
>>106を読んで理解できてないだろ？
function process() {
A();
B();
C();
D();
B();
C();
D();
}
このコードでな、Aの中のコードの生存期間は、
Aが呼ばれた時に始まり、Aが終了すると消えるんだよ
B〜Dも同じ。お前のように長い生存期間のものなんて一つもない
わかるわけがない。
こいつは、基礎から大幅にずれた理解をしてる。
完全に間違った知識をもとに語っているから
説明全てが的外れ。
そんなのを読んで理解できるわけがないんだよ
>>103
> 具体的な細かな話は気にしなくて結構です
あなたが解決できない原因はこれ。
理屈をすっ飛ばして、結果だけを求めるから理解できない。
ぶっちゃけ、一般的なフレームワークを使ってるという安心感が欲しいだけで理解する気は全くないでしょ？
解決手段は、配列と再帰を組み合わせるだけ
将来どんなコードが来るかわからんのだろ
自分でもそう思ってるけど上司の説得材料が欲しいから
こんなに長文を書いて反論で説得材料持ってきて欲しい、ってところじゃないのかね？
>>97は並列動作じゃなくて、逐次動作じゃないの？
>>110
チェーン って言うもんなんか？
>>97を読む限り、完了をトリガーに次の処理に移っているように読めるけど、彼は並列処理の意味を理解してるのかね…
そもそも、並列処理なら、Promise.allで十分だろうに
ないね
>>120は意味不明
だーかーらー、
こいつは基本自体がわかってないから
用語も間違ってると考えて間違いないよ
だから難しい用語をなくして、
基本の基本の話からしないといけない
その証拠が >>115 にレスがまったくないこと
このレベルの話から自分が抱える問題につなげることができない
関係のある話だってわかってないから
関数の生存期間の話をしてるのだから
並列処理は全く関係ない話なんだよ。
ようはローカル変数がわかってないレベル
asyncとかpromiseの関係ない話をすると疲れるだけだぞ。
関係ないことを教えるだけで問題解決せずに終わるからな
問題は、今回の処理は非同期で繋がっているので、
つまり、そのように並べた状態ではなく入れ子状態になっているということです
お伝い忘れてすみませんが、A->B->C->Dという関係は対等な処理を分けたものではなく
親子関係というか、包括関係と言ったらいいのですかね？とにかくそのようなものになっているのです
例えばDがメニューバーの表示とすると、
B'を再び呼び出す必要があるかどうかはDの動作にユーザーがどう反応をしたかどうかであり
勿論違う処理のケースも有るのでその結果をCで待ちわびなければなりません
実際はもう少し複雑ですが、簡単に書きますと>>114のような関係になっているということです
要するにDは下っ端も下っ端だけど、その特質上特権的な状態変化を起こす可能性があるものということなのです
>>117
私はここ何年かちょくちょくこの非同期の問題をどういう形で解決したら良いかを考えたこともあります
なので皆さんの中でよく考えて持論だったりそういうセンスを習得した人が居るのではないかと思いました
私が聞きたいのはそういう感覚であり、まさか具体的なコードに対する回答が貰えるとは思っておらず、
>>97や>>100で挙げたようなパターンに対して、ビビッとそういうときはこうするもんだという
決めつけたような適当な経験の言葉をいくらか頂けたら刺激として私に取り込もうと思ったところです
なので皆さん、適当でいいので言葉をください
例えば>>115さんは大変参考になりました
関数を小さく分割して入れ子になりがちだけど、もっと整理して単純なものに持っていけるのならそうしようと思います
最後の頑張りのための気持ちを高めるためと、問題提起というわけでもないですが、
非同期処理の様々な難しさに対して皆さんがどう思考してるのかを聞きせてほしいということであります
>>123
チェーンというときはだいたいPromiseチェーンを意識しています
>>120,121,124
沢山のことを、直接的に掛けない部分もあり、事実と例えの質問を交ぜて書いた事もあって混乱させてしまいすみません
AからDまでは平行処理ではありません。沢山の非同期関数が同期的に枝分かれ状に呼び出されているルートの内の１つを選びだしたと考えてください。
実際のコードでは平行、並列の部分もありますが、ひとまずそうお考えください
質問A）
皆さんは非同期処理が複雑になってきたらどのような対処を考えますか？
例1) コンテキストが変わると無効になるセッションをほぼ全ての関数に渡して置いて逐一セッション切れを調べるようにする
例2) キャンセルの値や手段を定義してそれを伝播させる（Cancellable Promise）
例3) その合わせ技のようなもの（CancelToken）
その他)
質問B）
>>114の状態で>>97の問題に直面したとき、
要するにいままで繋がってきた流れの中で突然安全にリセットしたくなったときはどうすればいいのか
例1) >>114で言ったように、ブラウザがほぼいつでも安全にタブを閉じれるように、
つながりの根本の方に枝を生やしたり切り落とせるポイントを用意しておく
例2) チェーンにを触れるPromiseをメモリリークを起こさないよう必死に再実装して明示的に切り離すようにする
例3) 生Promise+awaitに頼らない新設計を考える
その他)
質問C)
イベントを使うと不特定多数の直接知らない待機状態の処理を動かせて便利だが、
非同期処理のためタイミングが問題になる場合はどのような工夫をすればいいか
つまり、一方的にイベントを発火するだけではなく、それを全員がきちんと受け取って把握し
必要なら一定の準備ができたというフィードバックを得られるようなイベントシステムをきちんと整備するべきか、
それとも質問Aに書いたようなセッションだったり、今の共有状態変数を準備して対処するか
皆さんはどちらで組まれてるコードがお好きか
また他の場合でも一般に、問題解決のために高度に抽象化仕切ったシステムを作り上げたものと
例えばグローバル変数を１つ使うなどしてでも比較的シンプルに乗り切ったもの
場合によってそれらのスタンスを使い分け混合した状態
皆さんはどのスタンスで組まれてるコードがお好きか
結局、突き詰めると把握できない把握しきれない何かが問題なら
どんな状況でもコード生産速度を優先した途端に必然的に不具合が生まれる
規約が守られているか設計思想に合っているか
確認させる土壌を作るほうがマシ
> 問題は、今回の処理は非同期で繋がっているので、
> つまり、そのように並べた状態ではなく入れ子状態になっているということです
なりません。
少なくともメモリ使用量に限っては関係ありません
promiseやasyncではこうなりません
function process() {
A(function() {
B(function() {
C(function() {
D(function() {
B(function() {
C(function() {
D(function() {
// do something
});
});
});
});
});
});
});
}
これ非同期あんま関係ない
> 皆さんは非同期処理が複雑になってきたらどのような対処を考えますか？
非同期処理も、非同期処理じゃない場合も同じ。
処理を単純化して、その組わせで作る
> 例1) コンテキストが変わると無効になるセッションをほぼ全ての関数に渡して置いて逐一セッション切れを調べるようにする
> 例2) キャンセルの値や手段を定義してそれを伝播させる（Cancellable Promise）
> 例3) その合わせ技のようなもの（CancelToken）
これらは非同期処理が複雑になったときの対処法ではない。
非同期処理かそうかは関係なく、処理の途中で
キャンセルしたい場合に実装すべきこと
1のセッション切れは意味不明。独自用語使うな。
何がしたいのか全く不明
長々説明してくれるのは良いけど独自用語が混ざって訳分からん
確かにそうでしょうが、その規約だの設計思想だのも私に委ねられてる状態でして
結局の所、コードが動かないから、不具合が生じているから質問しているわけではありません
ただ少しでも良いコードを残したい、書いていきたいと思った次第で、
私はJSの「良い」コードというのはその時その時代の世界のJSerがどう考えているかで決まると長年思っているのですが
async関数やPromiseが入って２，３年がたった今どのような「良さ」を皆さんがそこに考え出してるのか
その感覚の言葉のシャワーを浴びて私の感覚を少しでも正しい方向に矯正したいというのが正直な気持ちです
>>133,134
言葉に認識の違いがあるのかもしれませんが要するに>>114の形だとお考えください
>>137
確かにおっしゃる通りです 同期と読み替えてくださって構いません
結局私は自分の中でも問題をまとめきれて居なかった上、色々書きすぎて本質を見失っていたようです
大変申し訳ございません
実際のところ、私がこれまで書いてきた問題（>>111など）は全て繋がっていて切り離せないものだったようです
結局私は、非同期『管理システム』、そのパターンを求めているのです
ユーザーの操作などによるイベントによる別の処理が途中と言って良いようなところで発生し得ることでしょうか
私は>>114でBで複数のCを待ちわびることで解決したと言いましたが、本当はそれだけではないのです
Cに相当する処理は実際は複数の非同期関数が繋がっているということもありますし、
その中ではawait Promise.race([D(),timeout(42),listen('buttonclick')])のようなものも使っています
ユーザー操作やタイマーや、他所から来たイベント次第でいつどう処理が完了するかは分かりません
要するに、シンプルに考えればDがBにnewC'を登録し、Dが終了すればoldCが開放されるように見えますが
実際はDが終了した段階でCはもうDを待ってはおらず、別の処理を始めているかもしれないです
Dはメニューと例えていたので変かもしれませんので言い換えると、
実際はC5が終了した段階でC4はもうC5を待ってはおらず、別の処理を始めているかもしれない、ということです
なので独自用語でセッションと言いましたが、関数開始時などに渡され、その関数が担当する処理が
未だ有効かどうか分かるオブジェクト用意し、コンテキストが変わるときにそのオブジェクトを無効状態にしておくことで、
そのような「タイミングのズレ」にだいたい対処しています
つまり、私は今基本的に素のasync-awaitを使いながら、時にはイベントを使ったり、セッションを使ったり、
Bのような部分的にタスク管理したり、色々しすぎているので
これを大きくまとめた比較的大規模なタスク管理システムを導入して整理し直すか、
もしくはそこまで行かないが10必要だったその場しのぎ対処が5になるような
比較的ちょっとした共通追加対応策についてのヒントや方向性のアドバイスが知りたいと言うことです
すみませんでした。
あぁ、わかった
お前に言えることは「余計なことすんな」だ
問題がわかってないお前が決めた所で失敗するだけ
問題が発覚した時に、後から方向転換できるようにしていればいい。
問題が起きたときに、最初に決めたルールは絶対守れと押し付けるはやめろ
そんなものはこの世に存在しない
大規模 = 悪 だから覚えておいたほうが良い
つまりお前の発想は間違いに突き進んでる
私はこれまでこのプロフェクトを2度白紙にして本当に0から作り直したのですが
この調子で行くと完成と同時くらいに3度目の限界点が来るんじゃないかなと
次の人が必要なら好きに作り直しゃ良いですっかね？
ただ、「あるはずだ」で質問を延々続行するのはどうかと
反省してないからそうなる
先に問題点を洗い出せ
問題点がわかってなくて反省できるわけ無いだろ
この調子で行くと3度目じゃ終わらないだろうな
反省しないお前のやり方じゃ何度も同じことを繰り返す
要するにお前の能力不足だ
不足してるのはリーダーや管理者的な能力だよ
どんな要件変更にも耐える設計作るのと永久機関作るのとどっちが現実的
それは十二分に承知してる
俺じゃなかったら1回目で済んでる
なんで経験浅い俺に任されたんだ
正直問題点は行の数だけある
流石に3回目なのでなんで動いてるのか分からんようにはなってはいない
でもそれが俺の限界
この先最後の最後に細かなバグに苦しめられることは必死
多分修正しきれる可能性のほうが低いだろう
もう疲れたよ
すみません
質問閉めます
と言っても多分参考になった
頑張る
1回目、2回目は成果物完成間近に根本的問題が避けられないことが分かったが
コードが密結合過ぎて要件大変更に耐えられそうになかった
だから3回目は俺もかなり加わって極力個々を小さく、素に作った
要件変更には強い
だが小さなバラバラに動く歯車を管理するのに限界がきそう
根本的問題って何？3回目スタートのトリガーは何？
>1行目「1回目、2回目は（略）根本的問題が避けられないことが分かった」
ほうほうなるほど1回目2回目は明確な問題があったんだな
その書きぶりだと要件変更のせいで作り直しとかじゃなかったんだな
>2行目「分かったがコードが密結合過ぎて要件大変更に耐えられそうになかった」
は？問題があったから作り直したんちゃうの？
要件大変更は生じたの？それとも未来くるかどうかわからない大変更に備えての作り直し？
無駄な情報を追加してる一方で、必要な情報が不足し整合性がない
日本語でこれ
一応なんとか形になったものの解消できないバグが残った
しかも将来の仕様変更に耐えられそうもなかった
バグの対応と将来の仕様変更への不安から設計からやり直すことになった
2回目＞設計だけやった
1回目の失敗から設計をやり直したが、最終的な結果は1回目と同じだった
やはりバグの対応と将来の仕様変更への不安から設計からやり直すことになった
3回目＞設計だけでなくコーディングにも入った
なんとかバグを解消しつつ想定される仕様変更にも一定程度対応できるようになった
しかし部品ごとの独立性を重視して非常にきめ細かく作り込んだため全体像から細部まで把握するのが至難の業になった
なお1回目から3回目まで通じて仕様変更はなかった
妄想推測と過去レスを元に書くとこんなところか?
密結合を嫌って疎結合にし機能ごとの独立性を重視した結果煩雑になったというならば
>>97や>>100末尾の諸問題は各機能のインターフェースや実装のレベルまで落とせそうなものだが
自分は平行処理なんて書いてないから
そもそも、平行処理って何？並行処理のこと？
並行処理と並列処理の違いを理解してるの？
「並列処理じゃなくて逐次処理じゃないの？」と指摘されてるのに、なんでそっちはガン無視なのよ
専門用語を使えば使うほどボロを出してるから、もっと平易な日本語で書きなよ
知ったかしないで、分からないことは分からないと認めなきゃ先に進めないでしょ？
window.open(url) はurlを引数に取りますが
window.open('<html><body>Hello!</body></html>');
みたいにｈｔｍｌを引数にして新規ウィンドウで開く方法ってないでしょうか
ブランクで開いてからhtmlを設定したらいいんじゃね
一応できて動きました。こんな感じですかね？
function new_window() {
var w = window.open("", "NW");
w.document.open();
w.document.write("<html><body>hello</body></html>");
w.document.close();
}
new_window();
バカは黙ってた方が身のためだ
皆、非同期処理のネストの深さに困ったから、
ネストが深くならないように、await が作られた
Selenium WebDriver では、ctrl+T キーを送って、別のタブを開いて、
そのタブに移動する、というサンプルがあった
名前欄に、最初の書き込みの番号を入れてくれ
処理の基本は、all or nothing
A | B | C
というパイプラインがあって、B で失敗した際、A だけが更新されると、
データの不整合が起こり、データの一貫性がなくなる
データベースなどでは、roll back して、Aの更新前に戻す。
中途半端な更新をしたら、絶対にダメ！
もうただのおしゃべりになるのであまり自ら事情をバラしたくないのだが、
その問題のために要件も含めて設計を大胆に見直す必要が出たってこと
/*このあと15行ほど書いたが削除した。察して欲しい。*/
>>155
勿論十二分に理解して書いてるよ
だって書く前にググったもの しっかりとね
2chに書いてるんだからそれくらいのことは当然してる
バカにしないで
>>その他のレスの人
アドバイスや意見をどうもありがとう
その問題を自分で理解してないんでしょ？
バカは黙ってた方が身のためだ
書く前にググらなきゃいけない時点でバカにされても仕方ない
1、2回目を限界が来たと書いていたけど
要件定義不備設計不備に由来する不具合が原因の作り直しじゃん
その問題というのは誰が見てもハッキリ分かるもの
度合い問題でもあるが
何を何に変えてそこから何に変えて良くしたか
３段階で解決できるものと言ったら
>>170
たしかになぁ
でも何とも言えんわ
正直言えば１回目で完成ですでも良かったわけだし
仕様はこうです、合わせてくださいってこちらから言える案件だし
つうか目的くらいしか決められてないしどういう機能があるべきかそれほど自明でもないし
そのくせ追加要望は未だにしょっちゅうしてくるし
ここまで聞いて分かったと思うけど、直接目的を達成するものだけを作ってるわけじゃないし
>>171
セッションは本来の呼び名を避けて適当に言ったんだよ！
ググってなくてすまんかったな！
よかったら良い呼び名を教えてくれ
次からそれを使う
何に困ってるか説明できてないので答えようがない
まあ全てはこいつの能力不足だ
お前が教えるんじゃなくてお前が教えてもらうほうだ
同僚の苦労が偲ばれる
実装手法なら、周辺環境や規約にもよるけど、だいたいこのように書くと言えることもある
でも設計だと一部を抜き出して語る意味がない
全体を知っている者同士の会話でもなければ良し悪しの判断基準がないから語りようがない
毎回個別に考えて調べて考えるのが原則
だから設計は単価が高くて人工が多い
元質問者も多少おさまりつかないとこあるかもしれんけど
もうやめといたらどうか
何かあったんですか？
・・・
}else{
・・・
}
みたいな文を書くとエラーが出るのだが、ダメなのか？
＞みたいな文
というのがよくわからないので
if(true){ console.log(1) }else{ console.log(2) }
これ試してみて
()内の条件が定数だと警告が出ていたようです。
相談するってさっぱり意味が分からんな
解決してほしいんじゃなくて話を聞いてほしいだけ
車が故障したと電話する女、クソまじめに解決のため診断方法をレクチャーしようとしちゃう男、みたいな
車クラスを作ろう！とかそういう練習問題的なのは無しとして
オレには作れん(´･ω･`)
実践的なお題がないかと思いまして
動物クラスを継承して犬クラスを吠えさせる、みたいなのでは実際にはどういうシーンで役立つのかイメージがつかないのですが…
classを使っててclassでないと困る実例を聞けばいいと思うんだけど
なんでjavascriptのクラスを駆使して何か作ってみたいの？
+ JavaScript のお題用スレッド +
https://mevius.2ch.sc/test/read.cgi/hp/1526666703/
クラス、クラス言いたいだけかよ
と言うような記述を見たのだが、
ifは何のためにあるの？
何が目的なの？
それ悪い書き方
MyFuncに関数が入っていない場合（＝バグ）
バグの場合にバグを無視するというコードになってる
良し悪しはともかく目的がなにかと想像すると
MyFuncは別のとこで代入されてるとか
代入されるまではundefinedなりnullなり
目的は呼べないものを呼ばないようにすることじゃなくて
呼べるものを呼ばなくすることだな
例えばNodeとかでV8に手を入れてtypeofを拡張してるとか
それで例えば呼ぶとエラーになるクラスのコンストラクタは'constructor'を返すようにしてるとか
一度しか呼ぶことを期待していない関数が呼ばれた後は'function'じゃなくすとか
十分に考えられる
関数名は自己顕示欲の塊だな
IE11用にPromiseのPolyfill作成
>>194の事例なら、onclickを付け外しする方が圧倒的にスマート
が一番スマート
そこはaddEventListenerじゃないのか
function* g(){
const n=yield 0;
yield n;
}
var f=g();
console.log(f.next());
console.log(f.next(3));
nextで直前のyield部の変数に値を渡せる、みたいな機能がありますが
これをうまく利用した例などはありますでしょうか
ぱっと見どこに値を渡したのか？という見辛さに違和感があるのと
実行直前の値を変えたい、という状況が思いつきません
＜script src="file1.js"＞＜/script＞
＜script src="file2.js"＞＜/script＞
＜script src="file3.js"＞＜/script＞
では正常に動作するんだけれど、三つのファイルを単純に連結して一つにして、
＜script src="fileAll.js"＞＜/script＞
とするとエラーが出まくるんだが、一般に、このやり方はエラー出るの？
単純に連結しているから、三つに分離している場合と同じだと思うのだが。
ファイルの冒頭に、; を入れておけば？
A エラー内容確認してがんばって直せ
チンコ晒せといってるじゃないんだから。
Githubとかあんなところもその恥ずかしいという気持ちを乗り越えてからすべてが始まるんだぞ
その理屈だと、エスパーも恥ずかしくてコードを晒せない
(::::::::::::::::::::::::::::）
(::::::::::::::::::::::::::::::::::）
（:;;;::::::::::::::::::::::::::::::::::::）
（:;;;;;:::::::::::::::::::::::::::::::::::::）
（;:::::::::::::::::人:::::::::::::::::ﾉ
（::::::: (´・ω・｀):::::ノ
jqueryの方はreturnで配列返したら配列じゃなく展開されて値が代入されてました
なので配列で返したいときは
$().map(_=>[[]])
みたいに入れ子にしないといけない、でよいでしょうか？
なんか根本的に間違ってるぞ。
jQueryのmapは二種類ある。
$.map と $().map だ。
前者は、（jQueryが開発された当時、存在しなかった）
JavaScriptのmap相当の機能を提供するものとして作られた。
後者はjQueryオブジェクト（＝要素の配列をラップしたもの）に対して
mapを実行するもの・・・が基本ではあるんだが、jQueryオブジェクトというのは
いうのはDOMだけではなく任意のオブジェクトをラップすることが可能なので
いろんなものに使えたりはする。
で、JavaScriptのmapとして使いたいなら、$.mapの方を使う。これは配列が
mapメソッドの引数になっているという違いはあるがJavaScriptのmapと同じように使え、
真の配列だけではなくlengthプロパティがある配列っぽい（Array-like な）ものを
扱えるという便利さもある。
> みたいに入れ子にしないといけない、でよいでしょうか？
入れ子にしないといけないとかいうのは意味がわからん。
後者を変な使い方をしてるだけだろう。
あんたが欲しいものは前者だ。それ使っておけば悩むことなど無いはずだ。
実際に試してみるとわかる
var arr=[1,2,3];
console.log( $.map(arr,_=>[1,2,3]) ); //[1, 2, 3, 1, 2, 3, 1, 2, 3]
console.log( arr.map(_=>[1,2,3]) ); //[Array(3), Array(3), Array(3)]
console.log( $.map(arr,_=>[[1,2,3]]) ); //[Array(3), Array(3), Array(3)]
ということではないかと
マジかｗ それはしらなかった。
jQueryのmapってRubyでいうflat_mapだったんだ。
ってことはmapといいながら1対1での変換じゃなくて
要素を増やしたり減らしたりもできるってことか。
なんでjQueryのmapはdeprecatedにならないのかと
思っていたらそういうことだったんだな
jQuery には、2種類のメソッドがある
$.メソッド名は、汎用的なユーティリティ関数で、
$().メソッド名は、this を持つ、インスタンスメソッド
付き合ってあげるここの人たち優しい
var tNumber = [];
var i = 0;
var o = document.getElementsByTagName("a")[25];
for( i=6;i <=24;i++ ){
tName.push(document.getElementsByTagName("a")[i]);
tNumber.push(document.getElementsByTagName("a")[i-1]);
if(tName[i].textContent.includes("(1001)") == true){
tName[i].style.display = "none";
tNumber[i-1].style.display = "none";
}
}
if( o.textContent.includes('(1001)') == true ){
o.style.display = "none";
}
これ実行するとTypeError: tName[i] is undefinedって出るんですが原因わかる方いますか？
実行順序の関係だろうか.
ループ最初のi==6の時はtName[0]しかないぞ
エラー出た時にブラウザでオブジェクトの中身覗いたら原因丸わかりじゃないですか？
いつもどういうデバッグしてるんですか
ブラウザのコンソールはエラーと警告が出るだけの場所だと思い込んでてまさかコード打ち込んでデバッグ出来るとは青天の霹靂だ
>>241
tNameは最初の一個しかないのが意味が分かりません
ほぼ同じソースコードだけど別のページだと動くのに.
ゴリ押ししたら動くのにforとarray使ったら動かなくなるのなんでなん
いつの時代の人？
多分江戸時代とか…滝汗
i と tName をconsole.log()にかけるコード1行入れりゃ理解できるんでね
var tName = [];
var i=0;
//i=0からi=5は、何もしていない
console.log(tName); // []
i=6
tName.push('要素a');
console.log(tName); // ['要素a']
console.log(tName[i]);// undefined == tName[6]
i=7
tName.push('要素a');
console.log(tName); // ['要素a','要素a']
console.log(tName[i]); // undefined == tName[7]
//以下繰り返し
とりあえずこれで事なきを得ました。ありがとうございました。
var tName = [];
var tNumber = [];
var i = 0;
var o = document.getElementsByTagName("a")[25];
for (i = 6; i <= 24; i++) {
tName[i] = document.getElementsByTagName("a")[i];
tNumber[i-1] = document.getElementsByTagName("a")[i - 1]
if (tName[i].textContent.includes("(1001)") == true) {
tName[i].style.display = "none";
tNumber[i - 1].style.display = "none";
}
}
if (o.textContent.includes('(1001)') == true) {
o.style.display = "none";
}