+ JavaScript の質問用スレッド vol.126 + [転載禁止]©2ch.net
JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。
■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。 https://liveweave.com/6IlWRJ
JavaScriptでスプリッターを作っているのですが、左右を分割するスプリッターをマウスで動かしても、マウスの位置とずれてしまいます。
どのように修正すればいいのでしょうか。 >>423
良いか悪いかはさておき
考え方としては
そのコードを、どのくらいの範囲で共有するのか
ってのを基準に考えたらいいと思う
自分だけなら好きにすればいいし
身内だけなら話して決めればいいし
広範囲なら世間一般の流れに合わせるべき
みたいな >>417
すんごい前だけど
似たようなことを頑張ったことある
でもやっぱり
select要素が開いているかどうかを判定出来ないので
原理的に出来なくて
select要素のように振る舞うものを
手作りするのが早かったです 今動作しているのがサーバ上（https//:～）なのかローカル（file:///C:～）なのか区別する必要性が出てきました。
locationで取得する以外にいい方法ありますか？
区別さえ確実にできれば得られる値は（true/falseなど）なんでもいいです。 >>427
window.location.protocolを見れば良いんじゃないかな
httpかhttpsなら、みたいな var people = [{
"id" : "ID1", "name" : "人物1", "room" : "1"
}{
"id" : "ID2", "name" : "人物2", "room" : "2"
}]
var select_tag = document.getELementById("my_select");
for ( var i = 0; i < people.length; i++ ) {
var option = document.createElement("option");
option.value = people[i].id;
option.innerText = people[i].name;
my_select.append(option);
}
こういう感じの select を設置して、option が選択された時に、選択された人物の room を取得するにはどうすればよいのでしょうか？ >>429
select_tag.selectedIndexに
今選ばれてるoptionが何番目かが入ってるから
select_tagのchangeイベントにフックして
その数字を拾って、people[数字].idを参照したらいいよ ごめん間違えた
people[数字].roomだった
すまんこ >>431
出来ました！ありがとうございます！
select_tag.addEventListener("change", (e) =>{
let i = select_tag.selectedIndex;
alert(people[i].room);
}); 今のJavascriptファイルの管理って、どれがスタンダードになっていますか？
webpackはだいぶ古いんですよね？ >>435
そもそもwebpackは管理するものではないのだが…
バンドルツールのシェアのことなら
webpackがまだまだ支配的だと思う
viteとturbopackが頑張り始めたところだけど
この辺はJSだけの話ではなくなるので
なんとも言い難い感じ パッケージの管理のことなら
npm一択な気がする
ツール自体はyarnとかpnpmとか色々あるけど Ruby on Rails では、npm は遅いから、yarn を使う
Rails 7 からは脱webpack で、
Import Maps で、CDN から直接インポートする
HTTP/2 が普及して、バンドル・Node.js が不要になった。
バンドル不要のTailwind を使う
バンドルするなら、esbuild, rollup, webpack を使う。
esbuildならCSS プロセッサとして、Bootstrap を使う >>436-438
バンドルツールのことです。
webpack→viteと学んでいるのですが、
正直複雑すぎてついていけてません・・・
特にviteでバンドルして生成されるファイル構成に
どうしても違和感があって、勉強を中断しています。
ChatGPTに聞くとviteのようにハッシュ値で変換した
ファイル名にすることでセキュリティが高まるそうですが、
元のファイル名から変わるのに違和感を覚えます Vite は、Vue.js の作者だったか？
Vueも、Vue 3 で人気が無くなって、React 一色になった
2, 3年前は、Vueが転職で有利だったのに、
今は、React, TypeScript
ブラウザのキャッシュ対策として、
ファイル名はハッシュ値の方が良い
ファイルを更新するとハッシュ値も変わるから、
古いファイルがキャッシュされない
どうせ配布用のファイル名だから、開発用には関係ない Viteの書き出すファイル名はconfigで変更できたような >>439
元のファイル名がわかることに
どこまで意味があるのか？って話じゃね？
たとえばbabel+webpackだって
トランスパイル、パッキング後は
部分的にバイナリになったりするわけで
要するに人間の読めるものではなくなる
つまり、ファイル名がハッシュ化されなくても
人間が得られるものはせいぜい
そのファイルがなんなのかの想像がつきやすい
程度のこと
ファイル名が中身と全く関係ない
なんてこともよくあるとは言わんまでも
一定数わけで、となるとデプロイされるファイル名には
それほど大きな意味がない
ってことが多いのではないかな Vite は、Ruby on Rails をコピーしたのかな？
foreman, webpack-dev-server で、hot reload するみたいな？
ファイルを修正したら、即ブラウザに反映されるとか
開発時には、CSS をコンパイルせず、
動的にスタイルを当てているだけとか Viteの使い方がやっとわかりました！
ファイル名が変わるのは許容します
これから少しずつ学んでいきます
みなさんアドバイスありがとうございました 実際にサイトをサーバーに公開することになったらファイル名のうしろにつくハッシュ値の恩恵がわかると思うよ
キャッシュのこと気にしなくていいからね アプリで登録されたユーザー情報をWEBアプリで管理するということで
制作会社から管理画面のラフが送られてきたのですが、
ある箇所で、アプリで登録したユーザーのメアドをプルダウンで選択するんだそうです。 続き
「今はテストなので登録数は20-30件ですが、仮に50,000人とかになったら？」
と尋ねたら「プルダウンされた50,000行の中から目視で探す」んだそうで
それが正しいやり方だと言い張って平行線です。
どう論破したら良いでしょう？ 長文の投稿ができなかったので分割にて投稿させていただきました。
何卒よろしくお願いいたします。 論破もくそもねーわ
変更したいなら変更すればいいじゃん
これ100％発注側の問題だからな まあそうだわな
客あるあるだけど
欲しいもの、必要なものをちゃんと説明できないのは
本当によくあることで
だいたいの不幸や不具合はそこが起点になるんだ
作る側もそれはわかってるから
出来るだけ真意を聞き出そうとはするんだけど
で、平行線になってるってことは
説明不足のまま、もう作っちゃったからでしょ
ちゃんと追加料金払って変更してもらいなさいな 今後のために教えてください。
「アプリで登録されたユーザー情報」を「WEBアプリで管理したい」
という話し合いはしていましたがプルダウンにする/しないという
話し合いは確かにしていませんでした。
また自分は普段別の領域で制作業務を行なっており
アプリに関して無知ですが制作系はそこそこのクライアントをこなしています。
アプリの業界では特に話し合いを詰めないと
この様な非常識な仕様がポンと出てくるものなのでしょうか？
自分がいる業界ならば二度と仕事は振られないと思います。
（考えれば使いづらいのは話し合うまでもなくわかるでしょう、それがわからないのなら次はない、という感じ） >>452
>「アプリで登録されたユーザー情報」を「WEBアプリで管理したい」という話し合い
いやいやざっくりすぎやろｗ
項目すら詰めてないとか非常識にもほどがあるんだけど >この様な非常識な仕様がポンと出てくるものなのでしょうか？
どういう会社にどういう条件でいくら支払うか次第
海外とかにユルユルな発注を低予算でやるとそれなりによくあること
さすがに5万件になったら使いづらいというのは受注側も百も承知
それが理解できないような人間には出会ったことがない
お金の問題かスケジュールの問題か人不足か
いずれにしろ仕様変更の影響度が大きすぎるから今の条件では対応できないということ
ぶっちゃけ言えば君から二度と仕事を振られなくても別に困らないということでもある 非常識な業者は多い。
だから優秀な社員、又はアドバイザーみたいな第三者を雇う。
例えば家の売買なら、直接売買せずに宅建業者を通すのと同じ
後はキャンセルして、裁判して金を取り返す。
そんな業者と付き合っても損するだけ
詐欺みたいなもの >>452
>アプリに関して無知ですが
無知な人が関わっちゃったのが
問題の根っこなのはさて置き
データ件数とかは設計時に検討した？のかな？
自分も死ぬほど経験しているけど
ウェブ制作会社のディレクターって
ウェブのこと全然知らないじゃん？
あんまり関わらない方がいいよ
自分でも作れるけどやらないだけ、くらいになるまでは 登録済みユーザーを一覧できる画面とか存在しないのかな？
負荷を無視して単に使い勝手を改善したいならデータリストに変更すれば解決 独自のプルダウンを開発すれば5万件いける
無限スクロールすればいい 
