>>847
解決したなら、回答する必要がないからね
本当は解決してないのがバレバレ

本当は解決してないのなら引き続き回答が付く流れになって何が問題なんだ？
何が言いたいんだこいつ、自分自身が何を言ってるのか認識しながら書いてるのか？

>>846
質問した824ですが843は別人です
よって回答は不要です

ただ別の人が興味持って続けたりするのはお好きにどうぞ
実際この問題けっこう面白いです

MathJaxについて質問です
サードパーティーによる拡張機能を追加する時は、どういう記法がいいんですか？

>>833
ライブラリスレで聞けや低脳
JavaScript ライブラリ総合質問所 vol.5
http://mevius.5ch.net/test/read.cgi/hp/1465399470/

>>853
別人だろうが同一人物だろうが関係ないよ
そんなこと考えて返信したりはしないから
コテハンも付けもしないくせにそんなこと言っちゃって変なの

>>856
お前なんか恥ずかしい

>>854
>>832,833,835

>>856
そうでないの（>>846）がいるだろ

>>859
ならなぜコテハンを付けない？？？
>>853が別人アピールをしたところで何がどうなる？
むしろそうでない人>>846が不快になって荒れる原因にしかならんだろ
俺には成りすましよりもずっと荒らしに見えるよ

よ
そ
で
や
れ

まで読んだ

後からコテハンつけてもな

質問です

class Company {
constructor(){
this.factory = new Factory();
this.shop = new Shop();
}
}

class Factory {
constructor(){}
}

class Shop {
constructor(){}
}

こうしたときに
factoryとshopがお互いを参照するためには
それぞれのインスタンスを作るときに
Companyのthisを渡すので良いのでしょうか？

>>863
良いか悪いかはあなたが判断すること

factory・shop が、お互いを参照するためには、
それよりも1階層上のCompany に、メソッドを定義すればよい

Companyからは、両方へアクセスできるから

>>863は引数で渡せば共有可能なことは分かってる
で、要件考察を放棄して「どうすれば良いですか」と最良のコードを聞いてるわけ
典型的なコピペプログラマ

>>863
Companyのthisを渡すのが良いね

>>864,866,867
あざます
微妙な聞き方ですみませんでした
ベストプラクティスが知りたかったです
コピペプログラマ以前の、まだペーペーでして

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に書いてある関数を実行するにはどうしたらいいでしょうか？
書き込めないので２バイト文字にしてます

それだけだと普通に呼べばいいのではと思うが
特殊な事情があるならそれを書いて欲しい

まじすか、リファエラー出てて、スコープは問題ないし
見直してみます

>>872
IE11をサポートしなくて良いなら、
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/import

http://mevius.5ch.net/test/read.cgi/hp/1510321470/635 と同じ質問だが、マルチポストか？
内容的にはライブラリ関係ないので、、こっちですべきだが

>>872,874
今時の奴はマルチポスト先で解決したら、「全てのマルチポスト先で解決方法を書く」程度の礼儀も知らんのか
全員がお前と同じスレを同じタイミングで見ているわけではないんだぞ
解決済みの質問に回答が来てもお前は困らないだろうが、無駄に骨を折らせるだろうが

しかも、スコープの問題ではないといってるし

$(function () {
　var a = 1;
});
$(function () {
　a; // ReferenceError: a is not defined
});

「それが普通とあれば解決です」といっている辺りからして、コピペコードのネタを探しているだけで理解する気はなさそうだな

