元スレ+ JavaScript の質問用スレッド vol.143 +
JavaScript覧 / PC版 / みんなの評価 :
前へ
151 = :
>>150
>単純に全ページ共通で読み込まれるブロックを1つ作ればいいんじゃない
ううぅ… そんな事できんの…？
出来るならもちろんそうしたい
ひんとか検索キーワードだけでもプリプリプリーズ💩
152 = :
jQueryの.loadで共通のhtml1個作って読み込んでくれば？
ただ、そういう面倒な部分を共通化しいてきたいのなら、
PHPだのjsのフレームワーク使ってやったほうが生産性大分上がると思うよ。
毎回DOMいじってどうこうしてたら面倒でしょうがないと思う。
153 = :
SASS なんかも、Partial
application.scss
_reset.scss
_variables.scss
この3つのファイルがあって、application.scss 内に、
@import "reset";
@import "variables";
で読み込める！
どのフレームワークでも、Partial
154 = :
>>151
template要素を使うとか、createElementとか
156 = :
フレームワークを使わない場合の、Partial は、
Document.createDocumentFragment( ) とかかな？
例えば、メモリー内で、header, footer 用のDOM 木を構築しておいて、
<div id="container"> に読み込むとか？
159 = :
>>152
jQueryはじめてつかったけど、できちゃああ！ ありがとうー
でも、jQueryって将来性大丈夫なのかな。。。(´ρ`)
あ、公式のjs落としておけば、js生きてる限り平気なのか（中身ｊｓだから？）
>>153-158
いろいろありがと、SASS自体しらなかった、CSSまとめるの楽になりそうー
久しぶりに触ってるので、新しい情報いっぱいで感謝。
templateも見てみるけど、Rubyはちとなじみ無いかも(むつかしそう…)
>>144-145
document.writeメッチャつかってたから、非推奨情報たすかった！
💩 < さんくぷー！
160 = :
DOMを知らないコピペプログラマ増えたなー
161 = :
10年前に比べたらむしろ激減してるよ
162 = :
結局、オブジェクトのディープコピーの定番はなんなん？
163 = :
>>162
自分はlodashのcloneDeepに頼るか
むかし作ってメンテし続けてる自前関数でやってる
164 :
>>161
10～15年くらい前が
いちばんどむどむ言ってた気もする
けっこういろいろ自前でやらにゃならんかった頃だし
165 = :
>>163
lodashか・・・試してみるか・・・
jQuery信者なので$.extend使ってるんだけど
未だにjQueryはJKにも笑われちゃうよな・・・
166 = :
>>165
そうでもない気もする
俺の身の回り限定だけど
jQ以降の世代は、今のESになって盛んに脱jQを叫んでいるけど
jQ以前の世代は、便利なものもあるんだけどなーと思ってる
167 = :
DOM1箇所いじるだけならjQueryで十分いいし使えるんだけど、
それ以上の用途だと逆に面倒でとても使ってられんからなぁ。
前に、クライアント側にもフォームのバリデーション追加してくれって話しになって
一度決まったものを作るだけならよかったものの、そっから改修で弄り始めた途端に一瞬でカオス状態になったよ。
168 = :
>>162
型情報が失われるなど、あまり良くないやり方では、
JavaScript(JS)オブジェクト/JSON 文字列の変換により、新しいオブジェクトを構築するとか
JS Object → JSON 文字列 → JS Object(新しいオブジェクト)
Haxe のSerializer では、型情報を維持したまま、
異なる言語間でも、文字列で通信できるけど
ただし、抽象クラスには対応していない
169 = :
>>168
それって
例えばプロパティの値が日付オブジェクトだった場合
メソッドはどうなってしまうん？
170 = :
JSON では型情報が無くなるから、メソッドを呼んだりできないでしょ？
単純なデータを入れるだけの使い方をして、
型情報などは、別の文書に書いておく
この文書を管理する手間が掛かるから、面倒！
だから各言語には、通信先のホストで、オブジェクトを再構築できる、Serializer がある
各言語のオブジェクト → 文字列で通信 → オブジェクトを再構築
171 = :
>>168
json経由すんのってなんか遠回りでやだよね
結局定番らしい定番は無いってことやんね
その都度適当な方法でコピるしかないのか
172 = :
コピペプログラマは永遠になくならないな
173 = :
コピペプログラマが有識者にネタを求めて質問するのが、ここの日常だから
174 = :
>>164
だからこそ内容の全くわかってないコピペで動かない厨が多かった
175 = :
>>162
非同期で良いならMessageChannelを使うのが良い
もしくは標準で議論が進んでるからそれに近いポリフィルを作って使うかの２択
176 = :
>>172
そのコピーすらロクにできないんだよJavaScriptは！
177 = :
JSのオブジェクトはJSからは参照ができない内部スロットがあるのでコピーは難しい
うかつに完全なクローンが作れたらセキュリティにも影響するかもしれないし
178 = :
というかコピーはどの言語でも難しい問題だよ
そもそも関数を値としてみるかどうかだからな
値として見るならコピーした時、それは複製されていなければいけない
だけど大体の言語は値としてみなしてないだろう？
例えばアプリの特定のバージョンでオブジェクトをコピーというか
データとしてファイルにシリアライズする。
そしてアプリのバグを修正したバージョンで、データを読み取る
そうすると、その保存したデータに含まれる関数は
バグ修正の前のものであるべきかどうか
という話をすれば、コピーしたときに関数の情報はデータとして
含まれるべきかどうかという問題が難しいってわかるだろ？
179 = :
保存がしたい場合は別だけど、最初から複写されることがわかっている場合は
操作対象は元のオブジェクトに必ずプロキシを噛ませて使うことにしたら良い
値に変更が及んだ場合のみそのプロパティは以後そのプロキシでキャッシュされる
そうすればメソッドのコピーを考えなくても良い
180 = :
Windows10でGoogle Chromeを使っています。
http://blog.capilano-fw.com/?p=4063
上記の画像認識のリンクの中で
「特定の顔が誰なのかを判別する」
という項目がありますがそのプログラムの中で
const detection = await faceapi.detectSingleFace(image)
.withFaceLandmarks()
.withFaceDescriptor();
の内容をconsole.logで出力してみるとundefindedになります。
どなたかこのプログラムを試した方いらっしゃらないでしょうか。
ちなみにhttpsをアパッチで立ち上げていて、オレオレ証明を使っています。
181 = :
正確には顔認識じゃなくて、簡単な絵の画像認識をしてみたいのですが
いい方法がないでしょうか。
182 = :
Three.jsでレンダリングされたcanvasが、
ダウンロードバーの出現のせいで大きさが変わって困ってます。
ダウンロードの開始・終了は検知できるので
その間だけ自動サイズ調整を無効にするにはどうすればよいですか。
183 = :
>>182
スクロールバーを消せばよいのでは
184 = :
vanilla jsは文法は覚えたくらいのレベルの次となる、上のステップに行くには何をするのが学習する上で有効ですか？
おすすめの課題などがあれば紹介していただけると嬉しいです
185 = :
>>184
文法はバニラでなくても必要
ES2019を学べ
186 = :
180です。
ごめんなさい、絵の顔を認証させようとしてしていましたが
実写の写真じゃないとダメでした。
187 = :
>>185
既に文法をずっと学んでいて質問しました。
実践的なもので役立つ課題みたいなのってありますか？
188 = :
>>187
「ES2019の文法だけ」を覚えても仕方がない
文法以外も学習が必須
189 = :
>>187
ES2019 !== 文法
190 = :
>>187
JSわかってるなら問題ないよ
ドキュメントとリファレンスとサンプル見れば
あーなるほどねーって使える
それがライブラリやフレームワークってもんよ
191 = :
まあ、文法だけ覚えてるなら、課題やる前に覚えることはあるだろうね
制御構文とか、オブジェクトとか、プロトタイプとか、いくらでもある
192 = :
エクセルにjsが採用されてますます需要が高まるな
193 = :
実際jsコーディングする時って何を作るのが実践でも役立つ？
題材でよかったもんとかある？
194 = :
>>193
ES6以降のPolyfill
SelectorsvAPIのPolyfill
195 = :
>>193
markdownからDOMノードへの変換気
196 = :
とりあえずhtmlなり何かしらweb系を絡ませないと
js使う意味なくなってpythonとかでよくねになる気がする
197 = :
>>187が安易な答えを求めて、>>193の質問をしただけ
題材だけ揃えてもあかん
199 = :
JSの真価は言語的に仕様が小さくて拡張性があったことだが
ES6から10までの間に半分以上の可能性を消費していて
今が一番真価が発揮されている壮年期
かといって別の言語なら2030年代に革命を起こせるかというとそうではない
そろそろ既存の言語の進化系ではなく、
非同期の大量のタスクを圧倒的自然で素敵に捌ける
新しい仕組みを持った言語が必要ということ
200 = :
async,awaitって使う頻度低くないですか・・？
みんなの評価 :
JavaScript一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (881) - [97%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.103 + (1001) - [97%] - 2012/11/9 15:30
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.141 + (1001) - [97%] - 2019/9/22 23:15
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.122 + (116) - [95%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [95%] - 2014/11/8 1:15
トップメニューへ / →のくす牧場書庫について