+ JavaScript の質問用スレッド vol.135 +
レス数が950を超えています。1000を超えると書き込みができなくなります。
JavaScript を自ら学ぶ人のための質問スレッドです。
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」だけでなく「意見」を出しても良い。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。
【条件】期待する回答の条件を書いてください。
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける＝荒らしです 本当は解決してないのなら引き続き回答が付く流れになって何が問題なんだ？
何が言いたいんだこいつ、自分自身が何を言ってるのか認識しながら書いてるのか？ >>845
質問した824ですが843は別人です
よって回答は不要です
ただ別の人が興味持って続けたりするのはお好きにどうぞ
実際この問題けっこう面白いです MathJaxについて質問です
サードパーティーによる拡張機能を追加する時は、どういう記法がいいんですか？ >>852
別人だろうが同一人物だろうが関係ないよ
そんなこと考えて返信したりはしないから
コテハンも付けもしないくせにそんなこと言っちゃって変なの >>858
ならなぜコテハンを付けない？？？
>>852が別人アピールをしたところで何がどうなる？
むしろそうでない人>>845が不快になって荒れる原因にしかならんだろ
俺には成りすましよりもずっと荒らしに見えるよ 質問です
class Company {
constructor(){
this.factory = new Factory();
this.shop = new Shop();
}
}
class Factory {
constructor(){}
}
class Shop {
constructor(){}
}
こうしたときに
factoryとshopがお互いを参照するためには
それぞれのインスタンスを作るときに
Companyのthisを渡すので良いのでしょうか？ factory・shop が、お互いを参照するためには、
それよりも1階層上のCompany に、メソッドを定義すればよい
Companyからは、両方へアクセスできるから >>862は引数で渡せば共有可能なことは分かってる
で、要件考察を放棄して「どうすれば良いですか」と最良のコードを聞いてるわけ
典型的なコピペプログラマ >>862
Companyのthisを渡すのが良いね >>863,865,866
あざます
微妙な聞き方ですみませんでした
ベストプラクティスが知りたかったです
コピペプログラマ以前の、まだペーペーでして
class使わずに書いてた時はCompanyの中でこんな感じで
var company = {
constructor : function(){
this.factoty = this.createFactory();
},
createFactory : function(){
var A = this;
var factory = {
constructor : function(){
// ここではAでcompanyが参照できる
}
};
factory.constructor();
return factory;
}
};
コンストラクタ作らずに、直に{}でオプジェクトとして生成してたので
参照に困ることがなかったのですが
これ自体正しいのかわからんし、classで書くにはこうも出来んので
どうするのが良いのか聞いてみた次第でした
ありがとうございました ベストプラクティスと言っても魔法の解があるわけじゃないし
JSはいろんな書き方ができる言語だから
結局はその要件・コンテキストでどれだけ自然かってことになる
でもそれってプログラミング関係なくて
実際の「企業」「工業」「店」の関係に置き換えて想像してみたら
もし変なことをしていたりムダがあってもすぐ分かるよ <ｓｃｒｉｐｔ src="js1.js"></ｓｃｒｉｐｔ>
<ｓｃｒｉｐｔ src="js2.js"></ｓｃｒｉｐｔ>
js2からjs1に書いてある関数を実行するにはどうしたらいいでしょうか？
書き込めないので２バイト文字にしてます それだけだと普通に呼べばいいのではと思うが
特殊な事情があるならそれを書いて欲しい まじすか、リファエラー出てて、スコープは問題ないし
見直してみます >>871,873
今時の奴はマルチポスト先で解決したら、「全てのマルチポスト先で解決方法を書く」程度の礼儀も知らんのか
全員がお前と同じスレを同じタイミングで見ているわけではないんだぞ
解決済みの質問に回答が来てもお前は困らないだろうが、無駄に骨を折らせるだろうが
しかも、スコープの問題ではないといってるし
$(function () {
var a = 1;
});
$(function () {
a; // ReferenceError: a is not defined
});
「それが普通とあれば解決です」といっている辺りからして、コピペコードのネタを探しているだけで理解する気はなさそうだな 質問者本人は「使いたい関数定義義は $(function の外にだすのが普通、と分かったので他はどうでもいいです」な考えだろうから、相手するだけ無駄って感じ
それはそれとして、moduleも解決策の一つだと思うけど、なぜ向こうではカスタムイベント一択の人が必死になってるんだろ jQueryを使えばIEサポートできるよ派が必死になってるのね
カスタムイベント、IEでも使えるんだけどねえ しかし、グローバル変数を敬遠してカスタムイベントを使うのはどうなんだろうな
カスタムイベントにも衝突のリスクがあるという点では問題が内在している事になるのだが
グローバル変数は一つのオブジェクト内にプロパティ定義すれば、汚染変数を一つに集約できるが、カスタムイベントは複数あれば複数定義してやらねばならない
必ずしも、カスタムイベントに優位性はないと思うんだがな カスタムイベントの人、衝突のリスクを真面目に考えてはいないと思うな
衝突を回避しようとすると、module一択になると思う
IEに対応するなら、一つのファイルに連結させるぐらいしか思いつかない カスタムイベントもグローバル変数もページ単位でスコープを持っているので、リスクは同等なんだよな
カスタムイベントに「関数をグローバルに定義する必要も importも使う必要もない」といえる程のメリットはない
衝突のリスクがないmoduleとは比較にならない JS全般に言えることだけど衝突してもすぐ分かるので問題にならない
そんな来年になったら衝突しだしたみたいなことはまず起き得ないのだから > JS全般に言えることだけど衝突してもすぐ分かるので問題にならない
const宣言しておけば、確かにわかるな
だが、カスタムイベントは検知できない 衝突の問題って自分がa.jsとb.jsを両方管理していればそうそう起きないけど、管理外のc.jsを別の人が加えた時点で発生するんだよね
全てのjsファイルを一人が管理しているなら発生しづらいけど、運用の都合上、編集権限がないjsファイルがあるかもしれない
あるいは、自分が今までに関わっていないサイトの機能拡張を依頼されて、そのサイトのグローバル変数に関するドキュメントがないかもしれない
そういう時に衝突しない仕組み(module)だったり、衝突しても自動的にエラーになる(constでグローバルスコープに宣言)のは大きい そんな大真面目にバグの可能性をできるだけ検知しようとしなくてもいいじゃん
どうせjQuery使う程度のサイトなんだからさ
そんなちょっとテストしてみてわからないバグなんてクリティカルじゃないよ
あとで気づいたり指摘されたときになおすので十分で
製作時はそんなこと考えずに適当に思いつくままパパっと作ったのでいいじゃない
どうせjQuery使う程度のサイトなんだからさ >>885
君は>>883って事でいいのかな？
> そんなちょっとテストしてみてわからないバグなんてクリティカルじゃないよ
「すぐに発見できないバグ＝クリティカルなバグじゃない」は通らないよ
むしろ、すぐに発見できない重大なバグの方が恐ろしいので、早期発見に努めたいと俺は思うね
> どうせjQuery使う程度のサイトなんだからさ
あなたが「品質保証しません」なスタイルなら、いいと思うよ(顧客の信用は失うけど)
https://mevius.5ch.net/test/read.cgi/hp/1510321470/643- は何かしらのポリシーをもって、カスタムイベントを推奨していたみたいだからおかしいとは思ったけどね 俺は883じゃないよ
そんなバグを潰したければTSも使うしjQueryは使わないよ
jQueryは何となく作ってそれなりに良いようにやってくれるライブラリなのに
それをちょっとでもマシにしようと考える時点で間違ってるんだよ >>886を訂正
× 君は>>883って事でいいのかな？
〇 君は>>882って事でいいのかな？ >>887
君の中ではこういうこと？
低品質コード: jQueryを使ったコード (jQueryで高品質なコードを作ろうとすることが間違っている)
中品質コード: TSとjQueryを使ったコード
高品質コード: TSを使ったコード
ぶっちゃけ、いずれも同様にJSなので品質が変わるのはおかしい気がするけど、TSに君の頭が最適化されているって事かな
jQueryの内部コード読んでると、共感できない実装が多いので、気持ちは分からんでもないけど 正直、1年前に書いた自分のコードを書き換えようと思っても、細部まで覚えていられる自信はない
直近なら完璧に管理できると思うけど、時間が経てば忘れるので、「自動的にエラーが検知される機構」か「エラーにならない機構」であって欲しいなあ >>875
>>873で一旦落ち着いてるのに何向きになってるんだ >>891
>>873は「スコープは問題ない」と書いているのがおかしい気はする 以下に、複数ファイルに分割して、読み込む方法が書いてある
JavaScriptの設計について考える - 機能ごとに分類する
http://tech.leihauoli.com/post/2014/11/10/program-design-1.html
でも、ファイル数が増えると、読み込みが遅くなるから、
webpack などで連結して、1つのファイルにまとめるのが普通 >>880
> カスタムイベントの人、衝突のリスクを真面目に考えてはいないと思うな
名前空間使えばいいだけだろ つまり、jQueryのカスタムイベントを使う方法は、
名前空間があるから、衝突のリスクも少なく
推奨できる方法というわけか >>889
> jQueryの内部コード読んでると、共感できない実装が多いので、気持ちは分からんでもないけど
共感できない実装を、あなたの実装に変えると
どういうメリットが有るの？ なぜこの場合にカスタムイベントが適切かと言うと
>>871の書き込みだけ見てるとわからんのよ
https://mevius.5ch.net/test/read.cgi/hp/1510321470/635-636
こっちをみないと理解できないだろう
そっちを見るとわかるのが、ex_js_2.js から呼び出しているのが
ex_js_1.js が担当しているDOM要素の初期化処理なんだよ
単一責任原則からするとモジュール（ファイル）が分かれているのだから
担当すべきものは別々でなければならない。
ex_js_1.js が担当している処理の内部実装に依存するのは良くない
本来なら ex_js_1.js で完結させるべきことだろう
だがどうしてもex_js_2.jsから呼ばなければいけないというのならば、
モジュール間の結合度を下げるためにイベントを使うのが適切
module使うのもモジュール間の結合度が高まってるのでなんの解決にもなっていない
カスタムイベントと聞いてDOMのカスタムイベントと同様のことしかできないと
思い込んでいる無知がいそうだが、jQueryのカスタムイベントは
名前空間が使えるからかぶるリスクも少ない
そこまで考慮した上でのレスなんだよ
呼べればいいだろレベルの浅い考えの答えとはわけが違う >>890
> 正直、1年前に書いた自分のコードを書き換えようと思っても、細部まで覚えていられる自信はない
誰でもそう。記憶力に頼って仕事なんてできないし、
そんなものに頼ってはだめ。
だからといってドキュメントをたくさん残せば良いのかと言うと
それも違う。読むものが増えると、その分忘れた記憶を取り戻す時間がかかる
じゃあどうするのかと言うと、結局は読むべきものを減らすということに尽きる
ドキュメントもそうだしコードもそう
プロジェクト依存の知識は、そのプロジェクトから外れると必要なくなる。
つまり忘れる。だからプロジェクトに依存しない知識を使いつつ
より少ないドキュメントやコードで構成しなければいけない
もう分かるね？ どんなにjQueryがなくてもできようが、
jQuery使ったほうがコードが減るなら、jQuery使ったほうが良いってことだよ
もちろんjQueryとTSを使ったほうがより良いだろう
TS単体よりもjQuery使ったほうがプロジェクト固有の知識は必要なくなる それってjQueryのAPIを忘れないよう未来永劫使い続けること前提じゃん
ライブラリにロックインされるのは嫌だわ 未来永劫、jQueryを使ったほうがコードが減るなら
そうした方が良いのでは？ｗ フレームワークにロックインっていうのならわかるが
ライブラリにロックインってよくわからんな
フレームワークは一つの大きな枠組みだから、
外すときは中身が全てばらばらになってしまうが
ライブラリは、中身で使ってるだけだから、
一つづつ中身を置き換えていける
ロックインってほどのものじゃない >>900
> もう分かるね？ どんなにjQueryがなくてもできようが、
> jQuery使ったほうがコードが減るなら、jQuery使ったほうが良いってことだよ
jQueryの内部コードを完全に把握していて、jQueryがバージョンアップする度に更新内容を詳細に知る努力を維持しているならね
根幹のjQueryを他者が完全に把握するのは不可能 > jQueryの内部コードを完全に把握していて、jQueryがバージョンアップする度に更新内容を詳細に知る努力を維持しているならね
そんなこと必要ないのでは？
誰もOSの中身やブラウザの中身なんて完全に把握してないでしょう？
もう少しさ、公平な視線で見れないの？ 読むコード減らすべきおじさん
いい加減自重してほしい…
ここは質問スレなんで
自己主張はブログでも作ってそこでやってください >>906
>>1を読もうね
> ・質問への「答え」だけでなく「意見」を出しても良い。 議論用スレじゃないのに明らかにおかしいね。
荒らしが足したのかな？
次スレ立てるとき消しとくわ。 >>909
じゃあ、自重してほしいというのをやめてほしい ほとんど議論なんだから議論スレ立てて好きにやれば？ phpやrubyと違ってjavascriptは簡単な言語です、
とか言ってる人もいるけど、間違ってると思いませんか >>898
例えばだが
1は他の様々なプロジェクトでも使える基本関数
それを2から呼び出すとか
phpのincludeのように 複数のページにまたがって使えるような定数の集まりや関数など
include的に使いたいとき皆どうしてるんだろう jsの場合、ファイル分けてもあまり意味がないからincludeしなくなったわ
一つのファイルにまとめている。アナリティクスすら一つのファイル >>920
そう
どうせキャッシュから読み出すので速度は問題ない javascriptウルトラ初心者がいきなりvue.jsやっても良いですか >>923
別にいいっちゃいいけどvue.jsはいつも通り、いつの間にか消えて行くパターンだろうなぁって感じ
ただそういう意味では逆に使って置くと良い。あの絶望感は楽しい >>925
vue.jsってあんまり普及してないんですかね？ >>926
一時的に普及はしてるけど、いつもの流行り
多分君みたいな「なんか革新的で凄そう！」って人が使ってしまっている
俺もその昔、jquerymobileっての使ってた。今みたらgithubは二年も更新止まってるわ・・・まぁいいけど
こういうのはある程度やってないと分からない
まぁ時間を無駄にしたくなければjQuery使っておけばok SPAを今の環境でやるには便利だし普及してるとは思う
けど、SPAをもりもり作ってる人ってのがそもそも少ないだろうし
より最適化したものが作られたりUA側の環境が変われば
また変わっていくでしょう >>929
あぁそういう風に受け取ったのか、お前は本当に素人だなｗｗｗ
phpから出力してheadに直接出力してるんだよ >>927
jquerymobile廃れたじゃんふざけやがって >>930
なんでjsスレでphpありきの話してんだよ
ここでなら普通phpなしが前提だろ >>931
まぁ、わざと大袈裟に言った。
アホな事やって周りにまで迷惑掛けてしまったからな
>>932
俺に言われても。
>>933
で、その挙げ句が>>929という発想だろ
ボトルシップでもやってんのか、ありえない
お前みたいなアホがシステムと連携せずにフロントをぐちゃぐちゃにするんだよ
もっと全体を見てくれ PHPでとか言ってるの俺じゃねぇからな
>>916
> 1は他の様々なプロジェクトでも使える基本関数
だからコード見る限りそういう使い方じゃないから
カスタムイベントと言ったんだよ >>936
jQueryはDOM操作用ライブラリ
俺を騙るのはやめろ >>914
Ruby が圧倒的に可読性が高く、各バージョンの互換性も高い。
言語に、include, require もある
>>917
>>893
のリンクにあるような、共通ライブラリにして、先に読み込む。
かつ、2回読み込まない
>>923
初心者は、jQuery から。
Vue.js は無理 electronでアプリ作ったらソース丸見えなの？ >>940
Rubyはマジで勉強しなくて良かったと思ってる
こんなに急速に終わるとは思わなかった rubyなんで終わったん？
なんか便利そうだな〜って思ってる内にフェードアウトしていた 元々Railsのおかげで流行っただけだし、ある種当然の流れともいえる ライブラリの出来の差でpythonに二周差くらいつけられた。
有名な先端のC/C++で書かれたライブラリ(ネイティブ)なんかも大抵Pythonから呼び出すインターフェースを公式で提供されてる。
Rubyだってできるもん！と馬の骨がRubyラッパーを作っても誰もメンテしない始末ｗ
あとディープラーニングなんかはMacでGPUサポートが弱い関係でWindows（やLinux）が主戦場になってるがRubyのコミュニティはWindows蔑視の伝統がありそのツケがまわってきてしまった形ｗ自業自得ｗｗｗ
もうRailsのDSLとしてしか息してない。 >>937
元々それも含まれてます
むしろそれがメインです Rails一発屋「Pythonは機械学習一発屋！！」 >>950
何回も叫ばなくてもわかってるよｗ
Pythonは機械学習一発屋！！！ レス数が950を超えています。1000を超えると書き込みができなくなります。
