のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,603,493人
頁
昨日:no data人
頁
今日:人
頁
最近の注目
人気の最安値情報

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

JavaScript覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

101 = :

浅はかすぎる

102 = :

>>95
>JavaScriptの常識からすると、イベントハンドラの中のthisは$aだと思うかもしれない

いや、ハンドラのレシーバが$aなわけじゃないんだからそう思う人は少ないだろ。
jQueryが通常のイベントハンドラと同じ動作をするという結論はいいとして。

103 = :

相変わらず、自己学習意欲のないいい加減な質問者ばかりだな
自ら学ぶスレの名が泣いてる

104 = :

回答者も学べばいいのに

105 = :

質問が抽象的でわからん！とか言う人一定数いるみたいだけど
アスペ的な人なのか、経験が浅くてエスパーできない人かじゃないの
大抵の質問は「あー、あのこと言ってるのね」ってわかると思うけど
回答して仮にそれで質問者に「そうじゃないんです」と言われたところで
客観的にみて知的活動に変わりなくスレにとってはプラスにしかならないでしょ。
それ以降質問者を責め立てるのは、間違ったことを恥ずかしいと思っていて
スレにとって何の得にもならない名誉挽回をしたいからだよな

106 = :

>>105
ここは右も左も分からない初学者のオムツを替えてあげるスレでは無いから
自立した自ら学ぶ事ができる人がどうしても行き詰まったときに
具体的に質問してヒントを貰いに来る場所だから
そこんとこ勘違いしないように

107 = :

>>105
質問者は努力放棄、回答者だけが努力するスレだと思ってるの？

108 = :

別にエスパーしてあげる回答者がいてもいいし
こき下ろす回答者がいてもいいだろ

JSとはすなわち言語なのだから
赤ちゃんのときにどうやって日本語を覚えたのかを思い出せ

社畜もいれば言語学者様もいる
雑音も含めた様々な情報のシャワーを浴びることで
徐々に物事の特徴量を抽出して分かるようになっていくものだろ

むしろそのためにわざわざこんな混沌とした場所に質問しに来てるのだろ
スレがプラスである必要はないし住民にその努力義務は一切無い
質問者が自分にとってプラスのように情報を汲み取ればいい

109 = :

>>108
母親から何もしつけられなかったの？
質問者が利益を得るためには、何をやってもいい？

110 = :

ライオンが崖から落とすような、荒波に揉まれる日本語学習過程を経ている人はそうそういない

111 = :

>>109
俺が言いたいのはどんな質問・どんな回答をしても構わない
自由にさせとけということではない

全うで良さそうに見える回答だって間違いを多分に含んでるかもしれないし
狂人の極論的な回答でもそれと対抗する回答と合わせて読めばバランスが取れて
幅広い視野での深い考えを得られるかもしれない

結局回答者の発言の何を汲み取って自分の物にするかは質問者の責任であるし
一方回答者には質問者や場の流れに必ずしも従わず
自分で何を汲み取ってほしいかを決めて発言する程度の権利はある

質問の仕方や姿勢が悪いと注意することだって
質問者は回答者が解決してくれることを期待してこのスレに来るな
回答者と対等とまではいかなくても十分意見をぶつけ合って自分で考えて解決できるくらいまで
勉強して質問を練ってから来いという激励の回答だろう

実際本当のところそうであろうとなかろうとそう捉えて自ら成長できないような質問者は
教えてあげる価値も無いと言われても思われても仕方がない

JSは自分で考えて自分で正解を見つけていかないといけない言語であるし
単純労働者、悪ければ宿題を抱えた学生よりもWeb技術に深い洞察を持って
将来Webを発展させるかもしれない人物に時間とリソースを割いて親身に教えてあげたいと思うのも自然だろう

112 = :

>>108
> 赤ちゃんのときにどうやって日本語を覚えたのかを思い出せ

思い出せない。俺が記憶にある最も古いものは幼稚園の頃の記憶だ

113 = :

>>105,108,111
意見が分岐しすぎて主張に一貫性がない

114 = :

>>111
簡潔に

115 = :

検索で10件ほど調べたのですがアロー関数のthisが何を指すのか分かりませんでした
通常のJavaScriptのthisは親オブジェクトやbind/callで指定したオブジェクトやnewで生成したオブジェクトを指しますが
アロー関数のthisは必ずwindowオブジェクトを指すわけではないですよね？

116 = :

>>115
10件見て分からないなら、それ以前の基礎知識が足りてない
切り分けを覚えろ

117 = :

