元スレ+ JavaScript の質問用スレッド vol.132 +

みんなの評価 :
401 = :
>>400
そういうのが広告である以上、広告配信側からの制限も有るので
統合するのは難しいと思ってる。つまりサイト側は広告内容には手を出せない
広告を表示しないようにするからバレるわけで
サイト側は広告を表示したつもりだけど広告内容が無害なものにすり替わる
サイト側は広告内容に手を出せないという前提を満たしている限りどうしようも
例えばポップアップウインドウ。これはポップアップを
出さなくするのではなくポップアップを出すのだけれど、
内容を広告ではなく自動でクローズするHTMLにすり替える
これでポップアップウインドウが開いたかどうかの判定を騙せる
透明広告画像にすり替えるのも同じ理由ね。
サイト側は表示したつもりになっている
402 = :
javascript OFF、iframeも遮断、できればサードパーティURLも遮断、が一番
それをわかってるからchromeとかfirefoxはjavascript切る設定を見えなくしてる
結局javascriptが害悪
403 = :
>>402
その理屈だとHTMLが害悪ってことにならんのか?
404 = :
イベントリスナーに変数渡したいのだがやり方がわからない
セッションストレージに一旦突っ込んでよびだせばいい?
それともグローバル変数にするか?
検索したら
http://qiita.com/rukiadia/items/03aaa8955c0f6576a5e7
が出てきたけど初心者の自分にはやり取りが難しくて結局どうなのかよくわからん。
405 = :
害悪はターゲティング広告や(第三者を介した)アクセス解析
HTMLというよりjavascript, cookie, refererだな
iframeですら呼び出し元がわからなければ広告手段としては劣るようになる
これらが欠けるほどターゲティング広告等は成立しづらくなる
406 = :
>>404
前段のどっちでもいい、それで問題がなければ一向に構わない
後段はjavascriptによって
<button>を
<button data-hoge="渡したい変数の中身">にして
関数でdata-hoge(コード中ではbuttonElement.dataset.hogeになる)を使ってるだけ
要するにjavascript側で保持するんじゃなくてhtmlに保持させる格好
これでもいい
408 = :
>>404
のコメ欄より
addEventListener を使用している場合は、第二引数で handleEvent プロパティを持つオブジェクトを指定して下さい。
document.querySelector('.jscBtn').addEventListener('click', {name: 'my name', handleEvent: function handleEvent (event) {
console.log(this.name); // "my name"
}}, false);
409 = :
>>405
害悪は派手な広告であって
ターゲティングとかはどうでもいいでしょ
410 = :
>>409
見た目派手すぎる広告をどうにかしたいだけだったら
アドブロックブロック対策的には
広告のサイズをwidth: 10px !important; overflow: hidden; とかするだけで完了すんじゃね
要素消してない、隠してない、srcset属性変わらない、つまり検知できない
411 = :
>>409
どうでもいいなら
ターゲティング広告の法規制が議論されたり対策が進められたり
Google Analyticsが違法認定されたり、なんてことは起きないはずだからな
412 = :
>>408
そういやそういう仕様があったなw
jQueryで書くとこうなる。DOM API作ってるやつ
センスなさすぎだろう
$('.jscBtn').on('click', {name: 'my name'}, function(event) {
console(event.data.name); // "my name"
});
414 = :
× console(event.data.name); // "my name"
○ console.log(event.data.name); // "my name"
>>404
リンク先読んで頭痛くなってきた
なんでこいつらこんな馬鹿なやり取りしてるんだ?
あんたが初心者だから難しくてわからないんじゃない。
リンク先の奴らが初心者で試行錯誤してるから、それ見てもわからないのは当たり前
まずセッションストレージはたかがイベントリスナーに変数を渡す程度では重すぎる
グローバル変数も、どこで書き換えられるか分からんのだから使ったらダメ
>>408のようにaddEventListenerの機能に助けてもらうのもありだけど
それを使わないとするなら、最初に出るべきコードはこれだろう
var handler = (function(data) {
return function() {
console.log(data.name);
}
}({name: 'my name'}));
なれないと見にくいだろうけど↑は関数(イベントリスナー)を返す無名関数をすぐに実行する書き方
その関数に変数を紐づけているという形
document.querySelector('.jscBtn').addEventListener('click', handler, false);
415 = :
というかタイトルが「引数を渡す」で???ってなる
416 = :
>>413
その書き方はJavaScriptっぽくないからね
何故かと言うと、その書き方は(昔の?)Javaのように
引数に関数を使用できない言語のための書き方
(DOM APIはJavaScriptだけの仕様ではないことに注意)
引数に関数を渡せないから、代わりに特別なメソッドを用意したオブジェクトを渡す
擬似言語で書くならば、こんな使い方を想定した仕様
class MyHandler implements Handler {
constructor(data) {
this.data = data
}
override handleEvent() {
console.log(this.data.name)
}
}
var handler = new MyHandler({name: 'my name'})
document.querySelector('.jscBtn').addEventListener('click', handler, false);
418 = :
>>413
JavaScriptは、ハッシュもオブジェクト(Object型クラスのインスタンス)なので
>>416の擬似コードに比べれば、>>408のように簡潔に書けるけど
> 名前付き引数でhandleEventに関数いれればできるのかあ。
解釈としては、イベントハンドラ関数の代わりに
イベントハンドラ関数が定義されているオブジェクトを渡す
と考えたほうが良いだろう
419 = :
そもそもイベントハンドラに何かを渡したいという設計が間違っている
そんなことをするとただ複雑になっていくのみ
イベントはイベントでただの一連の処理を継続するトリガーと考えるべき
つまりPromiseだとかObservableを使って抽象化する
421 = :
痛いな
422 = :
バグのほとんどは、設計から生じる
素人は思いつきだけで、奇妙な設計をするから、バグる。
よく使われる・普遍的な、設計・デザインパターンじゃない
特に、素人が好きなのは、状態・外部に依存すること。
関数を抜けた後に、何かの状態を保存したがる。
これがダメ
理想的なのは、状態を持たない、関数型プログラミング
423 = :
>>404のそれぞれと>>408と>>414は
どれが普遍的でどれが奇妙ですか
424 = :
jQuery使っておけ。多くのユースケースでベストな方法を用意してる
$('.jscBtn').on('click', {name: 'my name'}, function(event) {
console.log(event.data.name); // "my name"
});
426 = :
>>422
そうはいっても素人は良い設計なんかわからないからね。
手本が必要。
だからよく設計されたライブラリを使ってみるのが良い。
jQueryとか
427 = :
しつけー自演だな。ライブラリスレじゃねーんだよボケ。
あらゆる質問についてそれ用のライブラリつかえばいいよってのは言語スレで出す回答じゃねーんだよボケ。
428 = :
え?自演じゃないよ。
単にライブラリの話をしてるだけ
429 = :
じゃあスレ違いだな。
ライブラリスレもjQueryスレもあるし。
430 = :
ここでjQueryに関連する話が出たら、
そりゃここでもするよ
ここでブラウザの話がでたら
ブラウザの話するでしょ?
431 = :
自分で出しといて出たらじゃないだろ白々しい
433 = :
>>417が気になるんだけど
これどっちが正しいの
434 = :
JSで何らかのデータを生成しても、
JSはセキュリティ上ユーザのPC上にそれを「ファイルとして」データを保存することはできなくなってると理解しています。
でもダウンロードでファイルを保存できるのだから
JSで生成したデータを一旦サーバに送ってサーバ上でファイルにして
それをクライアント側で改めてダウンロードするようにすればファイルとしてデータを保存できるってことですか?
そこで質問なのですが
クライアント側でサーバを介せずに、ユーザスクリプトで生成したデータを
ダウンロードする操作を擬似的に行って
ファイルに保存することってできないのですか?
ーー
まだJSはじめて間もなくてものすごく初歩的で頓珍漢な質問かもしれませんが、
勘違いしてるとおもうとこあったらつっこんでくさい。
435 = :
>>434
できるよ。
ちょっとアイツが書くから
まっといて
437 = :
それはセッションストレージよりかなり軽いってこと?
438 = :
>>436
こういうことだな
var originalData = 'hoge';
// case2: var originalData = ['hoge'];
// case3: var originalData = {'name':'hoge'};
var handler = (function(recievedData) {
return function() {
console.log(recievedData); // 'hoge'
// case2: console.log(recievedData[0]); // 'fuga'
// case3: console.log(recievedData.name); // 'fuga'
}
}(originalData));
document.querySelector('.jscBtn').addEventListener('click', handler, false);
originalData = 'fuga';
// case2: originalData[0] = 'fuga';
// case3: originalData.name = 'fuga';
値渡しされる内容の変数だと、外部の変更を受けず、
逆に言えば外部での変更を反映させたいと思っても反映させられない
// イベントハンドラ内部のconsole.logを再代入にしてどうすんだ
参照渡しされる内容の変数だと、その変数を参照できれば変更されうる
MyApp.somePropertyみたいな
グローバル変数を使うかどうかは単にその蓋然性の多寡に過ぎない
ついでにstorageは正直ちょっとやそっとじゃ体感できない差だと思うが
440 = :
> ついでにstorageは正直ちょっとやそっとじゃ体感できない差だと思うが
速度が問題なんじゃない。適してない道具を使うなということ
セッションストレージは情報を永続化させるもので
用途に有ってない道具を無理やり使うと想定外のバグを引き起こす
441 = :
>>440
> 速度が問題なんじゃない。
> まずセッションストレージはたかがイベントリスナーに変数を渡す程度では重すぎる
言ってることが変わってる
442 = :
重いっていうのは速度だけの話じゃない
無駄全般の話しだ
メモリも食うしストレージも食う
読み書きするコードも無駄だろう
443 = :
日本語の使い方がおかしい
わざと曖昧な言葉使ってののか
適当なのかしらんけど
プログラミング言語以前に日本語からちゃんとしたほうがいいわ
セッションストレージが永続ってのもしっくりこんし
重いの範囲も広く使いすぎ
444 = :
言うに事欠いてどこにケチ付けてんだワロタw
計算機科学用語のpersistantの訳語だろうがw
もしかして永久に続かないからおかしいもん!とか思ったのかな?アホスwww
訳語が日本語としておかしいのは「仮想」とか「束縛」とかもそうだと思うが。数学用語もそう。
ある文脈で通じるお約束でそもそものそこにケチ付けてもしょうがないだろ。
どうしてもやりたいなら言語学板ででもやれば?w
446 = :
本題スルーすごいですね
447 = :
ソフトウェアエンジニアリングの世界で
永続とか重いとか普通に使うだろ初心者かよ
448 = :
persistentはIT分野(Web関係では特に)
どっちかっていうと「持続的」じゃないか?
切るまでは持続するってことでpersistent connectionとか
永続はどちらかといえばpermanentな気がする
449 = :
>>448
持続ではなく永続であってる
450 = :
本題スルーで有耶無耶で草



類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.102 + (1001) - [97%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
トップメニューへ / →のくす牧場書庫について