私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.143 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
前へ
jQueryの.loadで共通のhtml1個作って読み込んでくれば？
ただ、そういう面倒な部分を共通化しいてきたいのなら、
PHPだのjsのフレームワーク使ってやったほうが生産性大分上がると思うよ。
毎回DOMいじってどうこうしてたら面倒でしょうがないと思う。
ただ、そういう面倒な部分を共通化しいてきたいのなら、
PHPだのjsのフレームワーク使ってやったほうが生産性大分上がると思うよ。
毎回DOMいじってどうこうしてたら面倒でしょうがないと思う。
SASS なんかも、Partial
application.scss
_reset.scss
_variables.scss
この3つのファイルがあって、application.scss 内に、
@import "reset";
@import "variables";
で読み込める！
どのフレームワークでも、Partial
application.scss
_reset.scss
_variables.scss
この3つのファイルがあって、application.scss 内に、
@import "reset";
@import "variables";
で読み込める！
どのフレームワークでも、Partial
>>151
template要素を使うとか、createElementとか
template要素を使うとか、createElementとか
Ruby on Rails では、application.html.erb の中で、各部分テンプレートを読み込む。
_header.html.erb, _footer.html.erb に、その部分だけを作っておく
ERB テンプレート内では、<% ～ %> 内に、Ruby のコードを書いて、それをHTML へ変換する。
<% 式 %>, <%= 式 %>
<div id="container">
<header>
<%= render "header" %>
</header>
<footer>
<%= render "footer" %>
</footer>
</div>
このように、どのフレームワークでも、Partial で作る！
React, Vue.js, Electron なども同じ
_header.html.erb, _footer.html.erb に、その部分だけを作っておく
ERB テンプレート内では、<% ～ %> 内に、Ruby のコードを書いて、それをHTML へ変換する。
<% 式 %>, <%= 式 %>
<div id="container">
<header>
<%= render "header" %>
</header>
<footer>
<%= render "footer" %>
</footer>
</div>
このように、どのフレームワークでも、Partial で作る！
React, Vue.js, Electron なども同じ
フレームワークを使わない場合の、Partial は、
Document.createDocumentFragment( ) とかかな？
例えば、メモリー内で、header, footer 用のDOM 木を構築しておいて、
<div id="container"> に読み込むとか？
Document.createDocumentFragment( ) とかかな？
例えば、メモリー内で、header, footer 用のDOM 木を構築しておいて、
<div id="container"> に読み込むとか？
lodash の、template
<% ～ %> 内に、JavaScript のコードを書いて、それを文字列へ変換する
<% 式 %> 値を埋め込まない
<%= 式 %> 値を埋め込む
<%- 式 %> HTML エスケープする
var compiled = _.template(
'<% _.forEach(users, function(user) { %>
<li><%- user %></li>
<% }); %>'
);
compiled({ 'users': ['fred', 'barney'] });
// => '<li>fred</li><li>barney</li>'
<% ～ %> 内に、JavaScript のコードを書いて、それを文字列へ変換する
<% 式 %> 値を埋め込まない
<%= 式 %> 値を埋め込む
<%- 式 %> HTML エスケープする
var compiled = _.template(
'<% _.forEach(users, function(user) { %>
<li><%- user %></li>
<% }); %>'
);
compiled({ 'users': ['fred', 'barney'] });
// => '<li>fred</li><li>barney</li>'
DOM1箇所いじるだけならjQueryで十分いいし使えるんだけど、
それ以上の用途だと逆に面倒でとても使ってられんからなぁ。
前に、クライアント側にもフォームのバリデーション追加してくれって話しになって
一度決まったものを作るだけならよかったものの、そっから改修で弄り始めた途端に一瞬でカオス状態になったよ。
それ以上の用途だと逆に面倒でとても使ってられんからなぁ。
前に、クライアント側にもフォームのバリデーション追加してくれって話しになって
一度決まったものを作るだけならよかったものの、そっから改修で弄り始めた途端に一瞬でカオス状態になったよ。
>>162
型情報が失われるなど、あまり良くないやり方では、
JavaScript(JS)オブジェクト/JSON 文字列の変換により、新しいオブジェクトを構築するとか
JS Object → JSON 文字列 → JS Object(新しいオブジェクト)
Haxe のSerializer では、型情報を維持したまま、
異なる言語間でも、文字列で通信できるけど
ただし、抽象クラスには対応していない
型情報が失われるなど、あまり良くないやり方では、
JavaScript(JS)オブジェクト/JSON 文字列の変換により、新しいオブジェクトを構築するとか
JS Object → JSON 文字列 → JS Object(新しいオブジェクト)
Haxe のSerializer では、型情報を維持したまま、
異なる言語間でも、文字列で通信できるけど
ただし、抽象クラスには対応していない
JSON では型情報が無くなるから、メソッドを呼んだりできないでしょ？
単純なデータを入れるだけの使い方をして、
型情報などは、別の文書に書いておく
この文書を管理する手間が掛かるから、面倒！
だから各言語には、通信先のホストで、オブジェクトを再構築できる、Serializer がある
各言語のオブジェクト → 文字列で通信 → オブジェクトを再構築
単純なデータを入れるだけの使い方をして、
型情報などは、別の文書に書いておく
この文書を管理する手間が掛かるから、面倒！
だから各言語には、通信先のホストで、オブジェクトを再構築できる、Serializer がある
各言語のオブジェクト → 文字列で通信 → オブジェクトを再構築
>>164
だからこそ内容の全くわかってないコピペで動かない厨が多かった
だからこそ内容の全くわかってないコピペで動かない厨が多かった
>>172
そのコピーすらロクにできないんだよJavaScriptは！
そのコピーすらロクにできないんだよJavaScriptは！
JSのオブジェクトはJSからは参照ができない内部スロットがあるのでコピーは難しい
うかつに完全なクローンが作れたらセキュリティにも影響するかもしれないし
うかつに完全なクローンが作れたらセキュリティにも影響するかもしれないし
というかコピーはどの言語でも難しい問題だよ
そもそも関数を値としてみるかどうかだからな
値として見るならコピーした時、それは複製されていなければいけない
だけど大体の言語は値としてみなしてないだろう？
例えばアプリの特定のバージョンでオブジェクトをコピーというか
データとしてファイルにシリアライズする。
そしてアプリのバグを修正したバージョンで、データを読み取る
そうすると、その保存したデータに含まれる関数は
バグ修正の前のものであるべきかどうか
という話をすれば、コピーしたときに関数の情報はデータとして
含まれるべきかどうかという問題が難しいってわかるだろ？
そもそも関数を値としてみるかどうかだからな
値として見るならコピーした時、それは複製されていなければいけない
だけど大体の言語は値としてみなしてないだろう？
例えばアプリの特定のバージョンでオブジェクトをコピーというか
データとしてファイルにシリアライズする。
そしてアプリのバグを修正したバージョンで、データを読み取る
そうすると、その保存したデータに含まれる関数は
バグ修正の前のものであるべきかどうか
という話をすれば、コピーしたときに関数の情報はデータとして
含まれるべきかどうかという問題が難しいってわかるだろ？
保存がしたい場合は別だけど、最初から複写されることがわかっている場合は
操作対象は元のオブジェクトに必ずプロキシを噛ませて使うことにしたら良い
値に変更が及んだ場合のみそのプロパティは以後そのプロキシでキャッシュされる
そうすればメソッドのコピーを考えなくても良い
操作対象は元のオブジェクトに必ずプロキシを噛ませて使うことにしたら良い
値に変更が及んだ場合のみそのプロパティは以後そのプロキシでキャッシュされる
そうすればメソッドのコピーを考えなくても良い
Windows10でGoogle Chromeを使っています。
http://blog.capilano-fw.com/?p=4063
上記の画像認識のリンクの中で
「特定の顔が誰なのかを判別する」
という項目がありますがそのプログラムの中で
const detection = await faceapi.detectSingleFace(image)
.withFaceLandmarks()
.withFaceDescriptor();
の内容をconsole.logで出力してみるとundefindedになります。
どなたかこのプログラムを試した方いらっしゃらないでしょうか。
ちなみにhttpsをアパッチで立ち上げていて、オレオレ証明を使っています。
http://blog.capilano-fw.com/?p=4063
上記の画像認識のリンクの中で
「特定の顔が誰なのかを判別する」
という項目がありますがそのプログラムの中で
const detection = await faceapi.detectSingleFace(image)
.withFaceLandmarks()
.withFaceDescriptor();
の内容をconsole.logで出力してみるとundefindedになります。
どなたかこのプログラムを試した方いらっしゃらないでしょうか。
ちなみにhttpsをアパッチで立ち上げていて、オレオレ証明を使っています。
正確には顔認識じゃなくて、簡単な絵の画像認識をしてみたいのですが
いい方法がないでしょうか。
いい方法がないでしょうか。
Three.jsでレンダリングされたcanvasが、
ダウンロードバーの出現のせいで大きさが変わって困ってます。
ダウンロードの開始・終了は検知できるので
その間だけ自動サイズ調整を無効にするにはどうすればよいですか。
ダウンロードバーの出現のせいで大きさが変わって困ってます。
ダウンロードの開始・終了は検知できるので
その間だけ自動サイズ調整を無効にするにはどうすればよいですか。
>>182
スクロールバーを消せばよいのでは
スクロールバーを消せばよいのでは
vanilla jsは文法は覚えたくらいのレベルの次となる、上のステップに行くには何をするのが学習する上で有効ですか？
おすすめの課題などがあれば紹介していただけると嬉しいです
おすすめの課題などがあれば紹介していただけると嬉しいです
180です。
ごめんなさい、絵の顔を認証させようとしてしていましたが
実写の写真じゃないとダメでした。
ごめんなさい、絵の顔を認証させようとしてしていましたが
実写の写真じゃないとダメでした。
>>187
ES2019 !== 文法
ES2019 !== 文法
まあ、文法だけ覚えてるなら、課題やる前に覚えることはあるだろうね
制御構文とか、オブジェクトとか、プロトタイプとか、いくらでもある
制御構文とか、オブジェクトとか、プロトタイプとか、いくらでもある
実際jsコーディングする時って何を作るのが実践でも役立つ？
題材でよかったもんとかある？
題材でよかったもんとかある？
>>193
markdownからDOMノードへの変換気
markdownからDOMノードへの変換気
とりあえずhtmlなり何かしらweb系を絡ませないと
js使う意味なくなってpythonとかでよくねになる気がする
js使う意味なくなってpythonとかでよくねになる気がする
JSの真価は言語的に仕様が小さくて拡張性があったことだが
ES6から10までの間に半分以上の可能性を消費していて
今が一番真価が発揮されている壮年期
かといって別の言語なら2030年代に革命を起こせるかというとそうではない
そろそろ既存の言語の進化系ではなく、
非同期の大量のタスクを圧倒的自然で素敵に捌ける
新しい仕組みを持った言語が必要ということ
ES6から10までの間に半分以上の可能性を消費していて
今が一番真価が発揮されている壮年期
かといって別の言語なら2030年代に革命を起こせるかというとそうではない
そろそろ既存の言語の進化系ではなく、
非同期の大量のタスクを圧倒的自然で素敵に捌ける
新しい仕組みを持った言語が必要ということ
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
トップメニューへ / →のくす牧場書庫について