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

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

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

    851 = :

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

    852 = :

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

    853 = :

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

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

    854 = :

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

    855 = :

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

    856 = :

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

    857 = :

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

    858 = :

    >>854
    >>832,833,835

    859 = :

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

    860 = :

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

    861 = :

    よ
    そ
    で
    や
    れ

    まで読んだ

    862 = :

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

    863 = :

    質問です

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

    class Factory {
    constructor(){}
    }

    class Shop {
    constructor(){}
    }

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

    864 = :

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

    866 = :

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

    867 = :

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

    868 = :

    >>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で書くにはこうも出来んので

    どうするのが良いのか聞いてみた次第でした
    ありがとうございました

    869 = :

    どういてこましたれ

    870 = :

    ベストプラクティスと言っても魔法の解があるわけじゃないし
    JSはいろんな書き方ができる言語だから
    結局はその要件・コンテキストでどれだけ自然かってことになる

    でもそれってプログラミング関係なくて
    実際の「企業」「工業」「店」の関係に置き換えて想像してみたら
    もし変なことをしていたりムダがあってもすぐ分かるよ

    871 = :

    キモイ

    872 = :

    <ｓｃｒｉｐｔ src="js1.js"></ｓｃｒｉｐｔ>
    <ｓｃｒｉｐｔ src="js2.js"></ｓｃｒｉｐｔ>

    js2からjs1に書いてある関数を実行するにはどうしたらいいでしょうか？
    書き込めないので２バイト文字にしてます

    873 = :

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

    874 = :

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

    875 = :

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

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

    876 = :

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

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

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

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

    877 = :

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

    878 = :

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

    879 = :

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

    880 = :

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

    881 = :

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

    882 = :

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

    883 = :

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

    884 = :

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

    885 = :

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

    886 = :

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

    887 = :

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

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

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

    888 = :

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

    889 = :

    >>887を訂正

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

    890 = :

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

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

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

    891 = :

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

    892 = :

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

    893 = :

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

    894 = :

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

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

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

    895 = :

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

    896 = :

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

    897 = :

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

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

    898 = :

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

    899 = :

    なぜこの場合にカスタムイベントが適切かと言うと
    >>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のカスタムイベントは
    名前空間が使えるからかぶるリスクも少ない

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

    900 = :

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


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

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

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