私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.141 +

みんなの評価 :
レスフィルター : (試験中)
外様、と表現されているもので挙動が変わり得る、を以て「仕様上保証されているものではない。」と書いたのだが、理解頂けなかったようで。
そんなもんはぶっちゃけ、どうでもいいんだけれど、V8でMapやSetが重い点に関して、何か情報頂けないか。
Objectのプロパティアクセスがカリカリチューニングで早いのは当然、と言うかそうじゃないと使い物にならない、のは想像に易い。
MapやSetの速度改善は、
・あり得るのか
・進む予定はあるのか
・進む可能性はあるのか
例えば万単位でPush的な操作した際の処理時間がObjectよりかなり遅いと思っている。
logとか手元に残してなくてごめん。
そんなもんはぶっちゃけ、どうでもいいんだけれど、V8でMapやSetが重い点に関して、何か情報頂けないか。
Objectのプロパティアクセスがカリカリチューニングで早いのは当然、と言うかそうじゃないと使い物にならない、のは想像に易い。
MapやSetの速度改善は、
・あり得るのか
・進む予定はあるのか
・進む可能性はあるのか
例えば万単位でPush的な操作した際の処理時間がObjectよりかなり遅いと思っている。
logとか手元に残してなくてごめん。
仕様に大変詳しいここのお偉方様に質問です
配列の要素やオブジェクトのプロパティに値を代入する変数に対して、
constを使わずにletを使う例を見るのですが、これはconstの意味の取り間違えですか?
それとも"内容を変更する可能性がある"という目印のため、あえてそうする風習があるのですか?
配列の要素やオブジェクトのプロパティに値を代入する変数に対して、
constを使わずにletを使う例を見るのですが、これはconstの意味の取り間違えですか?
それとも"内容を変更する可能性がある"という目印のため、あえてそうする風習があるのですか?
>>101
いやいや、流石にそれはない
JSは拡張自由であり、基本的に実行環境で拡張して使うスクリプト言語なんだから外様のことまで考えてたらきりがない
例えばオブジェクトをブーリアン型に変換したらtrueになるが、document.allなど外様を考えたらその限りではなくなるでしょ
外様を考慮するのは流石にバカとしか言いようがないよ
いやいや、流石にそれはない
JSは拡張自由であり、基本的に実行環境で拡張して使うスクリプト言語なんだから外様のことまで考えてたらきりがない
例えばオブジェクトをブーリアン型に変換したらtrueになるが、document.allなど外様を考えたらその限りではなくなるでしょ
外様を考慮するのは流石にバカとしか言いようがないよ
for...ofやfor...inについては、for文の印象を引き摺って、考え無しにletを使ってしまっているのではないか。varしか無かった時代の名残りとも言えるかも。
let a = [];についてはもしかすると、aに対して要素の編集、変更をしたいんだよ、と明示したくてletにしているのかもしれない。編集したい内容次第では、代入した方が早いような配列操作は結構多い。その辺の修正を見越してletで定義しているのか?
根本的には書いた人間に聞くのが良いのかと。
let a = [];についてはもしかすると、aに対して要素の編集、変更をしたいんだよ、と明示したくてletにしているのかもしれない。編集したい内容次第では、代入した方が早いような配列操作は結構多い。その辺の修正を見越してletで定義しているのか?
根本的には書いた人間に聞くのが良いのかと。
for..of/for..inのパターンは考えなしにletでもいいんじゃないかという気がしないでもない
このケースで誤って再代入して困るようなコードってどんなの?
このケースで誤って再代入して困るようなコードってどんなの?
ふむふむ
皆様ありがとうございました
個人的にはconst厨なので気になるのですが(というかJSにconst厨なんてあり得ないと思ってる)
varからの移行で、というのはあるかもしれません
for-ofにconstが使えなかった時もありましたしね
皆様ありがとうございました
個人的にはconst厨なので気になるのですが(というかJSにconst厨なんてあり得ないと思ってる)
varからの移行で、というのはあるかもしれません
for-ofにconstが使えなかった時もありましたしね
>>109
そりゃあうっかり再代入したあとに再代入してないつもりで使ったときに困るんじゃないですか
constの利点は意図しない再代入をエラーで気づかせてくれることですから
それ以上でもそれ以下でもないと思います
そりゃあうっかり再代入したあとに再代入してないつもりで使ったときに困るんじゃないですか
constの利点は意図しない再代入をエラーで気づかせてくれることですから
それ以上でもそれ以下でもないと思います
イミュータブル流行ってんのも巨大オブジェクトの差分検出に必要とかいうクソどうでもいい理由だしな。
俺は全部letで書くぜ!
俺は全部letで書くぜ!
letでも再定義はできないのだから
値を設定するときにlet x=vの形で書く以上うっかり再代入なんてありえない
例えば関数頭でこの変数の値は不定だと思って定義して
その中のクロージャで、よし弄るぞってなることもありえない
まずより広範囲で使われることになるオブジェクトをfreezeするとか
プロパティごとに設定すべき(privateも含めて)という話なら分かるが
constだけに拘っても得られるものは自己満足だけ
値を設定するときにlet x=vの形で書く以上うっかり再代入なんてありえない
例えば関数頭でこの変数の値は不定だと思って定義して
その中のクロージャで、よし弄るぞってなることもありえない
まずより広範囲で使われることになるオブジェクトをfreezeするとか
プロパティごとに設定すべき(privateも含めて)という話なら分かるが
constだけに拘っても得られるものは自己満足だけ
あるとすれば、後続処理でブロックスコープなり、即時関数なり使っていて、その中でletで再代入を前提とした同名の変数を定義していて、何かしらの修正時に、この同名変数の定義部分が無くなったが、この同名変数への再代入処理が残っている、と言う場合くらい?
そもそも別スコープとは言えど、同名で変数定義するのは避けよう、と言う程度な問題ではある。
そもそも別スコープとは言えど、同名で変数定義するのは避けよう、と言う程度な問題ではある。
>>115
なるほどねー
自分の場合はループ内にそんな長々と処理かかないからその問題はまず発生しないな
for-of/for-inでletにするかconstにするか一瞬考えたりconstからletに変更するほうが無駄に思えてきた
なるほどねー
自分の場合はループ内にそんな長々と処理かかないからその問題はまず発生しないな
for-of/for-inでletにするかconstにするか一瞬考えたりconstからletに変更するほうが無駄に思えてきた
>>117
先の理由で広範囲だったり遠方で使う一部の定数になら使う意味があると思う
ということはそういう定数をそういう定数ですよと効果的に示すために使ったほうが
あるかないかもわからない「うっかり」のために全部constにするよりはメリットが大きいんじゃないかという話
そうじゃない大部分の変数はスコープを短くするのが基本なんだから
痴呆でも無い限りそんなうっかりが起こることはない
それが起こる確率とconstとletで2文字多い分打ち間違えやらでトラブる確率どっちが高いのかって話だよ
拘るのは結構だが、constだけに拘ってオブジェクトを放置したり
型周りを放置するのは本当に理にかなっているのか?
まあそこまでするなら結論altJSでやれと言いたいけどな
先の理由で広範囲だったり遠方で使う一部の定数になら使う意味があると思う
ということはそういう定数をそういう定数ですよと効果的に示すために使ったほうが
あるかないかもわからない「うっかり」のために全部constにするよりはメリットが大きいんじゃないかという話
そうじゃない大部分の変数はスコープを短くするのが基本なんだから
痴呆でも無い限りそんなうっかりが起こることはない
それが起こる確率とconstとletで2文字多い分打ち間違えやらでトラブる確率どっちが高いのかって話だよ
拘るのは結構だが、constだけに拘ってオブジェクトを放置したり
型周りを放置するのは本当に理にかなっているのか?
まあそこまでするなら結論altJSでやれと言いたいけどな
お前の意見には全然賛同できないし
お前もこっちの意見には絶対に靡かないと分かってる
お前もこっちの意見には絶対に靡かないと分かってる
個人的は、
全てconstに出来ないのは能力不足だとは思う。
全てconstにせよ、は合理的じゃないから採用はしない。
だからどうした、俺の美学…と言う話だなぁ。
ついでに言えば、varはもう、特殊過ぎて使いこなせる気がしないから使わない。昔使ってた自分を褒めてあげたい。
全てconstに出来ないのは能力不足だとは思う。
全てconstにせよ、は合理的じゃないから採用はしない。
だからどうした、俺の美学…と言う話だなぁ。
ついでに言えば、varはもう、特殊過ぎて使いこなせる気がしないから使わない。昔使ってた自分を褒めてあげたい。
特殊過ぎ?
関数スコープであることとカツ上げ以外何かあったっけ?
関数スコープであることとカツ上げ以外何かあったっけ?
レガシーでvar hoge=1とかfunction hoge{}とかグローバルに書くと、window.hogeが生えるのがクソキモイ。怖くて使えなーい。
もう、関数宣言とかvarとか使わないから、モジュールでどう動くのかは知らないけど、多分使わない。
Numberって、IEEE 754 の倍精度 64ビットバイナリ形式な浮動小数なんじゃなかったかい?
プロパティ拡張とかも出来ないはずだから、多分ほぼそのまんまだとは思うけれど、V8の実装の詳細は知らない。
探せばV8のソース見れるから、ソース見て追うのが間違い無いとは思う。
もう、関数宣言とかvarとか使わないから、モジュールでどう動くのかは知らないけど、多分使わない。
Numberって、IEEE 754 の倍精度 64ビットバイナリ形式な浮動小数なんじゃなかったかい?
プロパティ拡張とかも出来ないはずだから、多分ほぼそのまんまだとは思うけれど、V8の実装の詳細は知らない。
探せばV8のソース見れるから、ソース見て追うのが間違い無いとは思う。
すみません。質問させてください
Math.floor(Math.random()
でテキストを5~6項目程度
setInterval('location.reload()',timer);
で自動でランダム表示させてます。
その際、テキスト内容をgetElementById("span1").innerHTMLでフォーム入力で書き換えたいのですが
location.reload()でクリアされてしまします。
フォーム入力で設定したテキスト内容をlocation.reload()でも反映させ続ける方法は
ないでしょうか?
基礎知識が無い中、見様見真似で作成しており不明瞭な点ばかりかとおもいますが
なんとかご教示のほうよろしくお願いします。
Math.floor(Math.random()
でテキストを5~6項目程度
setInterval('location.reload()',timer);
で自動でランダム表示させてます。
その際、テキスト内容をgetElementById("span1").innerHTMLでフォーム入力で書き換えたいのですが
location.reload()でクリアされてしまします。
フォーム入力で設定したテキスト内容をlocation.reload()でも反映させ続ける方法は
ないでしょうか?
基礎知識が無い中、見様見真似で作成しており不明瞭な点ばかりかとおもいますが
なんとかご教示のほうよろしくお願いします。
>>124
巻き上げられない変数など存在しない
変数というのはスコープに属していて
その割当範囲で有効になるものなんだから存在や定義が
巻き上げられて行われるのは当たり前のこと
let.constがvarと違うのは当該宣言に達するまで初期化まではされないということ
よって仮想的にスコープの先頭から当該宣言までの間が
変数が定義はされているけれど未初期化なので使えない区間(TDZ)となる。
巻き上げられない変数など存在しない
変数というのはスコープに属していて
その割当範囲で有効になるものなんだから存在や定義が
巻き上げられて行われるのは当たり前のこと
let.constがvarと違うのは当該宣言に達するまで初期化まではされないということ
よって仮想的にスコープの先頭から当該宣言までの間が
変数が定義はされているけれど未初期化なので使えない区間(TDZ)となる。
>>129
ご返信ありがとうございます。
質問テンプレート無視してました。すみません。
事務所の大画面スクリーンに周知事項や注意喚起のメッセージを
10項目程度ランダムで表示させております。
終日表示させているので規則性があるとキツイかなと思いまして。
現状はhtmlソースを上書き更新しているのですが
誰でもテキストボックスやformから入力更新できるようにしたいと
考えております。
ご返信ありがとうございます。
質問テンプレート無視してました。すみません。
事務所の大画面スクリーンに周知事項や注意喚起のメッセージを
10項目程度ランダムで表示させております。
終日表示させているので規則性があるとキツイかなと思いまして。
現状はhtmlソースを上書き更新しているのですが
誰でもテキストボックスやformから入力更新できるようにしたいと
考えております。
>>131
hoistされないとかあるの!?ってなったのでスッキリした
hoistされないとかあるの!?ってなったのでスッキリした
textContentプロパティとinnerHTMLプロパティの違い
http://itsakura.com/js-textcontent-innerhtml
<h1>あ</h1>
などと、タグを入力された場合に、挙動が異なる
innerHTMLでは、h1タグが解釈されて、文字が大きく表示される
http://itsakura.com/js-textcontent-innerhtml
<h1>あ</h1>
などと、タグを入力された場合に、挙動が異なる
innerHTMLでは、h1タグが解釈されて、文字が大きく表示される
文字列で食わせると、evalとかfunctionコンストラクタ的な挙動になって結果動くんだけどね。デメリット挙げれば「実行される文字列の内容次第ではセキュリティ上まずい」とか「エスケープ書かなければいけなくなる」とか「呼び出してる変数のスコープが...」とか「タイマーが満たされる都度コンパイルが動く」とかかな。面倒事のが多いから使わない。
追記せず、操作せず、上書きだけできればいいならinnerHTMLで良いんだけれどね。innerHTML触ると該当ノード内部が再パースされる。変更の都度、対象の.childNodesが作り直される。対してinsertAdjacentHTMLは兄弟ノードは保たれる。
つまり、
document.body.innerHTML = '<div id="dv"></div>';
const dv = document.getElementById( "dv" );//これに何かイベント付けたり追記とかするかもよ。
document.body.innerHTML += 'hoge';//ここはinsert(略)で処理するべき
const dv2 = document.getElementById( "dv" );
console.log( dv == dv2 );
これはfalseになる。
innerHTMLに何か流し込みたい場合、HTMLTemplateElement.innerHTMLとか使うと言うのも一手。
Documentのノード操作でinnerHTMLって、全childNodes消したい時くらいしか。
追記せず、操作せず、上書きだけできればいいならinnerHTMLで良いんだけれどね。innerHTML触ると該当ノード内部が再パースされる。変更の都度、対象の.childNodesが作り直される。対してinsertAdjacentHTMLは兄弟ノードは保たれる。
つまり、
document.body.innerHTML = '<div id="dv"></div>';
const dv = document.getElementById( "dv" );//これに何かイベント付けたり追記とかするかもよ。
document.body.innerHTML += 'hoge';//ここはinsert(略)で処理するべき
const dv2 = document.getElementById( "dv" );
console.log( dv == dv2 );
これはfalseになる。
innerHTMLに何か流し込みたい場合、HTMLTemplateElement.innerHTMLとか使うと言うのも一手。
Documentのノード操作でinnerHTMLって、全childNodes消したい時くらいしか。
id="hoge"なエレメントが居るとして。
const hoge = document.querySelector("#hoge");//Domの参照取得しておく
const randamHoge = ()=>{
const r = Math.random();
const str = ( r < 0.5 ? "ほげ" : ( r < 0.8 ? "ふが" : "ぴよ" ) );//乱数から適当に文字列選択。
hoge.textContent = str;//Domに反映
setTimeout( randamHoge , 1000 * 5 );//とりあえず5秒で更新
};
randamHoge();
こんな感じでやれば終わる話じゃないのかい?
これは即席コードで修正した方が良さげな箇所多いけど。
const hoge = document.querySelector("#hoge");//Domの参照取得しておく
const randamHoge = ()=>{
const r = Math.random();
const str = ( r < 0.5 ? "ほげ" : ( r < 0.8 ? "ふが" : "ぴよ" ) );//乱数から適当に文字列選択。
hoge.textContent = str;//Domに反映
setTimeout( randamHoge , 1000 * 5 );//とりあえず5秒で更新
};
randamHoge();
こんな感じでやれば終わる話じゃないのかい?
これは即席コードで修正した方が良さげな箇所多いけど。
あと、こういうのって誰でも直接書き込めると問題ある内容を書き込んじゃうやつもいるから
ログだったり反映前に承認を得るか通知を飛ばすような仕組みを用意もあったほうがいいかも
それができなければ面倒でも1~2人の担当者を経由させたほうが無難
会社の規模とか民度による
ログだったり反映前に承認を得るか通知を飛ばすような仕組みを用意もあったほうがいいかも
それができなければ面倒でも1~2人の担当者を経由させたほうが無難
会社の規模とか民度による
何事もそうだが内容を規制しようというのは非常に難しい
それよりも信頼できる人を厳選して誰が書き込むかの部分で規制したほうが良い
それよりも信頼できる人を厳選して誰が書き込むかの部分で規制したほうが良い
全体リロードするからおかしくなるんだから、fetchで事足りる、
あるいは更新したい部分だけiframeに切り出したら済むのではないだろうか?
あるいは更新したい部分だけiframeに切り出したら済むのではないだろうか?
皆様、レスありがとうございます。
返信頂いた内容への理解が難しく申し訳ないです。
勉強してまいります。
ありがとうございました!!
返信頂いた内容への理解が難しく申し訳ないです。
勉強してまいります。
ありがとうございました!!
xhrもfetchもfileプロトコルは同一生成元ポリシーでエラーになる。
同一生成元ポリシーが、fileプロトコルは全て別のオリジンと見なす、と言う動作になっている。
一応、起動オプション触れば同一生成元ポリシーは抜けられたハズ。
ただ、モジュールスクリプトは確か、起動オプション触るだけだと上手く動かなかった気がする。
ローカルにWebサーバ導入する頃合い、と考えた方が良いかもしれない。
同一生成元ポリシーが、fileプロトコルは全て別のオリジンと見なす、と言う動作になっている。
一応、起動オプション触れば同一生成元ポリシーは抜けられたハズ。
ただ、モジュールスクリプトは確か、起動オプション触るだけだと上手く動かなかった気がする。
ローカルにWebサーバ導入する頃合い、と考えた方が良いかもしれない。
VSCode の拡張機能、open in browser では、ローカルファイル・アクセスだから、CORS 制限あり
file:///C:/Users/Owner/Documents/test.htm
一方、Live Server では、サーバーを立てているから、CORS にならない
http://127.0.0.1:5500/test.htm
同様に、コマンドプロンプト・PowerShell から、
1-liner で、Ruby で作られた遅いウェブサーバー、WEBrick を起動すると、
ruby -run -e httpd . -p 8080
これも、サーバー経由だから、CORS にならない
http://localhost:8080/test.htm
Ruby on Rails では、Node.js のwebpack-dev-server を使っている
file:///C:/Users/Owner/Documents/test.htm
一方、Live Server では、サーバーを立てているから、CORS にならない
http://127.0.0.1:5500/test.htm
同様に、コマンドプロンプト・PowerShell から、
1-liner で、Ruby で作られた遅いウェブサーバー、WEBrick を起動すると、
ruby -run -e httpd . -p 8080
これも、サーバー経由だから、CORS にならない
http://localhost:8080/test.htm
Ruby on Rails では、Node.js のwebpack-dev-server を使っている



類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (1001) - [100%] - 2019/9/22 23:15
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.101 + (1001) - [97%] - 2012/7/16 14:15
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.102 + (1001) - [95%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.123 + (966) - [95%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.122 + (116) - [95%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.100 + (1001) - [95%] - 2012/6/13 22:46
トップメニューへ / →のくす牧場書庫について