+ JavaScript の質問用スレッド vol.131 +
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」だけでなく「意見」を出しても良い。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【条件】期待する回答の条件を書いてください。(ex: jQuery不可, フレームワーク不可)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける=荒らしです >>273
事細かにありがとうございます。
プログラミングの知識はないのですが、外注に当たって方向性だけでも確認したかったので助かりました HTMLは初級ぐらいでJavaScript(TypeScript)も普通ぐらいには使えるようになって、
Reactも使えるようになったのですが、目的のUI作れません。
WPF/UWPならXAMLとコントロール使って、AndroidならレイアウトファイルとViewコントロールを使って
複雑でないUIならとりあえず普通に作ってアプリ作れるんですが。
自分のレベルだとWebアプリだとかなり死ねます。
例えば、ちょっとこの項目を右寄せ表示するにしてもできねぇーとかのレベルです。
やっぱ、CSSを覚えるしかないのでしょうか??みなさんはバリバリCSS使いこなしてるんでしょうか?? >>275の続きです。
例えば、Material UIなどReact用のコンポーネントはドキュメント見れば普通には使えるようになったんですが、
タブにアイコンつけたいとか、リスト表示でこの項目を右寄せしたいとか
Reactコンポーネントのプロパティに用意されてないことやると、
とたんにダメなレベルで、UIがつくれません。 >>275-276
cssも覚えないと、結局細かい事は何も出来ない
>タブにアイコンつけたい
font-awesomeのver4を使う
>リスト表示でこの項目を右寄せ
text-align:right >>275
> やっぱ、CSSを覚えるしかないのでしょうか??みなさんはバリバリCSS使いこなしてるんでしょうか??
HTMLもCSSも使いこなしてるよ。というかJavaScriptだけでやろうとしたら破綻する
基本的にJavaScriptではデザインは作らない
JavaScriptでやるのは状態に応じてclassを設定するとかそういうことぐらい
そのclassに応じてどういう見た目にするかはすべてCSSで行う
そうしないと面倒なだけだから
逆にCSSを使いこなすと処理とデザインの責任範囲が明確になるから
コードはシンプルになるし、デザインの修正も簡単になる 個人的には細かいこと気になるならCanvasの方がオススメ >>234
>>235
>>236
規制で書き込めなかったけど読ませていただきました。
無事解決しました!ありがとうございました(遅) 「当方のエージェントは、追跡を避けるためメールアドレスを毎週変更している。
かあわいい ついに宇宙一難解なパズルが完成しました・・
その名も
『宇宙一難解なパズルゲーム』!!
http://jagarikin.html.xdomain.jp/pzl.html
htmlでできてるのでブラウザから手軽に宇宙一難解なパズルをプレイできるよ〜 5年ぶりに触り始めたんですけども、
var不要論ってなんすかね? let, constが使えるならvarで宣言する意味はない(少なくともletに置き換えて問題ない)
そして現状、メジャーな環境では使える
それならvarいらんよね、という主張かと コールバックの中のreturnについてお伺いします。
ttps://azu.github.io/promises-book/#promises-overview
の中の、promise-workflow.jsについてなのですが、
このサンプルコードを仮に2連続で呼び出すように改変する場合、A部分を
asyncFunction()
.then(function (value) {
console.log(value); // => 'Async Hello world'
return asyncFunction()
}).then(function (value) {
console.log(value); // => 'Async Hello world'
})
のように書くかと思うのですが、最初のthenの中の、
return asyncFunction()のreturnは、関数を実行するだけなのになぜ必要なのでしょうか?
以前も別件でfoo.map( ( x ) => x*2 )を
foo.map( ( x ) => { x*2 } )と書いてしまい、returnでハマりました。
どなたかこのreturnのミステリーについて教えてください。 >>287
> 関数を実行するだけ
ではない。
asyncFunction() は promise も返す。
2 つめの then は、その promise がresolveされたときに呼ばれることになる >>288
訂正
2 つめの then は、…
→
2 つめの then の中のfunctionは、 … >>289
ありがとうございます。
asyncFunction()
.then(function (value) {
console.log(value); // => 'Async Hello world'
asyncFunction()
}).then(function (value) {
console.log(value); // => 'Async Hello world'
})
この書き方では動かないのは、これではpromiseが返ってこないということです…かね?
説明が下手で本当に申し訳ないです。 Promiseのthenメソッドが返すPromise Tはthenメソッド中でPromise Rを返した場合
Rの解決を待って、その解決値を持ってTが解決されることになる
つまり実質的にT==Rと言うように振る舞わせることが出来る
つまり、
非同期A .then( Aの解決値を得て、別の非同期Bを実行 ) .then( Bの解決値を得て、別の非同期Cを実行 ) .then ......
というようにどんどんthenを繋げて行くことができる
勿論then中でそのチェーンとは独立したPromiseを作成することを繰り返してもいいが、
そうすると所謂コールバック地獄のようにネストが深くなってしまう
それを平坦化するためにこの機能がある >>290
Promiseをreturnするのが自然だけど
気持ち悪いなら別にこう書いたって良い
https://jsfiddle.net/4kks4bns/ 皆さん、ありがとうございました。
ようやく納得がいきました。 この流れで理解できたのか・・・?
なんか質問者も回答者もずれまくってる気がするんだが なぜか納得してるようだが、これで納得できるはずがないので勝手に説明するわ
まず基本(?)系。thenを二回続けているが、asyncFunction()は
一回しか読んでないパターン
asyncFunction()
.then(function (value) {
console.log(value); // => 'Async Hello world' ・・・(1)
}).then(function (value) {
console.log(value); // => undefined ・・・(2)
});
(2)でundefinedになっているのは、1回目のthenで何もreturnしてないから
JavaScriptは関数で何もreturnしてない場合はundefiendになる
(Rubyなどのように最後に評価された値ではない)
次のように、thenでreturnすれば次のthenの関数の引数に渡すことができる
asyncFunction()
.then(function (value) {
console.log(value); // => 'Async Hello world' ・・・(1)
return value;
}).then(function (value) {
console.log(value); // => 'Async Hello world' ・・・(2)
return value;
}); >>297の例では、return valueと単なる値を返した、
単なる値を返すと、次のthenの引数になるが、
単なる値の代わりにPromiseオブジェクトを返すこともできる
function newPromise() {
return new Promise(function (resolve, reject) {
resolve('new-promise');
});
}
asyncFunction()
.then(function (value) {
console.log(value); // => 'Async Hello world' ・・・(1)
return newPromise(); // 参考 return Promise.resolve('new-promise') と書いても良い
}).then(function (value) {
console.log(value); // => new-promise' ・・・(2)
return value;
});
この場合、2番目のthenの関数の引数には、Promiseオブジェクトが渡されるのではなく、
Promiseでresolveされた値(new-promise)が渡される
もしnewPromiseがresolveするまでに時間がかかる場合は、
2番目のthenが呼び出されるまで時間がかかるということ
thenで単なる値を返した場合は、次のthenはすぐに実行される。
すぐにresolveされたのと同じだと考えればいい
このように、thenでreturnするのは単なる値でもPromiseオブジェクトでも良いという
仕様のために、Promiseを返さない単なる関数をあとからPromiseに変えても
同じように動かすことができる。同期と非同期の違いを吸収していると考えることができる。 >>287でreturnしない場合、
asyncFunction() ・・・(a)
.then(function (value) {
console.log(value); // => 'Async Hello world' ・・・(1)
asyncFunction() ・・・(b)
}).then(function (value) {
console.log(value); // => undefined ・・・(2)
})
(a)のasyncFunction()につながってるthenの結果として
(1)と(2)のconsole.logが実行される。
(2)のconsole.logがundefinedなのは間違いではない。
なぜならthenでreturnしてないのだから当然undefinedになる
(b)のasyncFunction()は何の意味も持たない。なぜなら(b)がresolveしても
その後にthenがないので(b)の結果としては何も出力しない
returnした場合は意味が異なる。(a)の1番目のthenの戻り値はPromiseオブジェクト
そのため(b)がresolve()された後にresolve()された結果が2番めのthenに渡される。
asyncFunction() ・・・(a)
.then(function (value) {
console.log(value); // => 'Async Hello world' ・・・(1)
return asyncFunction() ・・・(b)
}).then(function (value) {
console.log(value); // => 'Async Hello world' ・・・(2)
})
注意として(1)のvalueと(2)のvalueは(同じ文字列だが)違うオブジェクト
(1)は(a)がresolve()された結果だが、(2)は(b)がresolve()された結果 >>287の
> 以前も別件でfoo.map( ( x ) => x*2 )を
> foo.map( ( x ) => { x*2 } )と書いてしまい、returnでハマりました。
これは単純な勘違いをしているだけ
{ } を省略したら return も省略できる
{ } で囲んだら return が必須
というだけの話
個人的にはアロー関数は、関数っぽく見えないのも利点の一つだと思ってるので
前者の書き方をおすすめする。 { } をつけて returnを書いて、ましてや { } の中に
複数の式や文を書くのはなんか違うと思ってる >>300
ありがとうございます。自分の納得は低レベルでした。
めちゃくちゃわかりやすかったです。精進します。 >>300
お前それforEachさんの中でもおんなじこと言えんの? forEachとか使わないな。
普通はmapとか使う 個人的にforEachは名前をforやeachにしなかったのが結構な失敗だと思ってる >>304
普通って何よ。お前の普通なんて知らんがな。
javascriptで副作用だけ使いたい場面なんていくらでもあるだろう。
console.log使って例示すると、
['foo', 'bar'].forEach(item => {
console.log(item);
});
map使うってお前…これをお前は
['foo', 'bar'].map(item => console.log(item));
と書くのか?
[undefined, undefined]なんて生成してなんに使うの?
なんでもかんでもmapはダメだろ。それぞれ想定されてる用途がある。
あとアロー関数の{}にreturn必須とか嘘教えんな。
複数の文を書くなと言うのもどういうことだ。
ちょっとしたcompare function書くとき、読みやすさや入力値チェック処理などで複数行になったらアローじゃなくてfunction(){}使えってこと?
どんなオレオレルールだ。わけの分からない縛りいれるのならアロー関数なんてやめたら。
['大', '小', '小', '中', '中', '大'].sort((a, b) => {
const order = ['小', '中', '大'];
return order.indexOf(a) > order.indexOf(b);
}); 普通こうやるからなぁ
console.log(['foo', 'bar']); おじいちゃん、配列の要素をそれぞれログするのと配列をそのままログするのは違うでしょ。
前者は
foo
bar
後者は
[ 'foo', 'bar' ]
になるでしょ。
ロシアのえんぴつ的なことが言いたいならそもそもブラウザのデベロッパーツール使えばいいでしょ。
でもそういう話じゃないから。 まあ普通にこうかくだろうな
何度もconst order = ・・・を実行するのは無駄だし
const order = ['小', '中', '大'];
const data = ['大', '小', '小', '中', '中', '大'];
data.sort((a, b) => order.indexOf(a) > order.indexOf(b)); >>309
ごもっともな指摘。
もっとちゃんとした例考えないとな… ちなみに最後の
data.sort((a, b) => order.indexOf(a) > order.indexOf(b));
は、order.indexOfを二回書くの無駄だと思わね?
lodash使うとこう書ける
_.sortBy(data, v => order.indexOf(v)); へぇー思想違うんだなぁ。
考えてみてもこの仕様で困る例が思い付かない。
素のsortでは表現できてlodashのsortByでは無理な比較仕様ってあるのかな 思想? 違いがあるとしたら
まあ何かやりたいことがあって、それを実現するためには
どういうふうに処理したらいいか?と考える人と
やりたいことがそのままコードになってないと気がすまない人の違いかな
俺は「文字の小さい順に並び替えたい」と思ってるから
コードには「文字」「大小を求める」「並び替える」この3つぐらいしか
登場してほしくないんよ。人間の思考の通りのコードになって間違いが少なくなる
一方で、並び替えるには文字と文字をそれぞれ数値化したものを比較する関数を
ソート関数に渡せば実現できるという、やりたいことを処理に置き換えてからコードにするやつもいる
処理を考えてしまうから、こっちのやり方では冗長化してしまうんだよ。それが困ることだな >>312
あり得そうな気がするが、相当なレアケースじゃないかな。事実上困らない >>316
こういうこと?
https://lodash.com/docs/4.17.4#sortBy
var users = [
{ 'user': 'fred', 'age': 48 },
{ 'user': 'barney', 'age': 36 },
{ 'user': 'fred', 'age': 40 },
{ 'user': 'barney', 'age': 34 }
];
_.sortBy(users, ['user', 'age']);
// => objects for [['barney', 34], ['barney', 36], ['fred', 40], ['fred', 48]] ライブラリ使う必要ない場面で
ここでしか見ないナントカってのを執拗に勧めるやつまだいたのか
害悪だなぁ ここでライブラリを使うって事は間違ってないと思うよ
ただsortByっていう名前での
結局ライブラリを覚えないと自明ではない振る舞いは好きじゃないし
それがこの一時で便利だとは思わない >>319
sort by というのは例えばRuby標準にも有るしよく知られた単語なんだよ
プログラマにとって、for といえば ループねって
わかるように、sort by というだけで何をするのか知ってるもの
それに対して、オレオレライブラリで勝手な名前を作ると困る
それが何をするのかわからない
同じ覚えることでも、一般的なものを覚えるのと
プロジェクト固有のものを覚えるのとでは、覚える価値が違う
lodashはよく知られたアルゴリズムをよく知られた名前で実装してるので
覚える価値が高い。たとえ使わなくても知っておいたほうが良いものばかりだよ 他の言語にあるって然程重要では無いと思うけどね
特に補完が弱い動的型付け言語のJSでは
いかに他のJS周りの標準と命名規則を揃えて
振る舞いや型を想像付かせるかが大事
JSにsortByのような文化は無いのだから
なんぼRubyやらにそれがあると言われても
多くのJSerはローダッシュのsortByと覚えることになるのよ >>322
> JSにsortByのような文化は無いのだから
世界が狭いな。
あんたはJSの世界に生きてるわけか
俺はプログラマの世界に生きてるんだよ。
JSはそのプログラマの世界の一地域にすぎない >>324
それは日本人に会った時世界の挨拶だからと言ってハグするようなもんだぞ >>326
それは的はずれだな。
今言ってる世界っていうのは、広さの話をしてる
JSの世界っていうのはプログラマの世界の一部 >>328
今は相対的な話をしているので、
プログラマの世界よりも○○の世界が広い言い方をしてくれない困る
そして○○が話と全く関係ない世界だとそれは意味がない JSerの価値観っていう話でさえ既に十分に大袈裟で広い話なのに
JS質問スレにプログラマの世界(しかも一部の>>324が好きな言語限定)とか持ち込まれてもな 好きな言語限定?
いろんな言語の知識を持っていると
好きな言語以外の話も持ち込むよ?
本当にあんた世界が狭いねw すんごく初歩的なことで申し訳なさでいっぱいなんですが教えて下さい
clickイベントリスナをつけた<button>や<input>があって
これをdisabled="disabled"やelement.disabled = trueでdisabledにしたとき
<button>や<input>をclickしてもイベントは発火しない
これ合ってます?この挙動普通? >>331 見てて恥ずかしい奴だな もう口を開くな >>333
断るw いくらでも言うよ?見たくない、聞きたくないなら、
俺に何かをさせるんじゃなく、あんたが自分で行動しなきゃだめだよ 自演しつけえ
お前が低レベルなことはみんなわかってるからw >>318-322,324-331,333,334,336
とりあえずこれ全部低レベルな1人の自演 はい、はずれw
それはいいからどこが低レベルなのか
その理由を言ってみたら?
言えなきゃ言えないやつが低レベルってことだし なぜ自作自演だって見抜いただけで
俺様の世界ってことになるのか? >>340
自演なんだろ?お前の中ではな
って言えば理解できるかい? アジアではこういう考え方が主流なんだから狭い価値観に捕われるなって言うのと
その前にここは日本人による日本人のためのスレなんだから日本の考え方を深く学ぶべきって言うのと
アジア基準が常識とか中途半端で恣意的な価値観だなっていうヤジの3つに分けれてる 質問スレなんだから質問とそれに対する回答だけでいいんだよ
考え方とかどうこうはいらない
自分の考え方と違うなら「こういうやり方もあるよ」と自分なりの答えを書けばいい
どれを採用するかは質問者の自由 「考え」は書くな
「答え」を書け
ただし質問に書いてもいないライブラリやフレームワーク持ち出すのはただのバカだからNGだろ 書いてもいないライブラリやフレームワークが答えの場合だってあるだろ?
ってか答を知らないから質問する訳で
答を質問に書くわけがない お前らwshスレって落ちました?
質問しようとしたらスレッド一覧にない・・・ 関数へ引数の渡し方が、func(A)、func(B)、func(A, B)、の3種類(のみ)。
(A, B)の場合は共に実行。
関数内は、A、Bそれぞれ同じ処理。例えば$('#hoge-' + A).〜。
処理は長いのでif分岐は重複が多すぎ。
yobidasi(A);
yobidasi(A, B);
function func1(arg1, arg2){
func2(arg1);
if(arguments.length === 2){func2(arg2)};
function func2(arg){
$('#hoge-' + arg).〜;
$('#hage-' + arg).〜;
}
}
より簡単な書き方教えてください。 そもそもfunc(A);func(B);で良くねとは思うけど
function func(...args) {
for (let arg of args) {
// $('#hoge-' + arg).〜;
// $('#hage-' + arg).〜;
}
} > 関数へ引数の渡し方が、func(A)、func(B)、func(A, B)、の3種類(のみ)。
> (A, B)の場合は共に実行。
その(A, B)をやめろって話だな >(A, B)をやめろ
そうなのですが、すると
yobidasi(A);
yobidasi(B);
となり、yobidasiの類は20種類あるので40行になってしまいまして。 yobidasi(A), yobidasi(B);
で良いじゃん >>351
forループはオブジェクトのみ推奨って先生が言ってなかったっけ? >>355
その「先生」は担任の先生って言う意味で素人だろw >>357
google先生だろ
SEO少しでもかじったのならすぐピンとくる >>358
オマエ馬鹿だろ JavaScriptって知ってるか? > forループはオブジェクトのみ推奨って先生が言ってなかったっけ?
これがSEOと関係があるとでも?
ないない Objectのみ推奨ってのはfor-inのことだろ >>353
>>351でもいいけど、
とにかく君に一番必要なことは配列を覚えることだな js初心者です。
var accounts = {
'mail@address1': 'user1',
'mail@address2': 'user2',
...
'mail@address100': 'user100',
'mail@address n': 'user n',
}
このように別のプログラムで使用してるオブジェクト型の文字データがありましてそれを利用したいのですが
うまく行かないので教えてください。
オブジェクトのデータの登録数は不定の為、メールアドレスとユーザー名を1セットと考え総数をカウントしたいのと
n番目のメールアドレスとユーザー名を文字列データで取得したい。
全部を読み取って文字列配列にいれてもOKですし、n番目のデータは何と返すだけでも構いません。
例えば 登録総数111で100番目のデータを取得した場合
100/111 のデータは、ユーザーはuser100でアドレスはmail@address100です のように出来るとありがたいです。 スクレイピングのサイト巡回を自動化するスクリプトかいてて
テストでクロムの開発者ツールでいろいろためしているんだけど
ログインが必要なサイトで名前とかのフォーム入力まではできたのですけど
それをsubmitするほうほうがわかりません。
「送信」ボタンのセレクターからノード?オブジェクトを取得。
例えば var button = document.querySelector('セレクター')
それにbutton.submit()という感じでsubmit()をつけてみたけど↓みたいなエラーがでます
どうすればいいのでしょうか?
button.submit()
VM775:1 Uncaught TypeError: button.submit is not a function
at <anonymous>:1:8
とコンソールにエラーがでます 配列はfor かfor of
for in はオブジェクとって本に書いてた >>365
自分も初心者だとことわっておくけど
mapオブジェクト使えば?
マップオブジェクトの作成
var mail = new Map()
中身の追加
mail.add('name3','address3')
IDとの名前の対応表を作成
var id = {1:"name3"}
要素数の取得
var size = mail.size
console.log(size)
名前からアドレスの取得
console.log(mail.get('name3')) >>366
自己解決しました
formエレメントの要素オブジェクトにsubmitをつけるんですね >>365
Object.keys(accounts)でキーの配列を取得できる
総数が欲しいならObject.keys(accounts).length
ES2017からはObject.entries(accounts)が理想的
ただし順序は保証されない
可能ならオブジェクトは避けるべき ■ このスレッドは過去ログ倉庫に格納されています