+ JavaScript の質問用スレッド vol.136 +
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。 次スレは>>950 が(本スレで改善案があれば考慮して)立ててください ■規則/推奨ルール ・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止) ・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。 ・質問テンプレートの利用推奨。 ・質問への「答え」から解離した議論はよそでやること。 ■禁止行為 ・丸投げ質問 ・迷惑スクリプトの質問 ・オレオレ用語の使用(一般的な用語を使用する事) ・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事) ■質問テンプレート 【環境】OS, ブラウザをバージョンと共に記入してください。 【条件】期待する回答の条件を書いてください。 【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。 【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。 【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。 【サンプルコード】現象を再現可能な最小限のコードを書いてください。 1レスに収まらないならコード投稿サイトを利用してください。 http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/ ■回答者へ ・回答には多様性があります。他人の回答を尊重してください ・動作ブラウザや環境が限られる場合は、それを明記してください ・他人の回答を批判する代わりに、自分ならこう書くという例を示してください ・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い ・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける=荒らしです そりゃ出来は良くても敷居が高い言語より出来が酷くても敷居が低い言語が残るよ 何人月で計算して数集めて、みんなでスパゲッティを作るのさ フロントエンジニアがやりたいのにバックエンドに入れられた 転職しよっかな… フロントは本当に気楽だからな〜 phpは止まったら死亡 dbは難易度高すぎィ! むしろDB大好き でphp嫌い だからフロントに行きたい 楽なのはサーバーサイドで、気が楽なのはフロントだな >>161 お、客の誤字の責任を取らされる世界に来るかね? >>144 >>134 をよく読め 「cookieはDOMじゃないんだから」と書いてる >>163 デザイン系が好きなんだ 理系だけど大学はデザイン系に行ってた なんのデザインも扱えないサーバーサイド楽しいと思う? フロントは気が楽って実際にやってみればわかるけどクソ大変だぞ 上流が何も知らないと何故かサーバを作るところから始まるし、実現不可能なワイヤーフレームが上がってきたら出来ない理由を1から教えてあげないといけないし、デザインが期日通りに上がってこなかったらアラートも出さないといけない それで上がってきたデザインがjpegやpdf,excelだったりする クライアントが実際にものが上がらないと見てくれないところの場合、デザインがなくてもそれっぽく見せないといけないし、デザインないのに大量に戻しを入れられる 上流の遅れのツケが全部下流に回ってきて、土日祝日構わず働かないといけないこともあるしサイトが24時公開の場合は時限公開しても待機してないといけない 給料も安いしよっぽどのどMじゃないとフロントエンジニアは出来ないね >>164 ばかか。だから>>144 で "DOM要素" って訂正してるんだろ なんかその感じだと DOM要素だったら間違いじゃなくなるから 訂正を認めないって必死になってる風に見えるぞw >>156 初心者は最初はフレームワークオススメしない 素でSQL書くようにしなさい それをやっていく過程で、「こんなデータが送られてきたらやばくね?」とか気づく そうしていくうちにセキュリティ意識が高くなるって自分でテスト攻撃と防御をするようになる 「フレームワークは中身何やってるんだかわからね」って感じになるから初心者は手を出すべきではない >>159 両方できるようになるべきだからその環境を喜べ フロントはjsでデータ保持して必要なときにajaxでバックエンドや他サービスへAPIリクエストするのが今後の主流だからその技術力がないとね まあreactとか使うからバカでもできるんだが 今はサポートライブラリがたくさんあって公式でもsuspense来るからそうだけど、当初はreactでajaxは鬼門だっただろ。 少なくともバカには出来なかった。 jQueryのajaxの記法が変わった時は冷や汗が止まらなかった >>168 要素限定はお前が勝手に主張してるだけだろ documentやwindowに.on()出来るし、.children()があるだろ computedStyleはdefaultView見てるし、コンテキストオブジェクトでdocumentを指定出来るじゃないか >>150 Ruby on Rails, Sinatra をいじくり回すのが早い DB アクセスは、フレームワークに付いている HTML, CSS(SASS), JavaScript(JS) も使う。 JS は、jQuery, Vue.js, Node.js なども使う テンプレートエンジンは、PHP に似た、ERB <% price = 2500 * 1.05 %> <p> 本の値段は<%= price %>円です。 </p> Ruby で、PowerShell から、Web サーバーを起動すると、WEBrick が起動する。 ruby -run -e httpd . -p 8080 これだけで、index.html にアクセスできる。 http://localhost:8080 プログラマースレでRubyはオワコンみたいなのを読んだんだけど、どうなの? javaとかより短く書けるからやってみたいなとも思うけど、今更なのかな?と思う気持ちもある 短く書ける事に何かメリットを感じるのなら、学習してみればいいんじゃないかな 俺にはちょっとよくわからない感覚だ >>173 なんで冷や汗が出るの? 古い記述が使えなくなったわけでもないし、 新しいjQueryにすぐに置き換えなければいけないわけでもないだろ >>176 世界的に使われなくなってるしそもそも嫌われてるからやらないほうがいい 気持ち悪い宗教に入信するのと同じレベル 短く書けるとか関係ない 世界の潮流に従うべき Python ブームに乗って、Pythonやった人が、ほとんど自滅してる Ruby の偽は、nil, false の2つだけ。 一方、JavaScript(JS), Python, PHP などは、偽が10個ぐらいあるから、まともにプログラミングできない Rubyは、jQuery のように、メソッドチェーンで書ける。 関数型。 加えて、オブジェクト指向 + Duck Typing で、JS のようにうっとおしい事もない スコープが厳格だから、外側の変数を、内側へ通さない。 スコープを変える、メタプログラミング・DSL 用のメソッドが、区別されている Sinatra をフルスクラッチで書くと、Web プログラミング・フレームワークの基本を学べる。 その後、無料のRails チュートリアルをやってもよい Progate でも、途中まで無料でやれる Pythonは機械学習専用だな webサーバーでpython使うメリットは、元々python使える人が楽に導入できるって程度のもの それを知らずにpythonでwebは茨の道 >>180 これが典型的なruby使い まず他言語を落としてから、rubyを持ち上げる そりゃー嫌われれる そういえばRubyは言語自体よりコミュニティの 勘違い野郎たちの方に問題があるってきいたわ AWSでサポートされただけでtwitterのトレンド入りした化石言語のCOBOLこそが最強 今さら激遅ruby、さらにもっと遅くなるRails使うとかあり得ねえわ Ruby で、web プログラミングでも、HTML, CSS(SASS), JavaScript(JS) も使う。 JS は、jQuery, Vue.js, Node.js なども使うし、 JSは、Rubyに似せてくるから、Rubyをやって損はない Windows でもファイル操作できるし、ツール作りにはよい。 PowerShell よりも使いやすい Python は、AI・機械学習・数学統計・ラズパイとか。 普通のweb やると、爆死する 掌田津耶乃の本も、出たばっかり。 Python Django 超入門、2018 Node.js超入門、2017 windowsでrubyはねーよ どれだけ知ったかなんだ >>180 > JavaScript(JS), Python, PHP などは、偽が10個ぐらいあるから、まともにプログラミングできない 今すぐ10個挙げてみろやホラッチョ糞Rubyキチガイ。 jsの関数相当がメソッド、Proc、lambda、ブロック、と4つもあり、 すべて変換が必要で、 それぞれ細かな挙動が異なり、 関数がファーストクラスオブジェクトではないクソ言語が流行ってるから!Rubyでもできるもん! と関数型を標榜するとはヘソが茶を沸かすわwwwww rubyだけは使わない方が良いという分かりやすい流れ サーバーサイドもフロントも両方やるけど、フロントのが大変だが気は楽だぞ。 バックエンドほどクリティカルなもんが多くない。 AudioElementのaudio.volume=0.3とWeb Audio APIのgain.value=0.3とでは音量が後者の方が小さく聞こえます 同じ値を設定したときの音量を統一したいのですが、どのようにするべきでしょうか? 結局、jQuery房のDOM要素は完全敗北したのん? 音量調整とか地獄すぎるな 端末やブラウザで変わりまくるんじゃないか フルスクラッチでwebアプリケーションを開発することになりました。 選定した技術について、色々とご指摘いただけると嬉しいです。 ■インフラ ・Google App Engine Standard Environment(以下GAE/SE) https://cloud.google.com/appengine/docs/standard/?hl=ja ■言語 node.js ■フロントエンド GAE/SEにService Aとしてデプロイ nuxt.jsを使いSSRする もちろんSPA、PWAに対応 ■バックエンド GAE/SEににService Bとしてデプロイ Apollo Server (RESTではなくGraphQLを使う) https://www.apollographql.com/docs/apollo-server/ ■データベース Cloud Datastore https://cloud.google.com/datastore/?hl=ja >>200 開発日記公開してくれ そこにコメントする jQuery君は仕様に詳しくないのだから、あまりいじめてやるな そうか? jQueryはDOM要素限定だと必死に主張してるだけに見えるが >>134 「cookieはDOMじゃないんだから」 >>137 「DOM Level3以降の仕様からは消されたけどなw」 >>139 「じゃあjQueryはDOM"要素"操作ライブラリって言えば納得するんか? 単なる言葉遊び、本質は変わらんよ」 どれ一つ正しくないわけだが もうさ、くだらないからそろそろやめてくれ つまらん jQuery房はプライド高い上に、後付け理論で訂正を整える事に必死だから嫌いだわ gatsbyでこんなコード片があるんだが {posts .filter(post => post.node.frontmatter.title.length > 0) .map(({ node: post }) => { return (... map(({node: post})の{node: post}ってどういう構文なんだ {node: post}ってのはjsonみたいなオブジェクトか何か? >>216 聞く時はもうちょい丁寧に聞いたほうがいいよ 「分割代入 オブジェクト」くらいで引っかかるんじゃね >>215 jQuery房からまともな反論が返ってくるわけないんだから、その辺にしておきなよ 彼の完全敗北は皆わかってる >>216 オブジェクト初期化子 >>219 自覚ないのか? お前のこと言ってるんだよ 議論するなら技術的な内容を伴ったものにしろよ ただ煽りあうマウントの取り合いは不毛 「cookieはDOMじゃない」はDOMの範疇なので間違い 「DOM Level3以降の仕様からCookieは削除されている]は意味不明 「DOM Level 2 HTML」があって「DOM Level 3 HTML」がないから削除されたと思い込んでるのかね https://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-BBACDC08 jから "The interfaces within this section are considered fundamental, and must be fully implemented by all conforming implementations of the DOM, including all HTML DOM implementations [DOM Level 2 HTML], unless otherwise specified." を100回読め 「jQueryはDOM"要素"操作ライブラリ」をオレオレ理論すぎる >>174 で反論済 「本質は変わらん」て、DOMとDOM要素は本質的に違うだろうが 「documentはDOMじゃない=documentはDOM要素じゃない」が通用するわけがない >>222 使ったこと無いけど、多分導入に結構時間がかかるのは分かる 学習コスト高い割に、そこまで機能が良いわけでもなく、独自要素が多すぎて潰しも効かないので使っていない >>222 nuxt.js(vuex)つかえばいいじゃん なんかreact界隈って今となっては大昔のライブラリ戦争、jQueryに駆逐されたPrototype.js臭がするんだよね 簡単に記述できることを難しくしちゃってる所が特に・・・ >>213 ES2015(ES6)から入った分割代入という構文。 https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment 関数定義の引数の部分が{node: post}だと、実引数として渡ってきたオブジェクトのnodeというプロパティを、postという変数に代入して(束縛と言わないと怒る人もいそうだが)、関数定義の本文でpostという名前でアクセスできる(使える)ようになる。 つまり、 .map(({ node: post }) => { return (... は、 .map((post) => { post = post.node; return (... と、等価。 引数を直接書き換えるのはお行儀が悪いと言われてる(V8の中の人によるとパフォーマンスも若干悪くなるらしい)ので、 .map((_post) => { let post = _post.node; return (... とかでもいいよ。 >>224 一週間学習してるんだけどさ、7割くらい理解できたんだが、さあアプリ作るぞってなったときどこから作ればいいのか不明 こんなライブラリ初めてだわ ネットみたらreact始めてすげー!redux導入して挫折ってブログが多い >>227 もうプロジェクトでreact使うこと決まったんだよね 有名なログイン処理のreactとreduxサンプル http://jasonwatmore.com/post/2017/09/16/react-redux-user-registration-and-login-tutorial-example フロントでログイン処理するだけで約20ファイルもある これとバックエンド繋ぐんだがマジで二重管理になるよな >>229 嫌すぎる… ログインログアウトだけページ遷移許してもらえばreactの外で旧来スキームで出来ないの? >>229 やっぱそうだよね。印象だけでもとっつきにくい。どういう場面で使えばいいのかよく分からなかった プロジェクトに向いてるかどうかで考えた方が良いのかも知れない ってプロジェクトで使う事が決まったのか、頑張って〜\(^o^)/ >>230 それね ログインページだけバックエンドのビューで生成してログイン後がreactってのもアリだとは思う それだとcontrollerとviewのたったの2ファイルでできるしね >>231 大手でもよくわからず使ってるプロジェクトもあるらしい ほんとバグの温床になるよなぁ >>233 似たような調査Node学園祭でもやってたな Reactは使ったことないけど、Vueはかゆいとこに手が届かない感じがする コンポーネントの親子関係とか、v-ifで子画面開くのにそれ用のフラグが必要だったり >>196 音量0と最大はどのブラウザ同じでも係数まではHTML5の仕様として決められておらずバラバラの可能性がある? 一度dBに変換するといったことも考えたのですが難しそうですね >>200 Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発、 花谷 拓磨、2018/10/17 この本によると、Heroku, AWS Lambda に当てはまらない場合は、GAE Standard がお勧め。 ただし、SMTP, WebSocket などは制限されている それらを使う場合は、GAE Flexible になるため、 インスタンス課金 + サーバーを所持する形へ変わるため、Nuxt.js には適さない Vue.js 日本語公式 Slack がある 下の本もよい。 基礎から学ぶ Vue.js、mio、2018/5/29 >>237 ありがとう、参考にします。 WebSocketは使わずGraphQLでJSON吐き出せれば十分なのでGAE/SEで良さそうですね。 >>236 探してみたけど、webで音声の扱いはロクな資料が無かったわ 質問 for ( let A of B ) { ... } というコードを書いた時、「B」はループの中で毎回評価(計算)される(=重い処理を書かないほうがいい)んでしょうか? それとも最初の1回だけですか? >>240 その処理の中にconsole.logを仕込んで確かめると良い 良く使うデバッグ手法 >>241 言いたいことは分かるんですけど 世界で自分しか検証し得ない最先端のテーマならともかく このありふれた疑問に対して答えを知ってるならサクッと教えてほしいです 車輪の再発明は嫌です すでにあるものと同じものを作るのが車輪の再発明であって、言語仕様を調べるのをサボることを言うのではない。 都合よく解釈しないように。 答え書いとくとBの評価は最初の一回のみ。 for ofではBはiterableオブジェクトでなければならず、最初にiteratorが取り出され、以降ループ毎にそのiteratorのnextメソッドの戻り値のオブジェクトのvalueプロパティに入っている値がAに入ることになっている。 これがnextメソッドの戻り値のオブジェクトのdoneプロパティがtrueになるまで続く。 処理系の実装でどのように最適化されてるかは知らないが、仕様ではそうなっている。 >>244 ありがとうございます。これでスッキリ使えます。 ただ言語仕様は調べたんです。一定時間調べて答えに辿り着かなかったので聞きました。 さあやるぞー。 訳が難しいのあるよね iterableとかconfigurableとかinvariantsとか、意味は分かるけど日本語にすると PHPは初心者お断りってあるから聞き辛いけど、javascriptスレは初心者にも優しいのでありがたい trelloのチケットを横に動かすみたいな動きのものはvue.jsとか使えばいいの? フレームワークを何から始めようか迷ってます >>239 ありがとう 適当に近い音量になるように計算させてみようと思います。 >>250 そもそも何故同じにしたいのか 全部WebAudioAPIで処理すればいいじゃない Bがジェネレーターとして重い処理を書かないほうがいいのかと聞いてるのなら 毎回評価されるという解になるな いやジェネレータからイテレータ取り出してんのは最初だけだろ。 前回のyieldから次のyieldまでの処理は当然毎回走るが、それは当たり前じゃん。毎回走ってほしい部分が走ってほしくないってどんな状況よ for (let i of [1, 2, 3]) {console.log(i)} の結果が1 2 3になるか1 1 1になるかを自分で確かめることすら車輪の再発明()とか言ってやりたがらないとかクズ過ぎる。 質問回答のコミュニケーションコストの方がよっぽど高くつくと思うのだが。 確かめるなら for(let i of hoge()){ } function hoge(){ console.log('hoge') return [1, 2, 3] } じゃない? >>255 うむ。>>254 は罵っといて自分が理解してないという最高級のダサさ。 >>253 当たり前とも言えるがそこは隠蔽されてもいるんだからさ どうでもいいけど何でforでlet使ってるの? constにしないの? for (const i of arr) { } ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる