私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.144 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>95
>JavaScriptの常識からすると、イベントハンドラの中のthisは$aだと思うかもしれない
いや、ハンドラのレシーバが$aなわけじゃないんだからそう思う人は少ないだろ。
jQueryが通常のイベントハンドラと同じ動作をするという結論はいいとして。
>JavaScriptの常識からすると、イベントハンドラの中のthisは$aだと思うかもしれない
いや、ハンドラのレシーバが$aなわけじゃないんだからそう思う人は少ないだろ。
jQueryが通常のイベントハンドラと同じ動作をするという結論はいいとして。
相変わらず、自己学習意欲のないいい加減な質問者ばかりだな
自ら学ぶスレの名が泣いてる
自ら学ぶスレの名が泣いてる
質問が抽象的でわからん!とか言う人一定数いるみたいだけど
アスペ的な人なのか、経験が浅くてエスパーできない人かじゃないの
大抵の質問は「あー、あのこと言ってるのね」ってわかると思うけど
回答して仮にそれで質問者に「そうじゃないんです」と言われたところで
客観的にみて知的活動に変わりなくスレにとってはプラスにしかならないでしょ。
それ以降質問者を責め立てるのは、間違ったことを恥ずかしいと思っていて
スレにとって何の得にもならない名誉挽回をしたいからだよな
アスペ的な人なのか、経験が浅くてエスパーできない人かじゃないの
大抵の質問は「あー、あのこと言ってるのね」ってわかると思うけど
回答して仮にそれで質問者に「そうじゃないんです」と言われたところで
客観的にみて知的活動に変わりなくスレにとってはプラスにしかならないでしょ。
それ以降質問者を責め立てるのは、間違ったことを恥ずかしいと思っていて
スレにとって何の得にもならない名誉挽回をしたいからだよな
>>105
ここは右も左も分からない初学者のオムツを替えてあげるスレでは無いから
自立した自ら学ぶ事ができる人がどうしても行き詰まったときに
具体的に質問してヒントを貰いに来る場所だから
そこんとこ勘違いしないように
ここは右も左も分からない初学者のオムツを替えてあげるスレでは無いから
自立した自ら学ぶ事ができる人がどうしても行き詰まったときに
具体的に質問してヒントを貰いに来る場所だから
そこんとこ勘違いしないように
>>105
質問者は努力放棄、回答者だけが努力するスレだと思ってるの?
質問者は努力放棄、回答者だけが努力するスレだと思ってるの?
別にエスパーしてあげる回答者がいてもいいし
こき下ろす回答者がいてもいいだろ
JSとはすなわち言語なのだから
赤ちゃんのときにどうやって日本語を覚えたのかを思い出せ
社畜もいれば言語学者様もいる
雑音も含めた様々な情報のシャワーを浴びることで
徐々に物事の特徴量を抽出して分かるようになっていくものだろ
むしろそのためにわざわざこんな混沌とした場所に質問しに来てるのだろ
スレがプラスである必要はないし住民にその努力義務は一切無い
質問者が自分にとってプラスのように情報を汲み取ればいい
こき下ろす回答者がいてもいいだろ
JSとはすなわち言語なのだから
赤ちゃんのときにどうやって日本語を覚えたのかを思い出せ
社畜もいれば言語学者様もいる
雑音も含めた様々な情報のシャワーを浴びることで
徐々に物事の特徴量を抽出して分かるようになっていくものだろ
むしろそのためにわざわざこんな混沌とした場所に質問しに来てるのだろ
スレがプラスである必要はないし住民にその努力義務は一切無い
質問者が自分にとってプラスのように情報を汲み取ればいい
ライオンが崖から落とすような、荒波に揉まれる日本語学習過程を経ている人はそうそういない
>>109
俺が言いたいのはどんな質問・どんな回答をしても構わない
自由にさせとけということではない
全うで良さそうに見える回答だって間違いを多分に含んでるかもしれないし
狂人の極論的な回答でもそれと対抗する回答と合わせて読めばバランスが取れて
幅広い視野での深い考えを得られるかもしれない
結局回答者の発言の何を汲み取って自分の物にするかは質問者の責任であるし
一方回答者には質問者や場の流れに必ずしも従わず
自分で何を汲み取ってほしいかを決めて発言する程度の権利はある
質問の仕方や姿勢が悪いと注意することだって
質問者は回答者が解決してくれることを期待してこのスレに来るな
回答者と対等とまではいかなくても十分意見をぶつけ合って自分で考えて解決できるくらいまで
勉強して質問を練ってから来いという激励の回答だろう
実際本当のところそうであろうとなかろうとそう捉えて自ら成長できないような質問者は
教えてあげる価値も無いと言われても思われても仕方がない
JSは自分で考えて自分で正解を見つけていかないといけない言語であるし
単純労働者、悪ければ宿題を抱えた学生よりもWeb技術に深い洞察を持って
将来Webを発展させるかもしれない人物に時間とリソースを割いて親身に教えてあげたいと思うのも自然だろう
俺が言いたいのはどんな質問・どんな回答をしても構わない
自由にさせとけということではない
全うで良さそうに見える回答だって間違いを多分に含んでるかもしれないし
狂人の極論的な回答でもそれと対抗する回答と合わせて読めばバランスが取れて
幅広い視野での深い考えを得られるかもしれない
結局回答者の発言の何を汲み取って自分の物にするかは質問者の責任であるし
一方回答者には質問者や場の流れに必ずしも従わず
自分で何を汲み取ってほしいかを決めて発言する程度の権利はある
質問の仕方や姿勢が悪いと注意することだって
質問者は回答者が解決してくれることを期待してこのスレに来るな
回答者と対等とまではいかなくても十分意見をぶつけ合って自分で考えて解決できるくらいまで
勉強して質問を練ってから来いという激励の回答だろう
実際本当のところそうであろうとなかろうとそう捉えて自ら成長できないような質問者は
教えてあげる価値も無いと言われても思われても仕方がない
JSは自分で考えて自分で正解を見つけていかないといけない言語であるし
単純労働者、悪ければ宿題を抱えた学生よりもWeb技術に深い洞察を持って
将来Webを発展させるかもしれない人物に時間とリソースを割いて親身に教えてあげたいと思うのも自然だろう
>>105,108,111
意見が分岐しすぎて主張に一貫性がない
意見が分岐しすぎて主張に一貫性がない
>>111
簡潔に
簡潔に
検索で10件ほど調べたのですがアロー関数のthisが何を指すのか分かりませんでした
通常のJavaScriptのthisは親オブジェクトやbind/callで指定したオブジェクトやnewで生成したオブジェクトを指しますが
アロー関数のthisは必ずwindowオブジェクトを指すわけではないですよね?
通常のJavaScriptのthisは親オブジェクトやbind/callで指定したオブジェクトやnewで生成したオブジェクトを指しますが
アロー関数のthisは必ずwindowオブジェクトを指すわけではないですよね?
JavaScript のthis は、ネストすると、window を指してしまうので皆困っていた。
bind を使うとか、 that に代入する必要がある
それが、jQuery などでは便利
アローは、レキシカル・構文スコープ
bind を使うとか、 that に代入する必要がある
それが、jQuery などでは便利
アローは、レキシカル・構文スコープ
>>115
アローじゃない関数のthisはわかってんだよね?
アロー関数はthisに関与しなくなったんだよ
束縛しない
だから、アロー関数の中でのthisは
そのアロー関数が書かれたスコープのthisがそのまま参照される
アローじゃない関数のthisはわかってんだよね?
アロー関数はthisに関与しなくなったんだよ
束縛しない
だから、アロー関数の中でのthisは
そのアロー関数が書かれたスコープのthisがそのまま参照される
JavaScript のthis は、ネストすると、window を指してしまうので皆困っていたから、
検索すれば、説明は一杯あると思う
検索すれば、説明は一杯あると思う
>>113
それらが同一人物に見えるのならお前病気だぞ
それらが同一人物に見えるのならお前病気だぞ
>>119
アロー関数による実行コンテキスト上の環境レコードはthisを持たないし
thisキーワードによるレコードサーチにも引っかからない様になっている
一方アローでないレキシカルな関数コンテキストでは必ず引っかかる
他はグローバルな環境レコードでは必ず引っかかるが、その他の環境レコードでは引っかからない
よってレキシカルな関数の環境レコードをL、アロー関数の環境レコードをAとしたとき、
L内スコープでthisが参照されると引っかかるのはその時の実行コンテキストから辿れる一番近い関数の環境関数レコード、つまりLから必ず探されるが
A内スコープでthisが参照されるとその時の実行コンテキストから辿れる一番近い関数の環境関数レコード、つまりAも引っかからないので
更にその外側から探され、直上のレキシカルな関数の関数レコードかグローバルな関数レコードから探されることになる
アロー関数による実行コンテキスト上の環境レコードはthisを持たないし
thisキーワードによるレコードサーチにも引っかからない様になっている
一方アローでないレキシカルな関数コンテキストでは必ず引っかかる
他はグローバルな環境レコードでは必ず引っかかるが、その他の環境レコードでは引っかからない
よってレキシカルな関数の環境レコードをL、アロー関数の環境レコードをAとしたとき、
L内スコープでthisが参照されると引っかかるのはその時の実行コンテキストから辿れる一番近い関数の環境関数レコード、つまりLから必ず探されるが
A内スコープでthisが参照されるとその時の実行コンテキストから辿れる一番近い関数の環境関数レコード、つまりAも引っかからないので
更にその外側から探され、直上のレキシカルな関数の関数レコードかグローバルな関数レコードから探されることになる
非レキシカルの中に含まれるレキシカルも
非レキシカルに読み替えてくれ
非レキシカルに読み替えてくれ
非レキシカルの中に含まれるレキシカルに含まれるレキシカルも
非レキシカルに読み替えてくれ
非レキシカルに読み替えてくれ
サークルの在庫管理システムを作りたいんです、とりあえずそれが目標であとは勉強しておいたら損は無いかと
>>131
Google の開発者も読むのは、表紙にサイが描いてある、いわゆるサイ本
昔のサイ本は、Ruby の本も書いていた、Flanagan の本。
JavaScript 第6版、2012、David Flanagan
今のサイ本は、
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017
Google の開発者も読むのは、表紙にサイが描いてある、いわゆるサイ本
昔のサイ本は、Ruby の本も書いていた、Flanagan の本。
JavaScript 第6版、2012、David Flanagan
今のサイ本は、
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017
>>134
だったらそんなに長く基礎的な勉強をしていくってわけにもいかないだろうし
Pythonかjavaをバックエンドに、GUI画面をWebで作りたいってことだろうから
サイ本でじっくり勉強するっていうのはあってないかもね
サイ本っていうのはJSに仕様の隅々まで解説するやり込み向けのいわゆる「攻略本」だから
2言語が使えるって言うならとりあえずMDNのJSの再入門でも読めば
JSがどんな言語が薄っすら掴めるはずだから
あとは適当なフレームワーク本買って、物を作った後にサイ本でも読むのが良いかもね
だったらそんなに長く基礎的な勉強をしていくってわけにもいかないだろうし
Pythonかjavaをバックエンドに、GUI画面をWebで作りたいってことだろうから
サイ本でじっくり勉強するっていうのはあってないかもね
サイ本っていうのはJSに仕様の隅々まで解説するやり込み向けのいわゆる「攻略本」だから
2言語が使えるって言うならとりあえずMDNのJSの再入門でも読めば
JSがどんな言語が薄っすら掴めるはずだから
あとは適当なフレームワーク本買って、物を作った後にサイ本でも読むのが良いかもね
つかJSいらなくね
formさえ用意すればいいじゃん
あとはデータからHTMLの組み立てを
pythonでやるかJSでやるかってくらいじゃん
formさえ用意すればいいじゃん
あとはデータからHTMLの組み立てを
pythonでやるかJSでやるかってくらいじゃん
PythonもJavaも初級レベルならJavaScriptでいきなりフロント作ろうなんて辞めとけ
造り手が知識も経験もないんだから、在庫管理程度ならスプレッドシート共有でまず始めること
土台のバックエンド、フロントエンドのスキルが身についてから作成したほうが利用する周りの人たちにも迷惑かからんで良いと思う
造り手が知識も経験もないんだから、在庫管理程度ならスプレッドシート共有でまず始めること
土台のバックエンド、フロントエンドのスキルが身についてから作成したほうが利用する周りの人たちにも迷惑かからんで良いと思う
画像の読み込みに関する某書籍のサンプルコードについて質問です。
//ページのロードが完了した時に発火するイベント
window.addEventListener('load', () => {
// まず最初に画像の読み込みを開始する
imageLoader('./image/color.jpg', (loadedImage) => {
// 引数経由で画像を受け取り変数に代入しておく
image = loadedImage;
});
});
//画像をロードしてコールバック関数にロードした関数を与え呼び出す
function imageLoader(path, callback){
// 画像のインスタンスを生成する
let target = new Image();
console.log(target); //(1) <img src=“./image/color.jp”>とコンソールに表示される
// 画像がロード完了したときの処理を先に記述する
target.addEventListener('load', () => {
// コールバック関数の引数に画像を渡す
callback(target);
});
//画像のロードをするためパスを指定する
target.src = path; //(2)
}
//ページのロードが完了した時に発火するイベント
window.addEventListener('load', () => {
// まず最初に画像の読み込みを開始する
imageLoader('./image/color.jpg', (loadedImage) => {
// 引数経由で画像を受け取り変数に代入しておく
image = loadedImage;
});
});
//画像をロードしてコールバック関数にロードした関数を与え呼び出す
function imageLoader(path, callback){
// 画像のインスタンスを生成する
let target = new Image();
console.log(target); //(1) <img src=“./image/color.jp”>とコンソールに表示される
// 画像がロード完了したときの処理を先に記述する
target.addEventListener('load', () => {
// コールバック関数の引数に画像を渡す
callback(target);
});
//画像のロードをするためパスを指定する
target.src = path; //(2)
}
(1)で <img src=“./image/color.jp”>とコンソールに出力されます。
(1)の1行前で、 console.log(new Image())とすると、
コンソールに<img>と表示されるので(1)も<img>となると思いました。
(1)の時点では(2)で./image/color.jpg を読み込む前なのに、
なぜ<img src=“./image/color.jp”>となるのでしょうか?
(1)の1行前で、 console.log(new Image())とすると、
コンソールに<img>と表示されるので(1)も<img>となると思いました。
(1)の時点では(2)で./image/color.jpg を読み込む前なのに、
なぜ<img src=“./image/color.jp”>となるのでしょうか?
>>143
分かった…
分かった…
Image()
http://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/Image
そんなややこしい書き方をせずに、これじゃダメなのか?
var myImage = new Image(100, 200);
myImage.src = 'picture.jpg';
document.body.appendChild(myImage);
結果
<img width="100" height="200" src="picture.jpg">
http://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/Image
そんなややこしい書き方をせずに、これじゃダメなのか?
var myImage = new Image(100, 200);
myImage.src = 'picture.jpg';
document.body.appendChild(myImage);
結果
<img width="100" height="200" src="picture.jpg">
>>131
web 系なら1年ぐらい、Ruby on Rails で、
VSCode, HTML, CSS/SASS, JavaScript(ES 2015)/TypeScript,
jQuery, Bootstrap, Node.js, npm/yarn, Webpack, Babel, React, Vue.js
他には、実行環境構築。
Linux, WSL, Vagrant, Docker, Kubernetes, CircleCI, シェルスクリプト・PowerShell
Rails チュートリアル日本語版の1つ前のバージョン(Rails 5)が、無料で読める
web 系なら1年ぐらい、Ruby on Rails で、
VSCode, HTML, CSS/SASS, JavaScript(ES 2015)/TypeScript,
jQuery, Bootstrap, Node.js, npm/yarn, Webpack, Babel, React, Vue.js
他には、実行環境構築。
Linux, WSL, Vagrant, Docker, Kubernetes, CircleCI, シェルスクリプト・PowerShell
Rails チュートリアル日本語版の1つ前のバージョン(Rails 5)が、無料で読める
>>145
オブジェクトをconsole.logした場合その時点でスナップショットを取ってるわけではなく変数に代入するのと同じで参照を保持するだけ
ブラウザのコンソールは非同期動作なのでconsole.log直後に対象オブジェクトを操作すると実際に表示する時には中身が変わってる事がある
(2)の所にブレークポイントを設定しておけば<img>と表示される
オブジェクトをconsole.logした場合その時点でスナップショットを取ってるわけではなく変数に代入するのと同じで参照を保持するだけ
ブラウザのコンソールは非同期動作なのでconsole.log直後に対象オブジェクトを操作すると実際に表示する時には中身が変わってる事がある
(2)の所にブレークポイントを設定しておけば<img>と表示される
類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (881) - [97%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.104 + (1001) - [97%] - 2013/1/28 4:00
- + JavaScript の質問用スレッド vol.114 + (1001) - [97%] - 2014/5/3 10:45
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.124 + (1001) - [97%] - 2015/7/16 1:30
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.141 + (1001) - [97%] - 2019/9/22 23:15
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.123 + (1002) - [95%] - 2015/4/27 23: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.121 + (1001) - [95%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [95%] - 2014/11/8 1:15
トップメニューへ / →のくす牧場書庫について