+ JavaScript の質問用スレッド vol.126 +
レス数が1000を超えています。これ以上書き込みはできません。
JavaScript を自ら学ぶ人のための質問スレッドです。
■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。
前スレ
+ JavaScript の質問用スレッド vol.125 +
https://mevius.5ch.net/test/read.cgi/tech/1518940081/
（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです） そもそもJSにdivをbuttonとして誤認識させた後に何をしたいのかがよくわからないけど、どうしてもHTMLButtonElementにしたいってのが目的ならそういうコンバーターなり何なりを作るしかないんじゃないの >>899
意味不明。初心者が馬鹿やろうとしてるとしか。
JavaScriptも24年の歴史があり、広く使われているのだから、
初心者が思いつくようなところで今更困ることはほぼ無い。
それはやり方を間違えているだけ。
多分CSSについて勉強した方がいい。 この世にIEという存在がなければそんな変なことは考えないのですが、
IEの利用者がまだいてbuttonのクリックイベントと、divのクリックイベントでは
差異があるので、なんとかしようと考えた次第です。
とりあえず「簡単にはできないし、まず無理」という結論であればそれを受け入れます。 >>902
馬鹿乙
IEなんて大昔からあるだろ。
それが本当に必要なら、誰かが既に開発して、それこそjQueryにでも搭載されてるよ。
無い＝要らない、ってことなんだよ。初心者ならやり方を間違ってるだけ。 挙動を統一したいならCanvasでやれ
そういうフレームワークも増えてきてる またcanvasおじさんが湧いた
>>899
ボタン要素でスタイルシートでお好みのデザインに合わせればいいよ カード型みたいにボックスの中に画像、タイトル、アイコン、とかいろんな要素があって
そのカードがボタンの役割をしているならdivでもいいんじゃないの？
むしろbuttonタグの中にdivやらspanやら、iとかいろいろ要素ぶっ込むものなのかね？ >>899
UIだけなら、CSSでボタンライクではないようにも変更できるわけでdiv要素を使う理由はない >>907
Enterキー押下時のclickイベント拾わない話じゃねーかとエスパーしてみる
それは他のブラウザでも同じなので、keydownイベント拾ってEnterキーだけ抽出してclickイベント時と同じ挙動をさせるしかないよね
shift/alt/meta/ctrlキー同時押しはもちろん排除するとしてさ >>909
それだけなら、tabindex属性付与だけで実装可能ではないか？
ボタンの何をエミュレーションしたいのかがわからん、には同意 javascriptでreplaceを用いた特定の文字の置換ができないです。
// サーバーからデータを受信したとき
function onReceive(data) {
let json = JSON.parse(data);
let messages = document.getElementById('chat');
let li = document.createElement('li');
if(json.text == 'おい'){
json.text = 'オイオイオイ'
}
// JSONから必要なデータを取り出して、テキストにする
li.innerHTML = json.count + ":" + "<span style='color:green'><big><b>ななしさん</b></big></span>" + "ID:" + socket.id + "<BR>" + json.text;
// 画面に要素を追加する
messages.appendChild(li);
}
これがソースコードの一部です。
このソースコードで、「おい」と打ったら「オイオイオイ」と返ってくるのですが、
「あいうおいえお」と打ったら「あいうおいえお」と返ってきます。
本当は「あいうオイオイオイえお」と返ってきてほしいです。 if(json.text == 'おい'){
json.text = 'オイオイオイ'
}
上記の部分を
json.text.replace('おい','オイオイオイ')
にしたら何も表示されなくなってしまいました。 >>913
だされた課題は自分でやれ
どうせ本当に出された問題は
「以下のコードをreplaceを使って書き直しましょう」
なんだろ？
答えを聞くな >>914
違います。
課題は課題なんですけど、
課題内容は「リアルタイム通信を使用してアプリケーションを作ろう」です。
課題の一部がどうしてもわからないので聞いています。 replaceってヒントを貰ってるんだから、replaceについて調べればいいだけ >>917
おい、おっさん。
こんな時間に即返信するとかなにやってんの？ニート？ｗ
お前は「答えない」じゃなくて「答えられない」だろｗ
無能のくせにでしゃばるなよｗｗ # 詳しい人、知恵を貸してくれ。
div1 = document.createElement("div")、document.body.appendChild(div1)
として、div1 の style の position を absolute や fixed として、
style.top, style.left に座標を指定しても、以下のような affiliate がある場合、
newBox の margin の 100px と全く同じだけ、div1 の位置が下に下がってしまう。
仕様上は、position:absolute は、親要素であるところの body 要素の左上の点からの
相対位置で指定されるはずなのに、なぜだろう？
自分の理解では、以下の affiliate は、div1 などのもっとも年上の兄弟として
追加されるだけだから、div1 の位置には影響を与えないと思うんだが。
var func = function(){
var parent = document.getElementsByTagName("body")[0];
var newBox = document.createElement("div");
newBox.setAttribute('id', 'vdbanner');
newBox.setAttribute("style","display:block!important;position:relative!important;top:0!important;left:0!important;margin:100px 0 !important;padding:0!important;text-align:center!important;");
newBox.innerHTML = "広告内容";
parent.insertBefore(newBox, parent.firstChild);
}
try {
window.addEventListener("load", func, false);
}
catch(e) {
window.attachEvent("onload", func);
} 長ったらしいので翻訳。まずimportant;は使うな
#vdbanner {
display: block !important;
position: relative !important;
top: 0 !important;
left: 0 !important;
margin: 100px 0 !important;
padding: 0 !important;
text-align: center !important;
}
$(function() {
$("<div/>", {id: 'vdbanner', text: '広告内容'}).prependTo('body');
}); できたぞ、質問に答えられないバカ
var result = json.text
for(var i=0;i<json.text.length;i++){
if(json.text[i] == 'お' && json.text[i+1]=='い'){
var tagetString = json.text;
var reString = /おい/gi; // 複数を置換する時は"g"を、
// 大文字/小文字の区別をしない場合には"i"を指定します。
var repStrung = "オイオイオイ";
result = tagetString.replace(reString, repStrung);
}
}
じゃあな無能 一行で書けるけど、じゃあなって言われたな。じゃあなｗｗｗｗ >>899
ボタン部分だけのクリックじゃなくて、
もう少し範囲を広くして、ボタンを含む、div で、クリックイベントを動作させたいのかね？
ボタン部分だけだと、範囲が狭くて、うまく押せない人がいるから
それと投稿者は、次に投稿する際に、名前欄に最初の投稿のレス番号を入れてくれ >>918
>おい、おっさん。
>こんな時間に即返信するとかなにやってんの？ニート？ｗ
>お前は「答えない」じゃなくて「答えられない」だろｗ
>無能のくせにでしゃばるなよｗｗ
>>911
も、同じID。PNnv4t9U
こいつは、いつもの荒らしだから、皆答えないように！ >>920
web の質問は、こちらの板ではなく、web制作管理板の方へ書き込んでください！ >>921
それ、無料レンタルサーバー Xrea の Affiliate だよ。
結局、body 要素に、position: fixed; top:0px; を付けたら直った。 >>922
var result = json.text.replace('おい', 'オイオイオイ') >>930
それを複数個作るとエラーが出るんです。 >>931
var result = json.text.replace(/おい/g, 'オイオイオイ') ES6で新たに導入された式や文は
ES5.1の構文糖衣と考えて良いの？ >>935
> ECMAScript 2015 で導入された JavaScript クラスは、
> JavaScript にすでにあるプロトタイプベース継承の糖衣構文です。
> クラス構文は、新しいオブジェクト指向継承モデルを JavaScript に導入しているわけではありません。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Classes クラス構文だと関数で呼べないから違うものを導入してるよね 糖衣構文かどうかにこだわるのってなんでだろう？
マウント取りたいだけな気がする >>936
よく読め
それはモデルとして、つまり抽象度の高い概念としての話であって
実際にES5で書き換えられるわけではない なんかそもそも糖衣構文という言葉をわかってないやつがいるみたいだ
糖衣構文の条件
× ECMAScript 2015で書いたのと同等のことを、ES5で（複雑に）書けること
○ ES5で書いたのと同等のことを、ECMAScript 2015で（シンプルに）書けること
>>939
お前変換の向きが逆 それは絶対に違うね
新しい構文というのは問題を新しく解決する為に入れられるわけで
古いコードで書いてたコードがシンプルに書けるようになるものでない方が珍しい
そんな事を語っても仕方がない
古いコードで再現できるかどうかの方が意味がある また意味不明な
新しい構文の中で従来では複雑な書き方だったものを
シンプルに書けるようにしたものを特別に糖衣構文とよぶんだろ
誰が新しい構文はすべて糖衣構文って言ったんだ？
誰も言ってないだろ シンタックスシュガーがあるならシンタックスヌガーとかシンタックスハニーがあってもおかしくないよね >>942
度合いの問題だ
「ほぼシンプルに書けるようにすることが目的で導入されたもの」を糖衣構文と呼ぶのは分かる
ほかの要素を無視できるという意味での「ほぼ」だ
そうするとそのほぼというのは例えば感覚で8割〜９割としよう
しかしClass構文でのその目的、重要度はせいぜい６〜７割だということを言ってる
Class構文は従来__proto__を使わないとできなかったスタティックとプロトタイプメソッド両方の継承ということができる
これが俺にとって重要度・構文価値の〜1/10
さらにnewTargetの存在によりビルトインクラスの継承ができるようになった
これが俺にとって重要度・構文価値の〜3/10
少なくともこういう要素はClass構文を語る上で無視できる存在ではないだろう？
そうすると一般にClass構文は糖衣構文ということはできないというのが俺の主張だ
なのでそう言いたいのならコンテキストを絞った上で言わなければいけない
今回の場合も、もし「ES6で新たに導入された式や文は ES5.1の構文糖衣と考えて良い」と答えると
そういうClass構文などの無視できない重要なポイントを気にしていない、
下手すると気にしなくていいという発言になってしまうだろう？
君はそこを取るに足らないポイントだと考えるから、そう言えるんだろうが、
俺は>>933にそこももっと知っておいてほしい、説明したいと思うんだよ
そういう違いさ >>945
長ったらしくて読む気がしないが
要するにお前が言いたいのは、
class = 糖衣構文＋α って言いたいだけやろ？ そして＋αの部分がclassでしか使えないのかといえばそうではなく
classを使わなくても、+αの機能は使えるから
やっぱりclassは糖衣構文 >>947
Class構文のES5で代替不可能な機能はES6の他のより基本的な機能で代替可能だから、
ES6も入れたら糖衣構文と言ってもいいよ
でも今回はそうじゃないから
ES6の機能が、従来のES5の機能の糖衣構文と言えるかという話だから
その辺り俺は言葉に慎重だが、君は適当
そういう違いさ 糖衣構文の反対はキムチ構文って呼ぶってことで
この話題終わりにしませんか？ >>949
それでも良いよ
俺はどういう機能か説明したい気ならあるが
くだらない言い争いはもう沢山だから >>948
もしかして
ES5で今までやっていたことをclass構文で簡潔に書けるようになっても、
ES6で追加された機能をES5で実現できなければ糖衣構文ではないって言ってる？
意味不明なんだけど >>934で
> 「ES5.1の構文糖衣」という表現がおかしい
とせっかく俺が言ったのに
>>935がclassのことを持ち出すから
おかしくなったって自覚してるのかな？
classは糖衣構文だが、そもそも最初にES6の機能がとかいう言い方はおかしいって指摘した。
マッチポンプかよ。自分がclass限定の話にしておいてclass限定の話はしてないって 話変わるけどジェネレーターは糖衣構文じゃないよねさすがに。 >>953,954
意味不明なのはあんただ
俺は0.999だからNoとか0.001だからYesとか言うのは嫌いだし
そういう0か1かで糖衣構文「であるのかどうか」を話す気はない
たとえちょっと変な表現であろうと、今回の話の流れの上で糖衣構文「と呼んだほうが良いか」を
アナログ的に考えて、俺なりの想いを持って方が良い、悪いと話している
また俺はClass限定の話を始めたわけではない
わかりやすい一例としてまずClassでの事実を１つ挙げただけ
そこから質問者が食いつけばClass構文が入ることによる新たな可能性を話すつもりだったのに
変におかしな流れに誘導したのは君の方だよ
少なくとも俺は>>933を俺なりに解釈して話を始めた
そこで君が横から言葉の使い方がどうのこうのヤンヤン言って来ても知らんがなって感じ
君の脳内パーサではエラーが出たんだろうが、それをエラーですエラーですエラーですよって、うるさい目覚まし時計かって感じ
俺のゆるゆるパーサでは通ったんだから俺は話を進める、君は固まっとく、でいいじゃないか
俺までどうにかして止めようとする必要はない、俺はそういうのは嫌いだね
JSでも値をチェックして例外を吐くとかね
値をできるだけ加工したり用意の仕方を工夫して無効な値を極力作らないようにする方が俺は好きだ
ともかく君の定義ではそもそも話がおかしいのはおっしゃる通り
だからこそ俺はその定義は今回はそぐわないとしてるところに、わざわざその破綻する定義を持ってきて
ギーギーガーガーおかしいおかしい言われても しつこいポンコツ機械かよって感じ
まあそんな感じ >>956
俺はclass = 糖衣構文＋αなんだから糖衣構文だって言ってるのに、
お前が、完璧じゃないから糖衣構文と言ってはいけないと言ってるんだろ
1じゃなければ0と言ってるのはお前だ 糖衣構文＋αじゃなくて、完璧に糖衣構文でしょ
糖衣構文＋αだったら糖衣構文とは言わないよ 糖衣構文か否かの議論の果てにどんな結論があるんだろ var flagA = false && true || true;
変数flagAがtrueとなるのは、
false && trueがfalseになって、
false || true
true
となるからだと思うのですが、
ひとつ目がfalseなのに何故ショートサーキット評価されないのでしょうか。
最初に末尾まで見てて、&&の後ろがひとつの論理式である時だけショートサーキット評価されるってことですか。
あと、
var flagB = true || false && false;
flagBがtrueになるのは何故ですか。
true || falseがtrueになって、
true && false
false
になると思うんですが。 >>959
いうだろ？
ES5で書いたものをclassで完璧に書けるんだぜ？
追加効果があったとしても関係ないだろ
それにそもそも糖衣構文って完全に同じものを
実現しなくてはいけないなんて制限はないんだが？
ほぼすべての糖衣構文はある機能に特化することでより便利にしているが
その反面あるきのう以外のことができなくなってる
他のどんなものが糖衣構文と呼ばれてるか考えてみなよ
糖衣構文という言葉に惑わされてるだけだろ >>960
それな。>>938ですでに俺が言ったことだが 一つ例を出してやる
C言語でswitch〜caseはifの糖衣構文と呼ばれているが、
ifでやれることのすべてをswitch〜caseでやれるわけじゃない
switch(a) ← 変数aとの比較限定になっている
この点においてswitchはifの制限版
また逆にswitch〜caseのfall throughはifでは実現できない
この点において、switchは糖衣構文＋αの機能を持っていると言える >>962
ショートサーキットしてる
false && true || trueの二番目のtrueは評価されない
それと後者の答えは優先順位が違うから
&& は||より先に評価される
四則演算でいうと||が足し算で&&はかけ算 >>966
＞逆にswitch〜caseのfall throughはifでは実現できない
そんなことはないと思う
https://ideone.com/tVia2L QZは馬鹿だから無視でおｋ
「車は右側を走れるか」みたいな話は余計脱線するだけ ふむ。まあ要するにES6の機能をES5で実現できれば糖衣構文。
実現できなければ糖衣構文ではない。という定義は
完全に間違っているってことだな >>956
> そこから質問者が食いつけばClass構文が入ることによる新たな可能性を話すつもりだったのに
話したいことがあるのなら勝手に書け
そしてそれに食いつく奴が居るかどうかだろ
順序が逆だ せっかちなのは君の好きにすればいいけど
勝手に思い込んで突っ走って人に迷惑かけて……
もうクズの見本みたいな振る舞いしてる事に気が付いたほうがいいよ
勿体ないよ const foo = [1, 3, 5, 7, 9];
const bar = [3];
console.log(foo[bar]); // 7
このコードの意味がよくわかりません
状況からしてbar[0]の3を自動で取り出してfooの添え字にしてるように見えますが、そんな意味不明な動きしますか？
Cでいう*barみたいに配列の先頭アドレスから値を取り出してる？？ >>974
そんな糞コードは理解出来なくていい
教科書なら捨てた方がいい
百歩譲って「添字はtoString()してるだけ」ということを教えたかったのなら、
数字と文字でやるべきだ >>975
すみません、業務で見たコードで、実際にはfoo相当の配列はオブジェクトの配列でした
先のコードは自分で実験用に動かしたコードです
なるほど、添え字に配列変数を指定すると、toStringメソッドが走る
配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
なので要素が数字かつ1つしかなければ、その数字を添字にしたのと同じことになる、ということでしょうか >>976
概ねその通りだが、俺は
> 配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
これが仕様なのか環境依存なのかは知らんよ。
いずれにしても、「配列を添字として使う」事自体があり得ないだろ。
糞コードだし、修正すべきだよ。
動いているからバグとして検出されず、結果的に修正漏れになっている、ということかな。
なおその手の詳細な挙動を知りたければ、仕様書を読むしかない。
JavaScriptの仕様書は他言語で言う仕様書ではなく、実装指示書（詳細設計書）といった方が正しい。
だからオグジェクトの配列のアクセスの仕方（セマンティクス）がいちいち細かく書いてある。
その中で原則的には全てtoStringされていたはずなので、結果的にはそういう挙動になる。
つまり、
× > 添え字に配列変数を指定すると、toStringメソッドが走る
○ 添え字は何であれ全てtoStringされる
だったはず。気になるなら仕様書を確認して。 × オグジェクトの配列の
○ オグジェクトや配列の
読める範囲ではあるが、若干混乱するかもしれないので念のため。 >>977
丁寧にありがとうございます
どう見てもミスっぽいので直しときます
まさかこれで動くとは思わなかった……js怖い 別にこの程度非難轟々するほどのコードじゃないだろう
暗黙の型変換がたった１回働いてるだけでしかないのだし
添字は必ずシンボルか文字列として評価されるってことも常識として知っておかないといけないこと
この程度にそんなに目くじらを立ててたらJSが読み書きしにくくなるというか
JSは避けてRustで書いてWasmにするとかした方が良いと思う でも文字列を引数にとる既存の関数をタグ付きテンプレートとして呼び出せるのって['foo']が'foo'に変換される仕様のお陰なんだよなぁ
'hogefugapiyo'.split('fuga').join('hage');
↓
'hogefugapiyo'.split`fuga`.join`hage`
意味のないコードだけどあくまで例として。 foo = [ 1, 3, 5, 7, 9 ];
bar = [ 3 ];
p foo[ bar ]
Ruby では、エラーになる。
配列から整数への、暗黙の型変換はできない
やっぱり、JS は、バグる。
怖い javascriptでいう関数ひとつ取ってもる〜ピぃは
def
ブロック
Proc.new
proc
lambda
->
用途に合わせてどれが使えどれが使えないのか、使える場合変換は必要かどうか、変換なしで使える場合も挙動がどう異なるのか（同じように使える場合もすこしづつ挙動が異なるからｗ）あっちとこっちは相互にどういう変換方法があったか、等しっかり考えて作るもんなｗｗ
さすがるっピ！ｗｗｗ >>981みたいな奴が普通に居るのがJavaScriptコミュニティが腐ってる証拠な。
プログラミングを知らない癖に出来ると勘違いした馬鹿が間違ったことを吹聴しすぎてて、
馬鹿が再生産されまくっている。
とはいえ問題点は981以外には分かっているようだし、この話はもういいが。
他言語出身者なら、当初参考にするのはMDNだけにして、
個人が俺ツエーしてるだけのブログ等は全部無視した方がいい。
他言語ではあり得ない確率で間違ってるから、無駄にはまることになる。
emscripten/WebAssemblyが本格稼働するかどうか俺は懐疑的ではあるが、
実際にそうなったときに馬鹿JSerが一斉粛清されるかどうかは見物ではある。
「動けばいい」という基準で書いている限り、「動けばいい」程度のコードしか書けるようにはならない。
しかしこれがJSerの大半なのもまた事実だ。
一般的に「良いコード」とされる物を書けるかどうかはプログラマの技量のみに依存し、
JavaScriptだからといって書けない事はない。
ただ、どちらかというとJSはC寄りで、どんな糞コードでも書けてしまう。
ただこれは、単にJSerの技量が足りないだけであって、推奨されているわけではないので注意のこと。
>>979は今後色々と実感することになるとは思う。 TypeScript使うのはReact使ってるときぐらいだろ？ >>989
あ、すまん。ReactじゃなくてAngularだね c#に似せるならもっとc#にすればよかったのに
あの型の定義の仕方が嫌だ >>991
それはあんたの会社での話でしょ？
あんたの会社の話でもなく、Angular関係でもなく
TypeScriptが使われてることを証明する証拠でもあるの？ >>994
どこが？ｗｗｗ
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png
GitHub Top Languages by Repositories Created: TypeScript is Not in the Top 5.
https://github.blog/2018-11-15-state-of-the-octoverse-top-programming-languages/
https://i.imgur.com/pZcCdjw.png 今時型定義も入れずにnpmモジュール作ってるやつとか、白い目で見られるぞ >>996
ごく少数から？ｗｗｗ
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png
GitHub Top Languages by Repositories Created: TypeScript is Not in the Top 5.
https://github.blog/2018-11-15-state-of-the-octoverse-top-programming-languages/
https://i.imgur.com/pZcCdjw.png >>997
下のページのtypescriptの伸びは見ないふりしてるの？ >>998
延びた結果がこの差なんだよねｗｗｗ
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png javascript最高！
rupyキチガイ死ね！ レス数が1000を超えています。これ以上書き込みはできません。