JavaScript のthis は、ネストすると、window を指してしまうので皆困っていた。
bind を使うとか、 that に代入する必要がある

それが、jQuery などでは便利

アローは、レキシカル・構文スコープ

118 = :

>>115
アローじゃない関数のthisはわかってんだよね？

アロー関数はthisに関与しなくなったんだよ
束縛しない

だから、アロー関数の中でのthisは
そのアロー関数が書かれたスコープのthisがそのまま参照される

120 = :

JavaScript のthis は、ネストすると、window を指してしまうので皆困っていたから、

検索すれば、説明は一杯あると思う

122 = :

>>117
ネストしたらwindowになるんじゃなくて
DOM APIの仕様による

123 = :

>>113
それらが同一人物に見えるのならお前病気だぞ

124 = :

>>119
アロー関数による実行コンテキスト上の環境レコードはthisを持たないし
thisキーワードによるレコードサーチにも引っかからない様になっている
一方アローでないレキシカルな関数コンテキストでは必ず引っかかる
他はグローバルな環境レコードでは必ず引っかかるが、その他の環境レコードでは引っかからない

よってレキシカルな関数の環境レコードをL、アロー関数の環境レコードをAとしたとき、
L内スコープでthisが参照されると引っかかるのはその時の実行コンテキストから辿れる一番近い関数の環境関数レコード、つまりLから必ず探されるが
A内スコープでthisが参照されるとその時の実行コンテキストから辿れる一番近い関数の環境関数レコード、つまりAも引っかからないので
更にその外側から探され、直上のレキシカルな関数の関数レコードかグローバルな関数レコードから探されることになる

125 = :

大間違い
レキシカルを全て非レキシカルに読み替えてくれ

126 = :

非レキシカルの中に含まれるレキシカルも
非レキシカルに読み替えてくれ

127 = :

非レキシカルの中に含まれるレキシカルに含まれるレキシカルも
非レキシカルに読み替えてくれ

128 = :

慣れない言葉使って長文書くなって教訓だな

129 = :

長文ドヤ顔マン嫌い

130 = :

このスレくっさ

132 = :

何のために勉強して何ができるようになりたいの？

133 = :

わからないままおわる　そんなのはいやだ！

134 = 131 :

サークルの在庫管理システムを作りたいんです、とりあえずそれが目標であとは勉強しておいたら損は無いかと

136 = :

>>131
Google の開発者も読むのは、表紙にサイが描いてある、いわゆるサイ本

昔のサイ本は、Ruby の本も書いていた、Flanagan の本。
JavaScript 第6版、2012、David Flanagan

今のサイ本は、
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017

137 = :

ダサイタマ本

138 = :

>>134
だったらそんなに長く基礎的な勉強をしていくってわけにもいかないだろうし
Pythonかjavaをバックエンドに、GUI画面をWebで作りたいってことだろうから
サイ本でじっくり勉強するっていうのはあってないかもね
サイ本っていうのはJSに仕様の隅々まで解説するやり込み向けのいわゆる「攻略本」だから

２言語が使えるって言うならとりあえずMDNのJSの再入門でも読めば
JSがどんな言語が薄っすら掴めるはずだから
あとは適当なフレームワーク本買って、物を作った後にサイ本でも読むのが良いかもね

139 = :

つかJSいらなくね
formさえ用意すればいいじゃん
あとはデータからHTMLの組み立てを
pythonでやるかJSでやるかってくらいじゃん

140 :

えらそーに

141 = :

バックエンドで完結させてからjsに手を出せ
順序が違う

143 = :

PythonもJavaも初級レベルならJavaScriptでいきなりフロント作ろうなんて辞めとけ
造り手が知識も経験もないんだから、在庫管理程度ならスプレッドシート共有でまず始めること

土台のバックエンド、フロントエンドのスキルが身についてから作成したほうが利用する周りの人たちにも迷惑かからんで良いと思う

144 = :

画像の読み込みに関する某書籍のサンプルコードについて質問です。

　//ページのロードが完了した時に発火するイベント
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)
}

145 = :

(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”>となるのでしょうか？

146 :

>>143
分かった…

147 = :

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">

150 = :

>>145
オブジェクトをconsole.logした場合その時点でスナップショットを取ってるわけではなく変数に代入するのと同じで参照を保持するだけ
ブラウザのコンソールは非同期動作なのでconsole.log直後に対象オブジェクトを操作すると実際に表示する時には中身が変わってる事がある
(2)の所にブレークポイントを設定しておけば<img>と表示される


←前へ 1 2 3 4 5 6 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド

トップメニューへ / →のくす牧場書庫について