質問者本人は「使いたい関数定義義は $(function の外にだすのが普通、と分かったので他はどうでもいいです」な考えだろうから、相手するだけ無駄って感じ
それはそれとして、moduleも解決策の一つだと思うけど、なぜ向こうではカスタムイベント一択の人が必死になってるんだろ

それはIEで動かないから。

jQueryを使えばIEサポートできるよ派が必死になってるのね
カスタムイベント、IEでも使えるんだけどねえ

しかし、グローバル変数を敬遠してカスタムイベントを使うのはどうなんだろうな
カスタムイベントにも衝突のリスクがあるという点では問題が内在している事になるのだが
グローバル変数は一つのオブジェクト内にプロパティ定義すれば、汚染変数を一つに集約できるが、カスタムイベントは複数あれば複数定義してやらねばならない
必ずしも、カスタムイベントに優位性はないと思うんだがな

カスタムイベントの人、衝突のリスクを真面目に考えてはいないと思うな
衝突を回避しようとすると、module一択になると思う
IEに対応するなら、一つのファイルに連結させるぐらいしか思いつかない

カスタムイベントもグローバル変数もページ単位でスコープを持っているので、リスクは同等なんだよな
カスタムイベントに「関数をグローバルに定義する必要も importも使う必要もない」といえる程のメリットはない
衝突のリスクがないmoduleとは比較にならない

JS全般に言えることだけど衝突してもすぐ分かるので問題にならない
そんな来年になったら衝突しだしたみたいなことはまず起き得ないのだから

> JS全般に言えることだけど衝突してもすぐ分かるので問題にならない
const宣言しておけば、確かにわかるな
だが、カスタムイベントは検知できない

衝突の問題って自分がa.jsとb.jsを両方管理していればそうそう起きないけど、管理外のc.jsを別の人が加えた時点で発生するんだよね
全てのjsファイルを一人が管理しているなら発生しづらいけど、運用の都合上、編集権限がないjsファイルがあるかもしれない
あるいは、自分が今までに関わっていないサイトの機能拡張を依頼されて、そのサイトのグローバル変数に関するドキュメントがないかもしれない
そういう時に衝突しない仕組み(module)だったり、衝突しても自動的にエラーになる(constでグローバルスコープに宣言)のは大きい

そんな大真面目にバグの可能性をできるだけ検知しようとしなくてもいいじゃん
どうせjQuery使う程度のサイトなんだからさ
そんなちょっとテストしてみてわからないバグなんてクリティカルじゃないよ
あとで気づいたり指摘されたときになおすので十分で
製作時はそんなこと考えずに適当に思いつくままパパっと作ったのでいいじゃない
どうせjQuery使う程度のサイトなんだからさ

>>886
君は>>884って事でいいのかな？

> そんなちょっとテストしてみてわからないバグなんてクリティカルじゃないよ
「すぐに発見できないバグ＝クリティカルなバグじゃない」は通らないよ
むしろ、すぐに発見できない重大なバグの方が恐ろしいので、早期発見に努めたいと俺は思うね

> どうせjQuery使う程度のサイトなんだからさ
あなたが「品質保証しません」なスタイルなら、いいと思うよ(顧客の信用は失うけど)
http://mevius.5ch.net/test/read.cgi/hp/1510321470/643- は何かしらのポリシーをもって、カスタムイベントを推奨していたみたいだからおかしいとは思ったけどね

俺は883じゃないよ
そんなバグを潰したければTSも使うしjQueryは使わないよ
jQueryは何となく作ってそれなりに良いようにやってくれるライブラリなのに
それをちょっとでもマシにしようと考える時点で間違ってるんだよ

>>887を訂正

×　君は>>884って事でいいのかな？
〇　君は>>883って事でいいのかな？

>>888
君の中ではこういうこと？

低品質コード: jQueryを使ったコード (jQueryで高品質なコードを作ろうとすることが間違っている)
中品質コード: TSとjQueryを使ったコード
高品質コード: TSを使ったコード

ぶっちゃけ、いずれも同様にJSなので品質が変わるのはおかしい気がするけど、TSに君の頭が最適化されているって事かな
jQueryの内部コード読んでると、共感できない実装が多いので、気持ちは分からんでもないけど

正直、1年前に書いた自分のコードを書き換えようと思っても、細部まで覚えていられる自信はない
直近なら完璧に管理できると思うけど、時間が経てば忘れるので、「自動的にエラーが検知される機構」か「エラーにならない機構」であって欲しいなあ

>>876
>>874で一旦落ち着いてるのに何向きになってるんだ

>>892
>>874は「スコープは問題ない」と書いているのがおかしい気はする

以下に、複数ファイルに分割して、読み込む方法が書いてある

JavaScriptの設計について考える - 機能ごとに分類する
http://tech.leihauoli.com/post/2014/11/10/program-design-1.html

でも、ファイル数が増えると、読み込みが遅くなるから、
webpack などで連結して、1つのファイルにまとめるのが普通

>>881
> カスタムイベントの人、衝突のリスクを真面目に考えてはいないと思うな
名前空間使えばいいだけだろ

つまり、jQueryのカスタムイベントを使う方法は、
名前空間があるから、衝突のリスクも少なく
推奨できる方法というわけか

>>890
> jQueryの内部コード読んでると、共感できない実装が多いので、気持ちは分からんでもないけど

共感できない実装を、あなたの実装に変えると
どういうメリットが有るの？

共感できるようになるというメリットがある

なぜこの場合にカスタムイベントが適切かと言うと
>>872の書き込みだけ見てるとわからんのよ

http://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のカスタムイベントは
名前空間が使えるからかぶるリスクも少ない

そこまで考慮した上でのレスなんだよ
呼べればいいだろレベルの浅い考えの答えとはわけが違う

>>898
それだけしかないという意味でいい？