+ 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/ そもそも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」仕様があった
での削除された、その理由を考えると良い ちょっとスレチかも知れないのですが
<video src="blob:https://google.com/example";>
のsrcのblobって何を表しているのでしょうか？blob先のURLにアクセスしてみても404なのですが data:image/png;base64,〜のようにDataURIは知ってると思うがそれの親戚だ
よりでかいバイナリデータを扱う場合に適しているAPI >>56
あー、考えたｗ 考えたｗ
はい、この話題はおしまい >>58
そういうことを聞いてるんじゃないだろ
説明が的はずれだな どこが的はずれなんだ？何を表してるって聞かれてバイナリオブジェクトってまんま答えなわけだが >>58
有難う御座います
すみません詳しい説明の乗ってるサイトとかってありますか？
404のページのURLが何を表してるのか分からなくて Q. srcのblobって何を表しているのでしょうか？
A1. バイナリデータを扱う場合に適しているAPIだ！
A2. バイナリオブジェクトだ！
的外れは続くよｗ メモリ上にあるオブジェクトに発行した一時的なIDみたいなもんでそのページのみで有効
普通にいつでもどこでもアクセス可能なURLではない >>64
有難う御座います
URLぽくなってるものの、実際には変数みたいなもので
"blob:https://google.com/example"; が "https://movie.google.com/example.mp4"; みたいな実URLに置き換えられて動画にアクセスしてるって感じで合ってますか？ blob は Binary Large Object の略称だから的外れでもない >>65
動画サイトなら手軽にアクセスできなくしてるのだろう
直リンで見れるようなら自分が持ってる動画プレイヤーや
第三者サイトの動画プレイヤーやとかで見れてしまうわけで
そうすると広告のある自サイトに誘導出来ないから困っちゃうとかね Blobと言うのは要するにプログラム中に存在するファイルデータみたいなもんだよ
そんでそのURLはそのデータを参照させるためのもの
つまりブラウザ内に存在しているデータへのリンクであって、
そのデータはどこかから取ってきたものかもしれないが、
blobURLが外部へのURLに置き換わるわけではない Firefoxスレで質問してみたのですが答えが返って来なかったのでご存知の方お願いします
Fullscreen APIでflashをsrcに指定したiframe要素をフルスクリーン化したあと
フルスクリーン化したiframe内を左クリックすると元に戻っていたのですが
先日リリースされたFirefox55になってからこの方法では戻らなくなり
ESCキーを押した時に戻るようになりました
Firefox55でも引き続きフルスクリーン化の脱出に左クリックを使いたいのですが
何か情報ありませんでしょうか？ その話は知らんけどflashは2020年には廃止されるようだな フルスクリーンのUIはずっと固まってないじゃん
Chromeでもオプション提供してずっと実験してるし
今たまたま望み通りいってることがこの先も上手くいくとは限らないと考えるべきだよ まあdocument.exitFullscreenをうまく使う位しか望みは無いんじゃないの? >>70-72
レスありがとうございます
Firefoxの場合設定いじったり加えると戻ったりするのですが今回は見当もつきませんでした
JavaScriptで制御できればいいんですけどね
iframe側はflash直接埋め込んでるのでJavaScript使えないので
フルスクリーンにしてフォーカスがiframe内に移ってしまうとどうしたらいいかわからないです
iframeが動作が軽快なのでiframeをどうしても使いたいため
objectやembed使う以外でなんかうまい解決策とかありそうでしょうか？ iframeが動作が快適だと考えるのも危ないと思うよ
今ちょうど各ブラウザがiframeの優先度やどういうプロセスで動かすか大改造中だもの
で、iframeが同オリジンなら操作できるかもね >>74
iframeを参照するhtmlもiframeのsrcのflashも同じオリジンです
localhostで使っているものなので
そうするとflash側のソースをいじらないといけないんですかね
一応オープンソースなのでソースはいじろうと思えばいじれるのですが
ActionScriptはさっぱりです >>68
"blob:https://google.com/example";というのは、いったんブラウザメモリへダウンロードしたファイルへアクセスさせる変数ということで合ってますか？
しかし動画ファイルだと数ギガあったりするので
「はい今数ギガの動画を一瞬でダウンロードしたのであとはローカルでアクセスしてください」ってことになっておかしい気がするのですが
どこか認識が違ってるでしょうか？ そうだけどメモリとかよりはもっと抽象的に考えたほうが良いとは思うよ
それで動画はチャンクで細切れに送られてくるものだから
MediaSource APIを使って随時結合していってるんじゃないの？ >>77
そんなAPIがあるんですね。つまり動画を見てる時、再生時間が変わる度に
再生時間に合わせた細切れ動画をダウンロード→blob:http://~~のリンクを今ダウンロードした場所へ変更→blob:http://~~の内容が変わったことをブラウザが感知して新しい動画が再生される
という感じですかね
どうも有難う御座いました 完全に取り残されて、最新の情報に追いつけないのですが、
10年前のコードから、順を追って現在のコードに変えていきたいのですが、
何か最適な学習法やサイトありませんか？ 必ず覚えておきたいという物は少ない
便利機能や雑多なもの、細かい難しい点についてはざっと眺めとくだけでいい
まずばletやconstだけど、どんな説明見ても一回で分かるだろう
次にclassだけど、これも重要な点はすぐ理解できると思う
一番の問題はPromiseかもしれない。
まあググって上の方のページ見とけば良いんだけど、
機能や使い方だけではなく、概念を理解しないといけないから
頭の柔軟度などに依存して難しいかもしれない
あとは本当に自分で自分のために使っていって慣れるしか無い
Promiseはこれから普及するasync関数で真価を発揮する
だからまだ取り残されては居ない
2020年くらいまでは猶予がある ESの変更については上記の通りだが、
Web APIについては、進化点を探すのが難しいかもしれない
取り敢えず自分が情報追うのに使っているのは、このChromeの実装計画
https://www.chromestatus.com/features
ここを左の下のVersion 1から順に選んで見ていったら良いかもしれない
追加だけでなく廃止された重要な点も書いてある 無理だとは思いますが、
Windowsのスタンバイ時、スタンバイ復帰時に、
開いていたブラウザでイベントを起こすことってできますか？ 似たようなことはできるよ。
調べるの面倒なんで
例のWeb APIマニアさん頑張ってｗ 出来ると知っているのに「調べるのが面倒」とはどういう意味だ？ 知ったかして、詳しい人が解説してくれるのを待つテクニックか 自分も気になって横から知ったか書き込みしたんだろうけど
スレの雰囲気も悪くなるしただ迷惑 横着な方法だけど、１秒毎に時間測って一定以上感覚開いていないか調べれば良いんじゃないの？ Promise は過渡期に出来てしまったから、.method() な連結記法が鳥肌ものにダサい。 Promiseってなんじゃ？xhrじゃだめなんけ？ Promiseは昔っから概念がある物だしESでも１年以上十分に練られただろうよ。 Promiseはasync-awaitと組み合わせてこそ最強 awaitぐらいasync無しに単体で使わせろよと思う >>92
時間掛かる処理の場合、続けてなにかやりたいときは
コールバックで渡すからやりたいことがいくつもあると
どんどんネストしていくことになるじゃん？
promiseはそうではなく、メソッドチェーンで繋いでも
ちゃんとひとつひとつの処理が終わるまで待ってくれるやーつ 今electronやっててjqueryで要素の編集とかで練習してんだけど
electronとjqueryの相性悪いのとjquery単体で画面パーツとか無いから新しいライブラリ探してるんだけどいいのないですかね？？
色んな画面パーツとそこからのイベントが簡単に用意出来ればいいんだが >>97
reactとかvue.jsとかかね。vue.jsが無難 サーバサイドのデータをクライアント側で編集するタイプのアプリを作っていますが
サーバサイドの状態とクライアント側が前提としている状態が
ズレた時の問題について考えています
データ変更のたびに変わっていくバージョン情報を設定し
クライアントが読み書きする時にはサーバに自分が所有しているバージョン情報を渡し、
それがズレていたらサーバは差分情報をクライアントに返し、
クライアントは差分を自分に適応する、
というような方法がいいのではないかと思ったのですが
もっといい方法ありますか？
あとこういうアプリのサンプルが載ってる本とかあれば教えてください >>97
これ立ち読みしてみ。
https://www.amazon.co.jp/dp/4774188190
どんなクオリティであれ自分が勉強してる分野の紙の本が出てるってすばらしい！
検索しなきゃいけない量がめっちゃ減るからね。 >>99
Firebaseはどう？
PouchDBは？ >>99
> サーバは差分情報をクライアントに返し、
> クライアントは差分を自分に適応する、
という部分の実装がどれだけ面倒かによるかな。クライアント側の１レコードの編集に掛かる手間がどれだけか、というのも考慮したい。
サーバのデータ（レコード）に最終更新日時を持たせて、それをバージョン情報として利用できる。
DBの更新条件に最終更新日時を付けてUPDATEして、更新されたレコード数を確認。もし0件だったら、最終更新日時が変更されていたことになる。
> あとこういうアプリのサンプルが載ってる本とかあれば教えてください
本とかは知らない。 >>98
おおおりがとう
>>100
これ実はフライングで買ってしまったんだけど解説に次々に知らんjsライブラリぶっこんで来るからソースコードの理解進まないから止めたわ、、 >>102-103
firebaseっていうの知らなかったんですが、
面倒な部分をgoogleに全部丸投げできるのめちゃくちゃ魅力的ですね
調べてみます
ありがとうございました 数秒ごとに細かく同期して、ずれたら単純に破棄するのが一番見易いよ setIntervalとかsetTimeoutって結構誤差出ませんか？
プチフリするようなしょぼい環境だったり
秒数カウントする（何回も呼ぶ）ものとかだと特にそんな感じがします
1/1000秒単位で正確なタイマーが欲しい場合って
別のタイマー使ってで数秒起きにズレ修正したりするのでしょうか？ なんか高精度のタイマーあったろ？
Web APIマニアさんに後は任せた ■ このスレッドは過去ログ倉庫に格納されています
