+ JavaScript の質問用スレッド vol.130 + [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-6のテンプレを読んだ上で質問してください。次スレは>>950が>>2のテンプレ案(本スレで改善案があれば考慮)を元に立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」だけでなく「意見」を出しても良い。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
・回答者同士のレスは原則禁止(>>6を参照)
・ライブラリの話題の投稿(>>6を参照)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/ ■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プロパティの算出値を表示("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 型の中身をそのまま表示してくれます。) ■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 和訳) クロスブラウザ問題も切り捨て時期に入りversion1の使う理由がなくる。
https://w3techs.com/technologies/history_overview/javascript_library/all
ここをみると今年に入ってからjQueryを使用している会社は0.4%増えているようだが
少数派の意見ではあるがうちの会社では年内でjQueryをきることが決まったぞ。
こういう会社もまれにあるってことを知ってほしい 例外的な会社の話をするならば、
そりゃjQueryを切るところもあるだろうけど、
ぶっちゃけ、少ない方の事例じゃね？ そもそもAjaxのころのライブラリ黎明期からHTML5ムーブメントまでの成長期なら分かるが
現代に主要ライブラリのリンクとか必要なのだろうか？
つうか全体的にリンクがあまりに多すぎじゃね
例えば仕様のリンクは多くてもスナップショットの和訳１つで良いだろう
最新の英語のLS版が知りたいやつがここのリンク参考にするとは思えんし
もっと言えばMDNだけで十分な気がする
MDNの各ページには仕様への適切なリンクが張ってあるし、
興味がある人ならそこから知るだろう
質問テンプレートもテンプレートなんて殆ど使われないし、
こういう質問の仕方にしてという注意事項形式に改めたり、
改善と言うか０からテンプレ作り直す必要があると思う スレチかもだけど
iOSでHTML、CSS、JavaScriptの編集、デバッグ(ここ重要)出来るアプリでお勧めあったら教えて
長文でも見やすくて、欲を言えばライブラリの追加とか出来ると素敵です
JSAnyWhereは試したけど、使い物にならなかった
もっと適切なスレあったら、誘導願います ここまで過疎ってる上にスレ分裂してるのにさらにテンプレ議論を別スレでさそうとは恐れいった 好き勝手にやればいい
まともな質問がきて答えたければ答える
それ以外はゴミどもがくだらん喧嘩しててもスルーしときゃいい >>15
↓無能はこいつ
>>1-7
スレチは微妙でグレーところか 無能っていうか意図的にやってるんだよ
元のテンプレで注意されていた荒らし本人がずっとそうやってスレ立ててんの 問題だー問題だーって騒ぐ割に
誰も具体的に指摘せず不備を直そうともしない いやｗちっとも改善する意識の無いやつがスレを立てるなよ
ただでさえ乱立してる中立てるってことは
相当の意味を込めてないとおかしい JavaScriptが最終的に覇権握るわ。こんな応用きいて自由な言語ねえ var t = obj.typo;
こういうバグを発見できないJSは糞言語 慣れればすぐ分かる
どうしても気になるなら存在しないときエラーを出すProxyで包んだりすればいいじゃないか 効率は悪いがメモ帳みたいな最低限の環境でもできなくはないし、
1発とはなかなか行かないが問題なく動くものも作れるけど、
存在しないあるいは未参照だったりするオブジェクト・変数・メソッドをチェックしてくれるぐらいの環境は用意したほうがいいんじゃね。
そこまで本格的でなくても、typo程度ならシンタックスチェック入れるだけでもだいぶ変わるはず。 typoは確かに良くするが大抵すぐ分かるけどな
コンパイルしてデバッグ実行のオーバーヘッド考えたらさほど大したことじゃないと思う
それよりも近年たまにハマるのがイテレータ周りだな
例えばPromise.all([a,b,c])としないといけないところをall(a,b,c)としてしまうと
undefined is not a functionエラーが出てしまう
これがall(a,b,c)ならまだ原因に気づきやすいんだろうが、
async関数の絡みでよくall(a(),b(),c())となってることも多いので惑わされる ブックマークレット作成してて、画面項目入力後にボタンクリックして次の画面に遷移。遷移先でも入力させたいんですが、描画完了直後に入力したい場合どうすればいいでしょうか？ Proxyを無理やり使って実行時に判明する程度だからな・・
静的にobjのプロパティ参照typoを見つけられるチェッカーは無いし >静的にobjのプロパティ参照typoを見つけられるチェッカーは無い
ないの？知らんけど
探せば普通にありそうだけどな 変数とは勝手が違うから難しそう
多分Object.prototype.__proto__にProxyを挟むというのが良いかもね typoが気になるならTypeScriptおすすめ。
基本的は
let a:型 = ほげほげ
みたいに型を:の後に追加するって仕様だけで使える。
後、個人的に気に入ってるのはjsonにスキーマ設定できる
interface User {
name: string
age: number
}
user:User = {
name: 12 // error!
// ageが足りない!
}
って感じでエラーを出してくださる。
jsonにスキーマがつくとすごく便利よ〜。 https://www.typescriptlang.org/play/
上記とかtypscriptがどんな感じかわかるから触ってみて
シンプルな見た目のくせに補完が効くしね。
試しにdom操作してみると感動するで
document.createElement とか使ってみて欲しい
document.createElement("button”)を実行するとちゃんとHTMLButtonElement型が代入されてるしそもそもdocumentって入力しただけで
候補が出るからtypoしようもないよね。 確かに素晴らしいんだけど
大規模コード書くようなTSが有用なときって
あんまりそう言う重し付けたくないんだよね
何が嫌かって言ったらリリースデータに元とコンパイル後の２つ含めることになること
ポリフィルみたいに簡単に要らなくなったら外すとかできないし >>34
最悪tsを捨てちゃったっていいのよ。
生成されるファイルはtargetをes2015にして出せばそんなにはキチガイなコードにはならないからjsとの混在も可能だしね。
ちょっと前は型定義ファイル周りのエコシステムが乱立？して混乱を呼んだけど
今は平和だしいい感じよ。
俺はむしろtypescriptからjsに本格入門した。
vscodeで書いてるというのもあるけど、書いてる最中にバグを指摘してくれるから
気分的にはコンパイラとペアプログラミングしてる感じ。
いちいちドキュメントを見に行かなくてもvscodeが必須パラメータを教えてくれる。
感覚的には文字入力してる時に頭の悪いIMEから頭のいいIMEに代わって
凄く捗るぜーって感じかな。 >>30
無いぞ
>>31
判明が静的と実行時では雲泥の差 >let a:型 = ほげほげ
>みたいに型を:の後に追加するって仕様だけで使える。
インタプリタに慣れすぎて型指定するのめんどくさいお >>37
型推論使えるから基本関数とかメソッドのインターフェース定義のときしか要らないよ。 >>22
これ
能力無い奴が余計なことして後手後手になる典型的なﾊﾟﾀｰﾝなんだよな 自己流で覚えたので、おかしなやり方をしてる気がしてるのですが、どうもstring.match(/hoge/)が使いにくいのです
正規表現マッチだとオブジェクトで帰ってくるので
var temp = string.match(/.*hoge/).replace("honya","hage") ← stringじゃないのでエラー
var temp = string.match(/.*hoge/)[0].replace("honya","hage") ← マッチしなかった場合0なんてプロパティはありませんとエラー
となり良く止まってしまいます
これを判別して
var temp = string.match(/.*hoge/)
if(temp != undefined){
var temp2 = temp[0]
} else {
temp2 = ""
}
temp = temp2.replace("honya","hage")
と書くと、ただストリングがひとつ欲しいだけなのにいちいち長くなってしまいます
そこで
var temp = (string.match(/.*hoge/) || ["","",""])[0].replace("honya","hage")
最終的にこんな書き方になりましたが、見づらいし、こんな泥臭いというか力業が一般的な書き方とは思えず悩んでいます
そこで皆さんがどうやってるか・一般的にはどうやるのか、どうかアドバイスください var temp = string.match(/.*hoge/), temp2 = temp && temp[0].replace("honya","hage");
var temp = string.match(/.*hoge/).map( m => m.replace("honya","hage") ) [0];
ある程度はどうしようもない 愚直にやるのが一番いいと思うけど。
ワンライナーにしなきゃいけない理由がわからない
三ヶ月後の自分が分かるコードで書くべき >>41
&&をこんな感じに使えるんですね、なるほど参考になります
ありがとうございます
>>43
長いと目が迷子になってしまうので、特にmatchはよく使うので
一般的な感覚じゃないかもですが、行数の割に得られるものが少ないと、このブロック何の為だ、と後々読んだ時に混乱してしまって
でもif文で数行に書くのが一般的なのですね、なるほどありがとうございます string.match(/(.*hoge)/)
temp = RegExp.$1.replace("honya","hage") >>46
これRegExp.$1に何も入ってなくてもエラー吐かないんですね
こんな裏技あったとは、RegExpって気になってたので意識して使ってみます、ありがとうございます 条件が複雑なら、コードも複雑になるのが、当たり前。
そのまま素直にコードにすればよい
条件が複雑なのに、コードが単純になっていれば、間違っている。
コードを単純に出来るなら、条件も単純に出来るはず
2段階のプロセス。
1. 論理的に正しい証明を先にしてから(仕様書)、
2. その通りにコードに写す(実装)
2を修正したら、常に1に帰ってから、正しさを証明して、2を修正する。
常に、考える時は、1の仕様書で考える
&& を使ったら、if-else よりも、分かりにくい。
頭の中で、if-else に置き換えて、
論理的に矛盾が無いか、証明しないといけないから、余計に難しい。
つまり、見落とし・勘違い・バグが起こる、可能性が高くなる
もし、&& の右の式に、副作用があって、何かの状態を変える場合、
パッと見て、右式が実行されたか、されていないか、分かりにくい。
頭の中で、間違いが無いか、確かめるのが大変
論理的に正しいと証明するのが、一番難しい。
コードを書くよりも難しい ECMAでRegExp.$1などを無くそうかという議論がされてるときに
堂々と提案できるやつはどういう神経してるんだろう なくそうか、じゃなくて仕様に拡張として追加しようか、という案と反対意見でしょ
現時点ではただのレガシーな独自実装なんだから、勧めるのは確かに良くないよ やっぱそうだったかｗ
無くすわけないしな
全てのブラウザで使えて昔から
よく使われているものなんだから
仕様に追加するべきだろうな。
昔から広く実装されているからって
レガシーってことにはならんよ よく使われている……？
キチガイじみててめまいがしてくるなｗ HTML5っていうのはそもそも過去のブラウザを含めて各ブラウザで
同じようにレンダリングできるように仕様が固められたもの
仕様があってそれに準拠するようにブラウザを開発するのとは逆。
だからJavaScriptでも同じように動くことを目標としてるので
使われている機能は消さないし、標準化されてないのであれば
標準化する方向にすすむ。 >>54
「JavaScript」の仕様があればそうだし、現にWHATWGにはRegExpの拡張を含む「JavaScript」仕様があった
での削除された、その理由を考えると良い ■ このスレッドは過去ログ倉庫に格納されています
