16/06/09 00:24:45.57 .net
■前スレ
JavaScript ライブラリ総合質問所 vol.4
ｽﾚﾘﾝｸ(hp板)
■関連スレ
+ JavaScript の質問用スレッド vol.115 +
ｽﾚﾘﾝｸ(hp板)
JavaScript Tips コレクション
ｽﾚﾘﾝｸ(hp板)
1行javascriptプログラミング
ｽﾚﾘﾝｸ(hp板)
【node.js】サーバサイドjavascript 2【Rhino】
ｽﾚﾘﾝｸ(tech板)
■各種ライブラリ
jQuery API Documentation
URLﾘﾝｸ(api.jquery.com)
jQuery Mobile API Documentation
URLﾘﾝｸ(api.jquerymobile.com)
API Docs - YUI Library
URLﾘﾝｸ(yuilibrary.com)
Underscore.js
URLﾘﾝｸ(underscorejs.org)
lodash documentation
URLﾘﾝｸ(lodash.com)
3:Name_Not_Found
16/06/09 00:39:54.59 .net
>>2の関連スレが古いので訂正。
■関連スレ
+ JavaScript の質問用スレッド vol.120 + [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(tech板)
+ JavaScript の質問用スレッド vol.130 + [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(hp板)
JavaScript Tips コレクション
ｽﾚﾘﾝｸ(hp板)
1行javascriptプログラミング
ｽﾚﾘﾝｸ(hp板)
【node.js】サーバサイドjavascript 2【Rhino】
ｽﾚﾘﾝｸ(tech板)
4:Name_Not_Found
16/06/12 11:07:35.91 .net
次スレはここかな
総合スレが復活して良かった
5:Name_Not_Found
16/06/12 17:40:51.91 .net
jQuery Compat 3.0のサポートブラウザがよくわからん
6:Name_Not_Found
16/06/12 19:58:16.09 .net
>>5
+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(hp板)
こっちに答え書いてあるよｗ
7:Name_Not_Found
16/06/12 22:20:24.63 .net
>>6
具体的な情報が書いてないがな
8:Name_Not_Found
16/06/12 22:43:12.38 .net
+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(hp板:8番)
>>7
書いたよｗ
9:Name_Not_Found
16/06/12 22:51:25.15 .net
>>5
アップグレードガイドを読む限り、jQuery 3.0 は IE9+ 対応とある
URLﾘﾝｸ(jquery.com)
こちらではIE6-8は1.12を使ってくれ、とある
URLﾘﾝｸ(blog.jquery.com)
こちらでは「jQuery Compat」は死んだ、といってる
URLﾘﾝｸ(blog.jquery.com)
というわけで「jQuery Compatはない」が正解
不確かな情報に踊らされないように
10:Name_Not_Found
16/06/12 22:59:20.70 .net
だから、
> そのため予定されていたjQuery Compat 3.0がなくなり、
> jQueryは3.0に一本化されました。
って
+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(hp板)
に書いてあるのにｗ
読んでんだろｗｗｗ
11:Name_Not_Found
16/06/12 23:01:02.66 .net
やっぱりjQueryの話はjQueryスレの方が
正しい情報書いてあるな。
なんだこのスレｗｗｗ
12:Name_Not_Found
16/06/12 23:05:54.69 .net
>>8-9
ありがとう
13:Name_Not_Found
16/06/12 23:11:00.39 .net
Qiitaのまとめが分かりやすいな
【翻訳まとめ】jQuery 3.0 アップグレードガイド - Qiita
URLﾘﾝｸ(qiita.com)
14:Name_Not_Found
16/06/13 00:35:21.25 .net
これもプログラム板に移すんじゃなかったのか
また荒らされて終わるでしょ
15:Name_Not_Found
16/06/13 00:46:15.41 .net
URLﾘﾝｸ(qiita.com)
「document-readyが常に非同期に」はこういうことか
ずいぶんとトリッキーな動きだな
'use stirct';
document.addEventListener('DOMContentLoaded', function (event) {
console.log(document.readyState);
jQuery(function () {
console.log(2);
});
console.log(1);
}, false);
DOMContentLoaded 的には何もしないのが正解なのだろうが
16:Name_Not_Found
16/06/13 10:24:15.39 .net
このスレの書き込みをjQueryスレに投稿し直してる奴は何なんだ？
そこまでして向こうのみならずスレを盛り上げたいのか…
+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(hp板)
17:Name_Not_Found
16/06/13 11:09:19.43 .net
>>15
DOMContentLoadedハンドラの後で動作するようにしてるのね
DOMContentLoadedのショートハンドとしてはありえない動きだけど、イベントを知らない初心者向けとしてはありがたい挙動なのかもね
18:Name_Not_Found
16/06/13 14:43:20.78 .net
>>16
それ本家質問スレに常駐してる荒らしが立てたスレだからだよ
以前も自分の建てた乱立スレに本スレから質問コピペ→自己レスして伸ばしてた
19:Name_Not_Found
16/06/13 14:49:51.66 .net
どっちが本家？
20:Name_Not_Found
16/06/13 14:57:24.60 .net
ｽﾚﾘﾝｸ(hp板)
現行はこれ
21:Name_Not_Found
16/06/13 22:30:48.26 .net
■ライブラリ総合スレ
【jQuery】JavaScript ライブラリ総合質問所 vol.3
ｽﾚﾘﾝｸ(hp板)
JavaScript ライブラリ総合質問所 vol.4
ｽﾚﾘﾝｸ(hp板)
JavaScript ライブラリ総合質問所 vol.5 [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(hp板)
■jQueryスレ
※前スレは「【jQuery】JavaScript ライブラリ総合質問 vol.3」(総合スレ)で「jQueryスレ vol.3」はない。
つまり、ライブラリスレの乗っ取り行為。
jQuery ライブラリ 総合質問所 vol.4
ｽﾚﾘﾝｸ(hp板)
+ JavaScript & jQuery 質問用スレッド vol.5 + [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(hp板)
22:Name_Not_Found
16/06/14 10:33:24.43 .net
>>19
jQueryスレとこっちを比較しているならこっちが本家
23:Name_Not_Found
16/06/14 10:56:46.12 .net
試してみてびっくりしたんだが、下記コードを実行すると
jquery-2.2.4.js では「1 -> 3 -> 2」となり、
jquery-3.0.0.js では「1 -> 2 -> 3」だった
document.addEventListener('DOMContentLoaded', function () {
console.log(2);
}, false);
jQuery(function () {
console.log(3);
});
console.log(1);
24:Name_Not_Found
16/06/14 11:27:50.36 .net
> 例えば"abc.def"というidを持つ要素をjQueryで取得することは出来ませんでしたが、この関数を使って$("#" + $.escapeSelector("abc.def"))と取得することができます。
URLﾘﾝｸ(qiita.com)
そんな馬鹿な、と思って試してみた
<p id="abc.def">#abc.def</p>
<script type="text/javascript">
'use stirct';
console.log(document.querySelector('#abc\\.def')); // OK
console.log(jQuery('#abc\\.def')[0]); // 2.2.4, 3.0.0 共にOK
console.log(jQuery('#' + jQuery.escapeSelector('abc.def'))[0]); // 3.0.0 のみOK
</script>
やはり、jquery-2.2.4.js でも実装できるな(エスケープ関数が用意されてなかっただけ)
25:Name_Not_Found
16/06/22 18:50:52.88 0C9LwOLq.net
jQueryにArray.prototype.concatと同等の関数はありますか。
var a = jQuery('#a');
var b = jQuery('#b');
var c = jQuery('#d');
var abc = jQuery('#a,#b,#c');
変数a,b,cから変数abcを一つの関数で生成したいのですが、APIが見つかりませんでした。
26:25
16/06/22 18:52:26.13 0C9LwOLq.net
>>25のコードに誤りがありましたので訂正します。
var c = jQuery('#c');
27:Name_Not_Found
16/06/22 21:23:37.27 .net
jQuery([a,b,c])
28:25
16/06/22 21:41:22.02 0C9LwOLq.net
>>27
ありがとうございます。出来ました。
jQueryにmerge機能が付いていたんですね。
ヒントを頂いたのでjQueryオブジェクト以外も試してみましたが、NodeListやHTMLCollectionはmergeしてくれませんでした…。
console.log(jQuery([document.querySelectorAll('p'), document.getElementsByTagName('div')]));
29:Name_Not_Found
16/06/23 00:17:37.67 .net
ｽﾚﾘﾝｸ(hp板:894番)がいってたjQuery版は16日経過した今も出てこないな
彼がどんなコードを書くのか興味があったんだが…、まあいいか
30:Name_Not_Found
16/06/23 00:49:15.33 .net
>>25
このスレで聞いても間違いしか出てこないよ。
こっちにjQueryを混ぜようとしたいだけで
jQueryが好きでもないやつがjQueryの話をしているだけだから。
あなたの疑問に対する答えはこっちに書いた。あとはこっちでやるように。
ｽﾚﾘﾝｸ(hp板:63番)
31:25
16/06/23 01:29:52.48 P9mZ3YME.net
>>30
間違いを指摘してくれた事には感謝しますが、このスレで満足していますのでそちらに書いて頂かなくて結構です。
>>21にあるように本スレはこちらだと思っています。
.add()はa.add(b, c)が期待通りに動かず、a.add(b).add(c)と書いてようやく要件を満たします。
(勿論、2回関数を呼び出してしまっていますので完全ではありません)。
.add()はどちらかといえば機能限定版(非破壊的、可変引数ではない)のArray.prototype.pushに近いメソッドだと認識しています。
そういえば、jQuery APIで可変引数の関数は見ないですね。
URLﾘﾝｸ(api.jquery.com)
32:25
16/06/23 01:40:53.04 P9mZ3YME.net
ああ、jQuery.extendが可変引数ですね。
反面、jQuery.mergeが可変引数でない仕様が謎です…。
jQuery作者はjQuery.merge(a, b, c);と書くニーズがないと思ってるんですかね。
URLﾘﾝｸ(api.jquery.com)
URLﾘﾝｸ(api.jquery.com)
33:25
16/06/23 02:03:36.83 P9mZ3YME.net
とりあえず、Spread要素で実装できました。
jQuery([...a,...b,...c]);
が、Babelを使うならjQueryを使う必要性が激減します。
jQuery APIの範囲内では何ともならないのでしょうかね…。
34:25
16/06/23 02:34:55.27 P9mZ3YME.net
ES5で妥協したコード。
Array.prototype.reduceとjQuery.mergeで2回呼んでるので私的にはまだ不満です。
もっとすっきり書けるコードがあればいいのですが。
[a, b, c].reduce(jQuery.merge); // 破壊的
console.log(a);
var abc = jQuery(a);
[abc, b, c].reduce(jQuery.merge); // 非破壊的
console.log(abc);
35:Name_Not_Found
16/06/23 02:43:27.62 .net
ほらねｗ 結局ここでやるなら自分で答えを考えるしか無いわけさｗ
36:Name_Not_Found
16/06/23 02:51:42.04 .net
回答じゃないけど、reduceの使い方が面白いね
37:Name_Not_Found
16/06/23 02:59:20.23 .net
可読性を低くしてまでやることじゃないけどなｗ
動きをドヤ顔で説明したくなるようなコードはだめ
38:Name_Not_Found
16/06/23 03:00:22.37 .net
ぶっちゃけ、この質問者はそこらの回答者よりもレベルが高い
向こうの回答よりも自分で導き出したコードの方が洗練されてるから、どこで質問しても結果は同じだっただろうな
39:Name_Not_Found
16/06/23 03:01:21.82 .net
レベルが高い（笑）
40:Name_Not_Found
16/06/23 03:02:01.63 .net
レベルが高い（笑）
27 名前：Name_Not_Found[sage] 投稿日：2016/06/22(水) 21:23:37.27 ID:???
jQuery([a,b,c])
28 名前：25[] 投稿日：2016/06/22(水) 21:41:22.02 ID:0C9LwOLq [3/3]
>>27
ありがとうございます。出来ました。
自作自演バレバレなんだよなぁ
41:25
16/06/23 03:20:45.17 P9mZ3YME.net
とりあえず、>>27は私ではないという事は伝えておきます。
>>28は私の確認ミスですので言い訳するつもりはありませんが、>>27,30には回答してくれた事に感謝しています。
私にとっては回答の正誤はどうでもよく、最終的に最適解に辿りつければ良いのです。
質問や回答に優劣をつける事に価値はありません。
42:Name_Not_Found
16/06/24 15:01:59.27 .net
reduceは可読性落ちてないよなあ
これで可読性落ちるっていうならreduceを理解してないだけ
jQueryにreduceないから知らんのかもしれんけど
43:Name_Not_Found
16/06/24 18:02:13.52 .net
Array.fn.concatを独自定義するのが現実的かねえ
上でreduceが挙がったけど、jQueryは配列操作関数としては物足りないところがあるよね
44:Name_Not_Found
16/06/24 18:08:07.52 .net
$.merge() を合成に使うのは危険な気がするがどうだろう?
あくまで配列的に合成してしまうのでは
45:Name_Not_Found
16/06/24 18:12:48.39 .net
>>44
ArrayLikeObjectを引数にとるから大丈夫だよ
URLﾘﾝｸ(api.jquery.com)
46:Name_Not_Found
16/06/24 18:21:07.31 .net
>>45
いや、そっちじゃなくて
添字とlength以外が適切に処理されないのではと
たとえば.add() の場合は前回選択している部分が残されて
.end() で取り出せるわけだけどそういう処理が行えないんではないかな
47:Name_Not_Found
16/06/24 18:35:32.18 .net
>>46
ごめん、何を言ってるのかわからなかった
>>34の実装ならどちらも a を基本としているから a にあるプロパティは引き継がれると思うんだけど、どういうコードで弊害が発生するんだろう？
48:Name_Not_Found
16/06/24 18:51:55.48 .net
>>46
わかった、こういう事ね
end()を使わなければ弊害がなさそうだけど、それが嫌ならadd()をreduceのコールバック関数に持ってくるしかなさそうだね
var abc = jQuery(a);
[abc, b, c].reduce(jQuery.merge);
console.log(abc); // [#a, #b, #c]
console.log(abc.end()); // new Object
var abc = a.add(b).add(c);
console.log(abc); // [#a, #b, #c]
console.log(abc.end()); // [#a, #b]
49:Name_Not_Found
16/06/24 18:58:52.25 .net
end()はslice()で代用できると思うが、どうだろう？
abc.slice(0, -1);
50:Name_Not_Found
16/06/24 19:12:51.87 .net
.end()は例えば現状ではって話で
(jQuery的にやっていいのかわからないけど)プラグインで内部に値を持つとか
将来jQueryが機能拡張されて…
とかいう意味での危険ね
まあ、そうなっていると認識していればOKかなあ
51:Name_Not_Found
16/06/24 21:18:12.98 .net
>>50
前方互換性を考慮するならjQuery APIを使ってマージ処理を実装した方がいいと思う
>25のケースなら.add()か.pushStack()を使えばいいね(関数一つで実装する条件は満たせないけど)
ちなみに、jquery-3.0.0.jsのコードはこんな感じ
add: function( selector, context ) {
return this.pushStack(
jQuery.uniqueSort(
jQuery.merge( this.get(), jQuery( selector, context ) )
)
);
},
> (jQuery的にやっていいのかわからないけど)プラグインで内部に値を持つとか
その設計だと.add()で引き継がれるか不明だし、filter()のような非破壊系メソッドでは引き継がれないよね
必要ならプラグイン作者側で破壊的メソッドだけでも値が引き継がれるように設計してもらわないといけない
「将来jQueryが機能拡張されて… 」を考慮するならやってはいけない設計だと思う
安全に設計するなら.data()を使うか、DOM側に値を持たせる
> まあ、そうなっていると認識していればOKかなあ
同意
コーダー側でもある程度はjQueryオブジェクトの設計を知っているべきだと思う
52:Name_Not_Found
16/06/24 22:05:33.72 .net
つまり最善策（わかりやすく、最小の実現方法）はどれ？
53:Name_Not_Found
16/06/24 22:12:24.42 .net
>>42
> reduceは可読性落ちてないよなあ
> これで可読性落ちるっていうならreduceを理解してないだけ
reduceを理解していれば、reduceの戻り値を
捨てるなんてありえないと思うがね。
reduceの機能を理解しているかどうかじゃなくて、
reduceはどういうときに使うものかっていう話だよ。
例えばmapかいてmapの戻り値を捨てるようなもんだよｗ
最初からeach使えという話。
54:Name_Not_Found
16/06/24 22:14:03.54 .net
>>52
素直にaddを二回使う
55:Name_Not_Found
16/06/24 22:28:42.60 .net
>>53
reduceは一つの値を連続処理する関数なのだから返り値を使わなくてもいいんだよ
返り値を使えばもっと短く書けるけど、「可読性を低くしてまで」は関係ない
var abc = [b, c].reduce(jQuery.merge, jQuery(a));
56:Name_Not_Found
16/06/24 22:32:23.38 .net
>>55
関数型を理解してくださいとしか言いようがないな。
関数型言語から来たものなのに副作用に依存するとか
ちょっとセンスがわるい
57:Name_Not_Found
16/06/24 22:54:38.28 .net
>>56
君にセンスを理解してもらう必要はないんだけど…、頭が固いと大変だね
58:Name_Not_Found
16/06/24 22:56:52.88 .net
というか、>>55は返り値を使ってるけどね
自分の世界観から抜けられないだけのような
59:Name_Not_Found
16/06/24 23:00:47.05 .net
さっきこっちに正しい使い方を書きましたよｗ
ｽﾚﾘﾝｸ(hp板:90番)
60:Name_Not_Found
16/06/24 23:13:34.05 .net
>>59
冗長合戦したいなら$()が冗長だから出直しておいで
61:Name_Not_Found
16/06/24 23:42:03.03 .net
この程度で冗長とか正しい書き方とか、偏執的にも程がある
62:Name_Not_Found
16/06/25 11:16:14.64 .net
割合的には大きいけどなｗ
63:Name_Not_Found
16/06/25 13:44:37.05 .net
コードだけ読んで批判は聞き流せばいい
相手の為を思って叱ってくれる人も中にはいるが、こいつのはただjQueryスレに誘導するためにこき下ろしているだけだからな
64:Name_Not_Found
16/06/25 13:45:16.35 .net
jQueryの話題をjQueryスレに誘導することに
なんの問題があるんだ？ｗ
65:Name_Not_Found
16/06/25 14:13:27.67 .net
ライブラリスレでjQueryの質問しても何の問題もない
荒らしのたてたスレに誘導する必要もない
66:Name_Not_Found
16/06/25 14:23:09.08 .net
そしたら今度はこっちがjQueryで占領されるわからないのかなぁ？ｗ
67:Name_Not_Found
16/06/25 14:24:16.13 .net
こっちはjQueryを含めるライブラリ全部のスレ
向こうはJavaScriptとjQueryのスレってことでいいじゃないか
68:Name_Not_Found
16/06/25 16:09:08.85 .net
一々そいつにレス返さんでいいから
69:Name_Not_Found
16/06/25 16:16:18.58 .net
レス返そうが返すまいが、会話してるんだがなｗ
70:Name_Not_Found
16/06/25 17:18:17.02 .net
ｗｗｗ
71:Name_Not_Found
16/06/25 18:15:36.63 .net
独り相撲乙
72:Name_Not_Found
16/06/25 21:22:01.73 .net
>>71
お前もその一人なのか？
73:Name_Not_Found
16/06/26 08:03:10.80 .net
>>67
タイトルで誤魔化してるが、向こうはただのjQueryスレ
JavaScriptの質問はスレ違い
74:Name_Not_Found
16/06/26 12:24:49.47 .net
jQueryはJavaScriptなんだが・・・
75:Name_Not_Found
16/06/26 12:33:39.05 .net
ふたを開けてみれば、jQuery 3.0はあまり変わってないな
もっと思い切ったAPI変更が欲しかったら
76:Name_Not_Found
16/06/26 17:09:26.10 .net
>>75
もう完成されているんだよ。
アドビ イラストレータと同じww
77:Name_Not_Found
16/06/26 23:02:49.40 .net
基本的に後方互換性重視だな
Deferedを廃止してPromiseを使うとか、classListを実装するとか、eachをforEach互換にするとか、標準に近づけてほしかったな
78:Name_Not_Found
16/06/26 23:14:41.33 .net
>>77
互換性をなくしてまで仕様を変える意味は？
79:Name_Not_Found
16/06/26 23:25:01.53 .net
学習コストの低下と汎用性じゃない？
メジャーバージョンアップで互換性がなくなるなんて良くあること
個人的にはDeferedはPromiseに変えて良かった気がしないでもない
80:Name_Not_Found
16/06/26 23:31:57.50 .net
>>79
> 学習コストの低下と汎用性じゃない？
学習コストは一度覚えればいいだけ
過去のソースを書き換えるほうが手間がかかる。
汎用性は意味不明。標準よりも高機能のほうが汎用性は高いし。
81:Name_Not_Found
16/06/26 23:32:16.43 .net
> 個人的にはDeferedはPromiseに変えて
機能が低下している。
82:Name_Not_Found
16/06/26 23:34:20.43 .net
PromiseはAndroid4.4が非対応だからな。
標準のPromiseを使うことはできないのだ。
83:Name_Not_Found
16/06/27 10:26:54.82 .net
> 学習コストは一度覚えればいいだけ
さすがにこれはない
jQuery一色に染まってるな
84:Name_Not_Found
16/06/27 11:00:08.45 .net
多機能が必ずしもいいとは限らんのよ
Promiseは内部的にPolyfillを作ればいいだけでPromisesの実装が進めばPolyfillは削除できる
event.pageXの独自拡張が削除されたように標準を使ってもらう形の進化は有りだと思う
85:Name_Not_Found
16/06/27 12:13:30.70 .net
slim版で$.ajax()が削除されたのはFetch APIの実装が整ったら削除するための布石かな
実装が整ったからAPI削除ってjQuery 3.0でもいくつかあったよね
86:Name_Not_Found
16/06/27 13:06:01.35 VxsZQDB5.net
>>85
kwsk
87:Name_Not_Found
16/06/27 14:05:54.34 .net
>>13にまとめられてなかったっけ？
削除されたAPIはajaxのcompleteが記憶に新しいが
$.parseJSONの非推奨も次で削除する為の準備段階な印象
88:86
16/06/27 17:29:54.68 .net
>>87
ありがとうございます。
リンク先参照します
89:Name_Not_Found
16/06/27 20:27:57.51 .net
>>84
> Promiseは内部的にPolyfillを作ればいいだけでPromisesの実装が進めばPolyfillは削除できる
それをいうなら、jQuery 3.0のDefferedはPromise互換なので、
Promiseを使ってDefferedを実装すれば良いだけ。
90:Name_Not_Found
16/06/27 20:32:07.43 .net
>>85
Fetch APIはあまり関係ないと思うよ。
Slim build
URLﾘﾝｸ(blog.jquery.com)
> Finally, we’ve added something new to this release. Sometimes you don’t need ajax,
> or you prefer to use one of the many standalone libraries that focus on ajax requests.
> And often it is simpler to use a combination of CSS and class manipulation for all your
> web animations. Along with the regular version of jQuery that includes the ajax and
> effects modules, we’re releasing a “slim” version that excludes these modules. All in all,
> it excludes ajax, effects, and currently deprecated code. The size of jQuery is very rarely
> a load performance concern these days, but the slim build is about 6k gzipped bytes
> smaller than the regular version ? 23.6k vs 30k. These files are also available in the npm package and on the CDN:
要するにjQueryをDOM用のライブラリだけとして使いたい人のため。それで6KBのサイズ削減ができる。
Ajax関連はいろんなライブラリに搭載されてるから機能が重複しやすかった。
91:Name_Not_Found
16/06/27 20:33:44.61 .net
>>85
> 実装が整ったからAPI削除ってjQuery 3.0でもいくつかあったよね
実装が整ったという理由で消えたAPIはないよ。
jQueryの互換性は高い。
jQueryはDOM APIよりも使いやすいという利点のライブラリなんだから
実装が整った程度じゃAPI削除する理由にはなりえない。
92:Name_Not_Found
16/06/27 23:47:20.35 .net
>>89
> Promiseを使ってDefferedを実装すれば良いだけ。
Promiseをprototype拡張するつもりか
93:Name_Not_Found
16/06/27 23:49:47.97 .net
>>92
prototype拡張は駄目なやり方だという設計してるのがjQueryなんでぇ。
当然jQueryと同じようにラップするに決まってるでしょう（笑）
94:Name_Not_Found
16/06/27 23:52:11.18 .net
そもそもDOM APIはPromiseを使うべきだろうな。
将来はイベントハンドラとか全部Promiseに置き換わるはず
95:Name_Not_Found
16/06/28 03:03:59.63 .net
ん？標準のPromiseにprogressってあったっけ？
標準のPromiseは基本機能しかサポートしてないから
普通はQとかを使うのが常識だと思ってたが。
96:Name_Not_Found
16/06/30 19:26:37.06 .net
>>93
Promiseをラップするぐらいなら、現行のPrpmise互換オブジェクトの方が数段マシだと思うが
拡張部分とPromise互換部分の整合性をとるのが面倒で内部的にPromiseを使うメリットが感じられん
97:Name_Not_Found
16/06/30 21:16:01.84 .net
そもそもさ、notifyとprogressの事を忘れてないか？
URLﾘﾝｸ(blog.toshimaru.net)
> deferredへ通知する: notify()とprogress()
>
> jQuery1.7からresolve/rejectに加えて、progressが導入された。、
> progress()により、deferred内でnotify()がコールされたときに実行される
> コールバック関数を登録することができ、resolved状態に対する「進捗(progress)」を
> 表現できるようになった。notify()で事前にコールバックを登録しておくことで例えば、
> ロードに時間がかかるリソースを持つdeferredオブジェクトの定期的に更新されるプログレスバーを描画できる。
> deferredはロード中に通知(notify)され、ロード完了時に解決(resolve)される。
jQueryでDeferredを使ってる所っていうのはAjax通信の部分だけだと思うが、
Ajax通信を置き換える目的ならば、XMLHttpRequestにあるprogress相当の機能を実装する必要がある。
ってことは素のPromiseオブジェクトでは明らかに機能不足なんだよ。
そういう前提において、DefferedにPromiseと互換性を持たせる（jQuery 3.0で実現したこと）のではなく
Promiseを使えって言うならば、足りない機能を実装するしか無いだろ。
そして>>96の言うとおり標準のPromiseをラップして使うメリットはないので
DefferedのままPromiseと互換性をもたせるのが一番すぐれたやり方なわけだよ。
98:Name_Not_Found
16/06/30 21:35:32.91 .net
そもそも、「>>77や>>84が目指しているゴール」と「現行jQuery擁護派のゴール」が違いすぎるので議論にならない
反論するなら相手の立場になって反論しないとな
でなければ、ただの宗教戦争だ
99:Name_Not_Found
16/06/30 22:35:07.88 .net
まあ確かに、Promise派としてはprogressはXMLHttpRequestと同じ方法で実装してくれれば満足するだろうね
100:Name_Not_Found
16/06/30 23:24:13.58 .net
>>98
そうか？単に標準のXMLHttpRequestで必要とされている機能を
満たすにはPromiseの機能だけでは不足しているから
拡張する必要があるってことに気づいているかどうかだと思うぞ。
101:Name_Not_Found
16/06/30 23:31:44.96 .net
>>99
XMLHttpRequestと同じ方法ってことは、
Promiseを返さないってこと？
102:Name_Not_Found
16/07/01 00:02:35.71 .net
>>101
そういうことになるね
>>97はjQueryの既存概念にとらわれすぎているようだけど、DOMのInterfaceで実装する仮定で想像してみればいいたい事の大体はわかると思うよ
そもそも、Ajaxの返り値の話なんて誰もしてないから
103:Name_Not_Found
16/07/01 00:22:07.78 .net
Promiseを返せと言ったりPromiseを返すなと言ったり
意味不明だなｗ
結局のところPromiseを使う理由はないってことか。
互換性を切るなんてもっての外だし、
あえて互換性を切ってまでDefferedの仕様を変える意味はないし、
やはり今の仕様が一番最善ってことか。
104:Name_Not_Found
16/07/01 00:36:33.62 .net
>>103
独り合点してないでもう一度、読み直して来たら？
jQuery.Defered === Promise && ajax() !== jQuery.Defered
105:Name_Not_Found
16/07/01 00:50:51.45 .net
だからFetch APIっていうのがあるんだよ。
互換性の問題があるからjQueryは仕様を変えてはいけない。これは大前提。
そして標準でXMLHttpRequestをPromiseベースに改良したFetch APIが普及しつつある。
最新版のSafariやAndroid 4系やIEで動かなかったりするからまだ乗り換えることはできないけど、
これを使えばjQueryでDeferredを使うもの＝Ajax関連は必要なくなる。
だからjQuery 3.0ではAjax関連を取り除いたSlim buildっていうのを用意した。
Promiseを使いたいならjQuery 3.0 Slim build + Fetch APIを使えばいいだけなんだから
互換性を切ってまでDeferredをやめてPromiseに変える合理的な理由はないでしょ？
Slim buildを用意することでPromiseベースのAjax通信（つまりFetch API）への移行を
サポートしてるわけでDeferredを使っていることは失望するポイントにはならないんだよ。
元来jQueryはブラウザ間の互換性を吸収するためにも用いられてきたけど、
本質を理解している人はわかってると思うけど、互換性を吸収する部分は実はおまけ機能で
真の姿は関数型風のDOM操作ライブラリ。今それになろうとしているということ。
だから関数型の考え方を理解して使いこなせる人だけがjQueryの凄さを理解できる。
jQueryに意味がないと言ってる人は、関数型の考え方を理解していないはず。
106:Name_Not_Found
16/07/01 00:54:14.73 .net
>>104
読み直した。それであなたが言いたいポイントは？
107:Name_Not_Found
16/07/01 07:49:13.76 .net
>>106
君は「相手の立場で物事を考える」って出来る？
「インデントにタブ/半角スペースのどちらを使うべきか」の命題でタブ派が半角スペース派に「誰でも納得出来る明確なメリット」を主張できると思う？
元々の立ち位置が絶対的に違うのに、自分の立場でしか物事を考えられない人は議論に向いてないと思うよ
108:Name_Not_Found
16/07/01 22:30:39.03 .net
>>107
What your point ?
109:Name_Not_Found
16/07/01 22:42:09.19 .net
議論したいなら、少なくとも聞かれたときには
自分が言いたいポイントを明確に答えられなければならない。
それが言えないってことは、そもそもお前は議論していない。
110:Name_Not_Found
16/07/02 08:37:53.99 .net
>>108
>>104が読めないの？
ajaxの返り値がPromiseでなく、jQuery.Defered === Promise であればいいでしょ
>>103の「結局のところPromiseを使う理由はないってことか」は文意を読めてないだけでしょ
いい加減、疲れるんだけど
111:Name_Not_Found
16/07/02 08:51:41.49 .net
あと、>>107もいいたいことの一つなんだけどね
>>77に対して「jQueryマンセー」な反論を返すのはただの思想の押しつけ
明らかな間違いを是正するならともかく、どちらが正しいという問題でもないよね
なぜそこまで確信的な論調になるのか、俺には理解できないよ
112:Name_Not_Found
16/07/02 10:44:07.42 .net
> ajaxの返り値がPromiseでなく、jQuery.Defered === Promise であればいいでしょ
なんで互換性をなくしてまでPromiseにしないといけないのかわからん。
PromiseはDeferredに比べてprogressの機能が足りない。
だからPromiseに置き換えることはできない。
jQuery 3.0でDeferredはPromiseと互換性があるものになった。
だからPromiseではなくても互換性があるDeferredで十分って話だろ。
それにPromiseをサポートしてないブラウザはどうするのか？
jQuery自身にPromiseのpolyfill機能でも搭載するのか？ｗ
提案してみれば？jQueryにPromiseのpolyfill機能を付け加えて
DeferedをPromiseに変えて互換性を壊しましょうってｗ
互換性がないものに変わることで、既存のコードを書き換えないといけないならば
Fetch APIに変更すればいいだけじゃないか。そのためにjQueryはSlim Buildを用意したというのに。
>>111
あのさ（苦笑）jQueryの機能が素晴らしいって言ってるんじゃなくて
jQueryの選択は正しいって言ってるの。論理的にね。
どうもjQueryを擁護したら、なんにも考えずにjQueryを叩くやつがいるよな。
jQueryに親でも殺されたか？ｗ
113:Name_Not_Found
16/07/02 13:25:10.19 .net
>>112
思想の違いってものが理解できないタイプなんだね
他人の思想にいちいち噛みつく辺りが嫌われてるのが理解できないか、理解した上でスルーしてるのか知らないけど
俺からすれば君はjQueryの布教活動しているようにしか見えないけどね
114:Name_Not_Found
16/07/02 13:50:03.82 .net
思想の違い？
互換性を保ちましょう。（Deferredの仕様は変えない）
標準への対応をしましょう。（DeferredのPromise互換）
将来への対応をしましょう。（Ajax部分を取り除いたSlim Buildの作成）
が俺とjQueryの思想だが、
じゃあお前の思想は？ｗ
お前の思想は何も考えずに適当に思いついたことを言ってるだけだろｗ
115:Name_Not_Found
16/07/02 16:53:39.12 .net
布教活動もクソも延々と啓蒙（）で荒らしてるやつじゃん
116:Name_Not_Found
16/07/02 17:56:40.15 .net
啓蒙はしてるが荒らしはしていない。
jQueryの話題をすることが荒らしというならば
それはお前がjQueryが憎いだけだｗ
ここはjQueryの話題OKのスレのはずだがね
117:Name_Not_Found
16/07/02 17:57:55.63 .net
URLﾘﾝｸ(dictionary.goo.ne.jp)
［名］(スル)《「啓」はひらく、「蒙」はくらいの意》人々に正しい知識を与え、
合理的な考え方をするように教え導くこと。「大衆を―する」「―書」
118:Name_Not_Found
16/07/02 18:36:09.47 .net
>>114
・標準のAPIを使いましょう
・標準に準拠する為なら後方互換性は切り捨てても構いません
119:Name_Not_Found
16/07/02 18:47:02.96 .net
> ・標準のAPIを使いましょう
何のために？
念の為に言っておくけど、 jQueryの本質は
DOM操作を関数型風にやること。
で標準のAPIっていうのはFetch APIのことだと思うけど、
jQuery（Slim build） + Fetch APIをすればいいよね？
jQueryは本来の用途であるDOM操作に専念させる。
Fetch APIを使えばいいのに何のために中途半端な対応を選んでいるの？
$.ajaxの戻り値だけをPromiseに変更するの互換性を切り捨てているのに
中途半端対応でしか無いんだけど
jQueryの標準への対応方法（Slim build）ではなくて
中途半端な対応をするべきだという合理的な理由を言ってくれ。
120:Name_Not_Found
16/07/02 18:48:03.24 .net
標準のAPIを使いましょうといわれても
標準のAPIを搭載していないブラウザがあるよね
Android 4.4とか
121:Name_Not_Found
16/07/02 19:11:11.43 .net
jQueryのDeferredがPromiseと互換性がある
ってことの意味を理解してないんじゃないだろうか？
互換性があるからこのようにPromiseとDeferredは混ぜて使える。
URLﾘﾝｸ(jsfiddle.net)
function timeout(ms) {
return new Promise(function(resolve, reject) {
setTimeout(function() {
resolve();
}, ms);
});
}
console.log('start')
timeout(3000).then(function() {
console.log('get')
return $.get('/');
}).then(function(html) {
console.log(html.split("\n")[0])
console.log('wait')
return timeout(3000);
}).then(function() {
console.log('end')
});
122:Name_Not_Found
16/07/03 13:43:15.42 .net
ここまで完璧な論破は珍しいなｗ
123:Name_Not_Found
16/07/04 12:15:02.16 .net
論破してる気になってるのは本人だけだがな
124:77
16/07/04 12:47:33.18 G9XXx5Kd.net
まだやっているのか…
反論してる奴は話にならん
jQuery3.0が後方互換性重視な事は>>77で指摘済み
現行jQueryの思想から外れている事は百も承知
標準に合わせるメリットは「学習コスト」と「コードの可搬性」だけで十分だ
上の掛け合いは保守派と革新派が言い争っているに過ぎない
お互いの理想の形が一致しない議論に参加するのは時間の無駄
125:Name_Not_Found
16/07/04 17:05:13.05 .net
jQueryの人は文体が特徴的だからすぐ分かる
126:Name_Not_Found
16/07/04 21:37:24.70 .net
>>125
文体が似ているやつは全員一緒ですよねｗ
127:Name_Not_Found
16/07/04 21:44:44.24 .net
>>124
> 標準に合わせるメリットは「学習コスト」と「コードの可搬性」だけで十分だ
だから標準＝Fetch APIでしょ？jQueryとFetch APIを組み合わせて
使っていいんだよ？そのためのSlim Buildなんだから。
お前が言ってるのは、標準のFetch APIではなくてjQueryのAjaxを使うことで
学習するコストが必要になるが、戻り値がPromiseだと（一部の）学習コストがさがる
って言ってるから謎なんだよ。Fetch API使ったほうが明らかに学習コストは減るだろ。
俺はFetch APIを使うのが一番学習コストが下がるからjQueryはそのままでいいって言ってる。
新しく使う人はFetch APIを使うだろうし、そうでない人、jQueryのAjax機能をすでに使ってる人は
当然今までのDefferedの知識があるからこちらも学習コストが下がる（正確には上がらない）
あとコードの可搬性で言えば、Android 4.4はどうする？Promiseはどこでも動くわけじゃないぞ。
PromiseのPolyfillライブラリを導入しろって？俺ならFetch APIのPolyfillごと導入するがねｗ
128:Name_Not_Found
16/07/04 22:14:34.35 .net
>>125
面倒くさいから名前もIDも書くつもりはないけど別に隠すしてないよ？
だから、わかると言われても・・・。
もしかして見抜いたり！とか思ってる？
129:Name_Not_Found
16/07/04 22:39:18.60 .net
あ、それからもう一つあった。
jQueryのDefferedがPromise互換になった今
どんな学習コストがかかるのかも聞いてなかったね。
130:77
16/07/04 23:21:08.45 OUGP5uwu.net
>>127
お前が問題にしているのは「jQuery.ajaxの返り値」であってPromiseは関係ない
ajaxの返り値はjQuery.DeferredでもPromiseでもない抽象オブジェクトで十分だが、それは別の話だ
お前が勝手に話を広げただけ
131:Name_Not_Found
16/07/04 23:38:18.14 .net
>>130
jQueryでPromiseが使われてるのはajax関連（getやpost含む）ぐらいなもんだろ。
少なくとも俺はajax関連以外でDeferredを使った記憶はない。
他にjQueryの一体どこでDeferred使えっていうんだよｗ
ajaxを標準にしろって言うならば、Fetch APIを使えばいいわけで
非標準のjQueryのajax と 標準のPromiseを混ぜる理由がない。
それに結局Android 4.4はどうするのかにも答えてないし。
132:Name_Not_Found
16/07/04 23:38:38.95 .net
訂正
jQueryでDeferredが使われてるのはajax関連（getやpost含む）ぐらいなもんだろ。
133:77
16/07/04 23:43:30.42 OUGP5uwu.net
>>129
別にPromiseだけに拘ってはいない
お前がしつこいほどに「jQuery.ajaxの返り値」を論旨に置いてるだけだ
Promiseについては前方互換性、可搬性が主だが、「Promise.allがjQuery.jQuery.Deferred.allに存在しない」もあるので学習コストが同じわけではないだろうな
134:Name_Not_Found
16/07/04 23:50:15.27 .net
>>133
あー、なるほどねｗ やっとわかったわ。
お前、Promise.all みたいに Deferred.allしたいと思ってるだろｗ
そんなのする必要ねーよ？
jQueryを使っていてDeferredが出てくるのは戻り値としてだけ。
自分でDeferredオブジェクトを作る必要はない。（作りたいなら作ってもいいがね）
っていうかなんのために作るのさ？ｗ
Promise.allを使いたければ、Promise.allをそのまま使え。
その引数にDeferredオブジェクトを渡すことができる。
互換性があるからね。
135:77
16/07/04 23:53:03.25 OUGP5uwu.net
>>131-132
> jQueryでDeferredが使われてるのはajax関連（getやpost含む）ぐらいなもんだろ。
それはお前が自前でPromiseを使った非同期処理を書いたことがないからそう思うだけだ
何の為にjQuery.Deferredが公開APIになっているのか、を良く考えろ
136:Name_Not_Found
16/07/05 00:02:05.86 .net
>>135
> それはお前が自前でPromiseを使った非同期処理を書いたことがないからそう思うだけだ
そういうレスするってことは>>134は正しかったようだなｗ
レスするならそうじゃなくてお前がいつどこでjQuery.Deferredを使うのか答えてほしいもんだがｗ
jQuery.DeferredがでてくるのはjQuery ajax関連の戻り値としてだけ。理解した？OK？
> 何の為にjQuery.Deferredが公開APIになっているのか、を良く考えろ
いや、単に世の中にPromiseが普及する前（標準化される前、ブラウザに搭載される前）に
jQuery.Deferredが世に出ただけの話だけど？？？
お前は何のためだと思ってたんだい？
URLﾘﾝｸ(api.jquery.com)
The Deferred object, introduced in jQuery 1.5,
URLﾘﾝｸ(blog.jquery.com)
jQuery 1.5 Released Posted on January 31, 2011 by John Resig
URLﾘﾝｸ(caniuse.com)
Firefox 27, Chrome 32 Partial Support
2014年01月15日 11時39分 更新 「Google Chrome 32」の安定版リリース
URLﾘﾝｸ(www.itmedia.co.jp)
URLﾘﾝｸ(ja.wikipedia.org)
> 2014年2月4日にリリースされ、
137:Name_Not_Found
16/07/05 00:11:14.01 .net
jQuery.Deferredオブジェクトを戻り値ではなく自分で作成したのは
iframeを使ったときにページがロードされたあとを検出するときに使ったぐらいかな。
古いブラウザまで考えるとiframeのページロード後の検出は意外と面倒だったんだよね。
onloadが変なタイミングで発生したりOperaがページロード前はabout:blank状態だったりとか。
Promise（Deferred）はresolveになった後に変化できないから、
clickみたいに何度も発生するイベントでは使えないしね。
今ならPromiseを使うだろうけど、昔はPromiseはブラウザに搭載されてなかったし。その頃の話だよ。
Polyfillもあったかどうか怪しい。jQuery使ってたからDeferredを使うのが楽だった。
で、jQuery.Deferredが出てくるのはajax関連の戻り値としてだけで自分で作る必要はなく
互換性があるのでjQuery.DeferredとPromiseを混ぜて使えばOKなので、
最初から言っているとおり、jQueryは今の状態が一番適切だと思うが？
標準が使いたければ、Ajax関連ごとFetch APIに置き換えればよい。そのためのjQuery 3.0のSlim build。
138:77
16/07/05 00:46:59.98 sEI91sKd.net
>>134
jQuery.Deferredは自前でDeferredオブジェクトを作れるようにする為に存在するのであってそれ以上でもそれ以下でもない
お前が「jQuery.Deferredを使う必要がない」というならお前と議論するのは時間の無駄だ
jQuery.Deferredが要らんというならさっさと廃止するようにリクエストしろ
「お前が必要と思うもの」を他人に押し付けるな
139:Name_Not_Found
16/07/05 02:16:25.93 .net
>>138
なに一人で空回りしてるんだよｗ
「お前が必要と思うもの」を押し付けてるのはお前だろ。
jQueryのDeferredをPromiseに変更することが必要なんだろ？ｗ
俺は現状維持でいいと言ってるの。なにも必要と思ってない。
jQuery.Deferredは自前でDeferredオブジェクトを作れるようにする為に存在するのであって
それ以上でもそれ以下でもないから、「自前でDeferredオブジェクト絶対に作らなければいけないんだ！」って
思うお前がおかしい。作れるからって作らなければいけないわけじゃないんだよｗ
もちろんjQuery内部では作る必要があるから作っているだろうが、
それをPromiseに置き換えるならば、Andorid 4.4などでPromiseをサポートしてないから
jQueryは自前でPromsiseを実装しなければいけなくなる。
その自前実装の亜種がDeferredでありPromiseと互換性があるオブジェクト
あれ？ お前の願い叶ってね？ｗ
お前がなにを言いたいのかさっぱりわからんね。現状維持でなにが悪い？
お前の根本的な間違いは、jQuery.Deferredを使ってjQuery.Deferredオブジェクトを作るときの
使い方が違うから、学習コストが～って言ってるだけだろ？
だがそもそも（jQuery内部以外では）jQuery.Deferredを（今の時代は）使う必要がないから
学習コストもなにもねぇだろ。
新しく使う人→Fetch API使うからDeferredの学習コストは0
前から使ってる人→すでに知ってるからDeferredの学習コストは0
現状維持ならどちらの人でも学習コスト0だろ。
むしろお前の言うようにajaxの戻り値をPromiseにしたほうが互換性なくなるから
その違いを埋めるための学習コストやコード修正コストがかかるんだが。
もう少し論理的に考えな。お前は一体どうしてほしいんだ？
140:Name_Not_Found
16/07/05 02:29:02.21 .net
> jQuery.Deferredが要らんというならさっさと廃止するようにリクエストしろ
重要なのはDeferredがPromise互換になることであって
Deferredをなくすことじゃないんだよ。
DeferredがPromise互換になることで、Promise.allなどの引数に使えるようになる。
そしてDeferredがPromise互換になることは実現済み。
だからこれ以上Deferredを変える必要はない。
むしろDeferredいらん、Promiseに変えろと言っていたのは
お前だったはずだが？廃止するようにリクエストしろよｗ
141:77
16/07/05 09:54:07.13 .net
>>139
> 「お前が必要と思うもの」を押し付けてるのはお前だろ。
お前は俺に反論してきたが、俺はお前に何も要求していない(不当な反論があれば釈明はする)
例えば、>>124の「Promise.allをそのまま使え」は余計なお世話だ
(これにはさすがにカチンときて「jQuery.Deferredを廃止するようリクエストしろ」と要求したが、本意ではない)
jQuery.Deferredを使うならjQuery.whenで事足りるからな
「jQuery.Deferredを（今の時代は）使う必要がない」とかいうお前の勝手な考えはどうでもいい
> 新しく使う人→Fetch API使うからDeferredの学習コストは0
お前が何度も指摘しているFetch APIもまるで関係がない
>>130に書いたようにajax()の返り値がPromiseになることを望んでないからな
お前は異常なほどに「jQuery.ajaxの返り値」に拘っているが、俺は一言もajax()には触れてない
> jQueryは自前でPromsiseを実装しなければいけなくなる。
その通り
jQuery.DeferredはPromiseのPolyfillであれば良い
ここまでの流れは基本的には>>111の指摘通り
俺は俺の思想を主張するが、お前はお前の思想を主張するだけ
思想の違いを理解するために説明しあうことは有意義だが、相手の思想を撤回させようとするのは無駄な事だ
お前はそれをしようとしてる
142:Name_Not_Found
16/07/05 14:39:59.02 .net
jQuery.Deferredを廃止してjQuery.Promiseが実装されれば>>77の望みは達成できるのかもしれないね
143:77
16/07/05 15:23:18.67 sEI91sKd.net
>>142
確かにjQuery.Deferredを書き換えるよりも現実的だな
144:Name_Not_Found
16/07/05 22:04:58.42 .net
>>141
> 例えば、>>124の「Promise.allをそのまま使え」は余計なお世話だ
なぜ？ Promise.allを使いたければ、標準のPromise.allを使えばいいだろ？
なんでそこで、Deferred.allを使いたいと思ったんだ？
> jQuery.Deferredを使うならjQuery.whenで事足りるからな
事足りるんじゃなくて、えとな。話聞いてる？
DeferredはPromsieが登場するよりも前に生まれたの。
事足りんじゃなくて、当時はそれを使うしかなかった。
今はPromiseがあるから、それを使えばいいだろ。
DeferredはPromiseと互換性があるのだから
Promiseのように使うことができる。
jQuery.Deferredオブジェクトを"作る" ときにはPromiseの作り方と違うから
学習コストはいるが、そこでちょっと待てって話だよ。
jQuery.Deferredオブジェクトを作ることがあるのかと。
答えは "ない" だ。昔（Promiseがなかった時代）はjQuery.Deferredを汎用的なPromiseの代用として
使う事もあったかもしれないが、今はPromiseをそのまま使えばいいのだから、もはや作ることはない。
PromiseとDeferredのオブジェクトの作り方は違うが作ることはないのだから学習コストも発生することはない。
今はjQueryのAjax関連の戻り値として、Promiseオブジェクトと互換性のあるDeferredのオブジェクトが
でてくるだけでその戻り値はPromiseオブジェクトであると思って使えば良い。互換性がある。
だから学習コストはかからない。
現状でお前の言う学習コストはどこにもかからないんだよ。
> 「jQuery.Deferredを（今の時代は）使う必要がない」とかいうお前の勝手な考えはどうでもいい
それをいうなら、お前の勝手な考えはどうでもいいｗ
145:Name_Not_Found
16/07/05 22:07:06.43 .net
>>141
> お前は異常なほどに「jQuery.ajaxの返り値」に拘っているが、俺は一言もajax()には触れてない
お前がなぜajaxに触れていないかのほうが問題。
jQueryでDeferredがでてくるのはajaxの戻り値としてだけだ。
jQuery.ajaxの返り値に拘るなというのなら、じゃあ聞こう。
どこで Deferred がでてくるんだ？
お前は何にこだわっているのかという質問だよ。
146:Name_Not_Found
16/07/05 22:08:14.58 .net
>>142
> jQuery.Deferredを廃止してjQuery.Promiseが実装されれば>>77の望みは達成できるのかもしれないね
そこは>>77の望みってなんだよｗｗｗって笑うところだねｗ
さて何だったかねぇ。
147:Name_Not_Found
16/07/05 22:09:28.07 .net
何か目的があって>>77はjQuery.Promiseに変えろと言ってるわけじゃないんだよね。
jQuery.Deferredが気に食わないからjQuery.Promiseに変えろと言ってるだけ
気に食わないだけで、肝心の気に食わない理由がない。
148:Name_Not_Found
16/07/05 22:18:09.13 .net
「jQuery.Deferredを廃止してjQuery.Promiseが実装されれば>>77の望みは達成できるのかもしれないね」
>>77「確かにjQuery.Deferredを書き換えるよりも現実的だな」
「jQuery.Promiseが実装されれば何が嬉しいんだい？」
>>77「jQuery.PromiseはES6のPromiseと全く同じだから学習コストが下がる！」
「全く同じというのならPromiseをそのまま使えばいいのでは？」
>>77「・・・」
ここまでが想定済みの流れｗ
149:77
16/07/05 22:21:33.99 sEI91sKd.net
PromiseもFetch APIも実装されてないブラウザがある以上、素のままでは書けないのでPolyfillを適用する必要がある
jQueryを使うなら他にPolyfillライブラリを適用するコストをかけたくないからjQueryだけで完結できれば一番良いというだけ
俺の望みは>>124で書いたことですべて
お前に伝わってないようだが、釈明するのは時間の無駄だと悟ったのでもうしない
悪しからず
150:Name_Not_Found
16/07/05 22:25:07.59 .net
ちなみにDeferredをPromise.allの引数としてそのまま使えることの証明
URLﾘﾝｸ(jsfiddle.net)
function timeout(ms) {
return new Promise(function(resolve, reject) {
setTimeout(function() {
resolve();
}, ms);
});
}
Promise.all([
timeout(3000),
$.get('/'),
timeout(3000),
]).then(function(data) {
console.log(data[1].split("\n")[0])
});
151:Name_Not_Found
16/07/05 22:31:32.31 .net
>>149
> PromiseもFetch APIも実装されてないブラウザがある以上、素のままでは書けないのでPolyfillを適用する必要がある
> jQueryを使うなら他にPolyfillライブラリを適用するコストをかけたくないからjQueryだけで完結できれば一番良いというだけ
それについてはとっくにレスしたよね？
だからPolyfillを適用すれば良い。標準のFetch APIを使うならばjQueryをajax用途として
使う必要はない。だからjQuery 3.0でajax部分を取り除いたSlim buildができたわけ。
jQueryがいくら頑張ろうがPolyfillになることはない。$.Promiseとかになるんだから。
だからお前の目的であるはずの標準APIを使うことはできない。
jQueryでは標準APIと同等のものになることはないのに、
なんでお前はPolyfillではなくjQueryを使おうとしてるんだ？
そこが意味わからんよね。言ってることとやろうとしてることが矛盾してるだろ
標準大好きならば、標準APIのPolyfill + jQuery 3.0 Slim buildの一択だろ。
jQueryはDOM操作用のライブラリに専念させろよ。
152:Name_Not_Found
16/07/05 22:32:50.45 .net
>>149
> お前に伝わってないようだが、釈明するのは時間の無駄だと悟ったのでもうしない
それがいいんじゃね？ｗ
俺はお前の言うこと全てに対して反論をしている。
そしてお前は言い返すのをやめた。
万事解決ｗ
153:Name_Not_Found
16/07/05 22:40:40.79 .net
結局>>77が一番jQueryを使い続けたがってるってオチかｗ
jQueryが提供しているAPIにはjQuery.eachやjQuery.mapのように
当時は標準JavaScriptにはなかったが、今は標準で提供されている機能がある。
超古いブラウザのサポートが必要ならjQueryのメソッドを使うが
そうでない場合には俺は標準のメソッドを使っているよ。
Promiseも同じ扱いだろ。現在非対応のブラウザにも対応する必要があるなら
jQuery.Deferred（もしくは PromiseのPolyfill）を使うことになるが、
近い将来Promiseを使えば良くなる。jQuery.Deferredを使う必要はない。
その今の時代においてjQuery.Promiseに仕様変更してまで
jQuery.Promiseを使いたいっていう考えが意味不明。
素直に標準のPromiseを使えばいいじゃねーかw
154:Name_Not_Found
16/07/06 12:07:53.48 .net
意味不明なら無理に反論しなけりゃいいのに
ここは相変わらずだな
155:Name_Not_Found
16/07/06 12:56:19.98 .net
荒らしに餌やってる>>77も似たようなもんだよ
156:Name_Not_Found
16/07/06 22:24:18.87 .net
>>154
「意味不明なら無理に反論しなけりゃいい」っていう考えがおかしい。
意味不明なことを言っているのなら、意味不明と言ってあげることが本人のためだし
意味不明ということで、相手に反論の余地を与えている。
そこで相手がちゃんと意味を説明できれば、それでいいんだが、
意味不明と言われて黙るってことは、どういうことかがわかるでしょう？
意味不明だっていうことは反論じゃない。
誤字脱字の指摘と同様、意味を明確にしろっていう指摘でしかないよ
（誤字脱字を指摘した程度で、反論したって思うやつはいないｗ）
157:Name_Not_Found
16/07/07 07:42:18.92 .net
意味不明なら意味を理解しようと努力するのが普通
意味不明な理由を「相手が自分よりはるかに知識量が低いから頓珍漢な事しか言えない」と決めつけて理解を放棄している時点で議論が成り立ってない
自分が相手より格上だと確認して優越感に浸っているだけ
158:Name_Not_Found
16/07/07 08:11:23.11 .net
意味不明がゲシュタルト崩壊してきた
159:Name_Not_Found
16/07/07 09:08:42.93 .net
>>157
> 意味不明なら意味を理解しようと努力するのが普通
じゃああんたは努力すれば？ｗ
160:Name_Not_Found
16/07/07 23:31:40.87 .net
そもそも、77が理解できないのは>>156だけだろ
あれだけ説明されてまだ意味不明とか言ってる時点で読解力が欠如してる
161:Name_Not_Found
16/07/07 23:46:52.83 .net
>>160
じゃあまとめてみる？
>>77の主張・・・jQueryのDefferedを廃止してPromiseを使え。
俺の主張
・DefferedはPromiseと互換性があり混ぜて使える。
・互換性がある今DefferedとPromiseの大きな違いはオブジェクトを生成するときだが
Deffered内部以外でDefferedオブジェクトを作る必要はない
・Defferedオブジェクトが作りたいならば、代わりにPromiseを使えば良い。
・jQueryでDefferedが戻り値になっているのはAjax関連だけである。
・jQueryでDefferedを引数に取るものはない。
・互換性があるから当然jQueryのAjax関連の戻り値のDefferedはPromiseと同じ使い方ができる
・DefferedはPromiseの機能＋αでありPromiseに置き換えると機能低下になる
・Promiseに対応していないブラウザ（Android 4.4など）があるからDefferedを廃止することはできない
・標準APIを使いたい人はPromiseと同時にFetch APIを使うだろうから、そもそもjQeuryのAjax機能を使う必要はない。
・それを見越してjQueryはajax関連の機能を除いたSlim buildを用意しており標準に適合するようになっている。
・つまりjQueryはDOM操作用のライブラリである。
まとめ
標準大好きな人
→ jQueryのAjax関連機能ではなく標準のFetch APIを使う（jQueryはDOM操作用として使う）から学習コストは下がる。
古いブラウザに対応する必要がある人
→jQueryのAjax関連機能を使う。戻り値はPromise互換なので標準Promiseと同じ使い方ができるから学習コストは下がる。
jQueryにどっぷり使ってる人
→Defferedオブジェクトを作ったりすることにすでになれてるから変わらない方が学習コストが下がる。
反論あるのならお待ちしています。
162:Name_Not_Found
16/07/09 13:10:02.62 .net
99のいう学習コストはDOM API習得済/jQuery初心者が対象だろうにjQuery習得者の学習コストに置き換えてる
ホント論理のすり替えが好きだよな
163:Name_Not_Found
16/07/09 13:26:38.08 .net
>>162
> 99のいう学習コストはDOM API習得済/jQuery初心者が対象だろうに
話をちゃんと読む気がないのか？
DOM API習得済であれば、当然標準のPromiseとFetch APIも習得済みだろ
jQueryはDOM操作専用に使って、Ajax部分はFetch APIを使うから、
Defferedは出てこないって話なんだが。
164:Name_Not_Found
16/07/09 18:24:20.90 .net
>>163
そんなんならjQueryなんか要らんわ
jQuery使ってんのにPolyfillまで適用するのは面倒くさすぎる
あまえのFetch APIを使えという指示に従う必要はないから
165:Name_Not_Found
16/07/09 18:55:57.46 .net
jQueryが気に入らないから書き換えたいんだ
→jQueryが気に入らないなら使わなければいいよ
→く( ﾟдﾟ)ﾎﾟｶｰﾝ
166:Name_Not_Found
16/07/09 20:01:07.72 .net
>>165
なんでわざとらしく間違えるから。
どうせやると思ったからあえて
「jQueryはDOM操作専用」って言ったにもかからわず
俺がjQueryを使うなと言ったことにする。
はっきり言うけど、あんた卑怯だよね。
167:Name_Not_Found
16/07/09 20:02:33.29 .net
>>164
> jQuery使ってんのにPolyfillまで適用するのは面倒くさすぎる
ならjQuery使えば？
> あまえのFetch APIを使えという指示に従う必要はないから
誰もお前に言ってないよ。標準を使いたいって人はFetch APIを使えばいいと言ってるだけ。
jQueryのAjax関連の戻り値をPromiseにしたって、一部しか標準になってない。
標準がいいならばFetch APIを使うのが一番だろ？
そしてjQueryはDOM操作専用で使えば良い。
168:名無しさん＠そうだ選挙に行こう！ Go to vote!
16/07/10 08:49:37.11 .net
>>166
> 「jQueryはDOM操作専用」って言ったにもかからわず
「jQueryはDOM操作専用」なら、ajaxもDeferredも存在しないはずだが？
てめーの勝手なイメージを押し付けているだけという事にいい加減気が付け
169:名無しさん＠そうだ選挙に行こう！ Go to vote!
16/07/10 09:03:37.49 .net
>>168
まーたわざとらしく間違える
「jQueryはDOM操作専用に使って」って言ったのに
「jQueryはDOM操作専用だ」と言ったことにしようとしてる。
本当にお前卑怯だな。
jQueryは最初はDOM操作＋ブラウザ間の違いの吸収＋Ajaxとして作られた。
ブラウザ間の違いが減って、使いやすいAPIがでてきて
ようやくjQueryに追いついてきたから、
jQueryはDOM操作専用として使えば十分だって話だ。
逆に言えば、DOM APIの設計が変わらない限り
jQueryはDOM操作用のすぐれたライブラリといえる。
（設計を変えるっていうのはjQueryオブジェクトのようなDOMコレクションに
DOM操作メソッドを追加するっていうことね。これをやらずにいくら
メソッドを増やしたところでjQueryには追いつけない）
170:名無しさん＠そうだ選挙に行こう！ Go to vote!
16/07/10 12:42:04.39 .net
>>169
標準に合わせる意義をお前が理解してないから「jQueryに追いついてきた」とかいう発想になるのさ
お前にとっては変わらず「>99の意見は意味不明」
171:名無しさん＠そうだ選挙に行こう！ Go to vote!
16/07/10 12:56:48.80 .net
>>170
まーた意味がわからんことを言う。
標準のAPIの仕様がjQueryのシンプルさに
追いついてきたって話だろうが。
172:名無しさん＠そうだ選挙に行こう！ Go to vote!
16/07/10 12:57:07.76 .net
標準の方が後追いなんだぞ。わかってるのか？
173:名無しさん＠そうだ選挙に行こう！ Go to vote!
16/07/10 13:32:33.67 .net
「標準に合わせる」これは素晴らしい
「非標準なもの」を使うと、特定のブラウザでしか
動かないものになるからだ。
という話がある。だから「標準」という言葉を使った。
だがよく考えてみよう。
標準の反対は非標準、つまり標準ではないものを使うことであって
標準なものを使っているライブラリにたいして
標準のメリットを言ったところで意味は無いのである。
174:Name_Not_Found
16/07/10 22:05:08.89 .net
とりあえず、プログラム板に統合する事に賛成するということはいっておく
175:Name_Not_Found
16/07/10 22:19:22.40 .net
どこでもいいよｗ
俺は人がいるところに行くだけだから。
176:Name_Not_Found
16/07/10 23:51:23.33 .net
結局、統合しないのか
あの議論は何だったんだ
177:Name_Not_Found
16/07/10 23:56:27.12 .net
なんか俺を排除するための議論だったみたいな感じなんだが
そんなの関係なく俺は適当にやるし、
仲間（？）割れしてなにやってるんだろうなって感じだよなｗ
178:Name_Not_Found
16/07/11 00:00:34.46 .net
こっちのスレで議論しなければ認めないという人もいたみたいだねえ
このスレの住民が向こうに書き込んでるとは考えなかったんだろうね
179:Name_Not_Found
16/07/11 00:11:23.47 .net
そして一番マヌケなのは、隔離（笑）できたと思っている所。
jQueryの話をする場所が増えているだけなのに気づいていない。
180:Name_Not_Found
16/07/11 00:29:28.48 .net
荒らしはスルーが基本だが、この粘着率は異常だな
181:Name_Not_Found
16/07/11 00:30:22.92 .net
>>180
俺としてもスルーしてほしいんだが（笑）
そうすれば、質問者 と それに答える俺 という
素晴らしい流れてできるだろう？
182:Name_Not_Found
16/07/11 00:39:00.89 .net
プログラム板の話ならjQueryの感想書いてつなぎ留め云々にドン引きだわ
炎上商法と比べたらド過疎の方がいくらかマシ
183:Name_Not_Found
16/07/11 00:39:10.55 .net
会話が成立していると思っているところが鈍感さんだね
184:Name_Not_Found
16/07/11 00:41:22.55 .net
ID強制したいって気持ちは理解できるからプログラム板に移ることは賛成なんだけどね
185:Name_Not_Found
16/07/11 00:45:21.31 .net
褒められたことではないが、感想云々は炎上商法とは違うんじゃないか？
感想を書くだけで炎上するとは思えないが
186:Name_Not_Found
16/07/11 00:50:10.12 .net
俺としてはID強制することで何が解決するのか
さっぱり分からないが、まあ俺としてはNGIDにしてくれることで
反論が一切されないっていうのは楽な状況でもある
（だってNGIDにしたら見えなくなるから反論したくても分からない）
187:Name_Not_Found
16/07/11 01:19:45.42 .net
まああっちのスレ見てて思うのは、俺が荒らしているような事を言ってるが
俺がいなくても荒れるじゃねーかって話。
あの例のテンプレ押し付けようとしているやつが
一番の元凶なんだよな。本人がわかってないのが一番たちが悪い。
188:Name_Not_Found
16/07/11 01:35:00.50 .net
子のスレから出張しているjQuery荒らしが完全にスルーされていて笑った
189:Name_Not_Found
16/07/11 01:36:54.89 .net
>>188
言っとくけどあれ俺じゃないよｗ
190:Name_Not_Found
16/07/11 09:38:16.58 ZUSJjugG.net
>>186
ageればIDでるんでよろしく
191:Name_Not_Found
16/07/11 11:14:59.37 .net
こいつは「NGIDにしたはずなのになぜ反論するの？ｗ」と反論するための布石をうってるだけだから何かと理由をつけて反論したりしないだろうな
2chブラウザで sage チェック外すだけだから「面倒くさい」は理由にならないけどな
192:Name_Not_Found
16/07/11 11:16:01.19 .net
× 何かと理由をつけて反論したりしないだろうな
○ 何かと理由をつけてIDを出さないだろうな
193:Name_Not_Found
16/07/11 12:42:26.40 .net
ID出しても自演だのIPコロコロ変えてるだのいうだけだろうなぁ
194:Name_Not_Found
16/07/11 17:21:05.21 .net
IDをコロコロ変えたらNGIDしてほしい要望と矛盾するけどな
195:Name_Not_Found
16/07/11 22:48:23.61 .net
「>>188は俺じゃないから」の体で逃げを打つと見た
196:Name_Not_Found
16/09/26 17:46:07.72 .net
ang2で2つの要素をforするにはどうすればいいですか？
定義リストをforで回したいです
197:Name_Not_Found
16/09/26 17:59:53.54 .net
ミス
198:Name_Not_Found
16/12/23 19:04:24.66 .net
保守
199:Name_Not_Found
17/01/24 20:25:51.02 .net
age
200:Name_Not_Found
17/05/24 22:22:53.29 VTOU+3TY.net
fabric.jsで質問です。
<canvas id="canvas1" width="1200" height="800"></canvas>
var canvas = new fabric.Canvas('canvas1');
で正常に動作しています。タッチデバイスで#canvas1をフリックすると選択の枠が表示されます。当然ですが画面スクロールにはなりません。
canvasを表示させたまま一時的に選択枠を無効にして画面スクロールできるようにしたいのですがどうやればいいでしょうか？
一時的にとはチェックボックスによるユーザ操作でもいいです。
selection = false;
は選べないだけで画面スクロールにはなりません。その他それらしきを試してみましたがどれもうまくいきません。
canvas.off('mouse:down');
canvas.off('mouse:move');
canvas.off('touch:gesture');
canvas.allowTouchScrolling = true;
ちなみに実際は#canvas1と同サイズの複数canvas（#canvas2,#canvas3・・・）を position:absolute; で重ねています。
よろしくお願いします。
201:Name_Not_Found
17/05/24 22:48:43.64 .net
>>200
試してないのでごめんだけど
透明なdivをcanvasの上に乗せちゃうってのはどうだろ?
202:Name_Not_Found
17/05/25 07:06:52.67 .net
同じイベントを、2つの異なる用途で使うの？
そもそも、それは無理だろ。
イベントハンドラーの中で、if文で処理を分けるとか？
203:Name_Not_Found
17/05/25 19:33:48.48 .net
>>202
disableは普通あるぞ
204:Name_Not_Found
17/05/25 19:51:40.30 .net
>>200
touch-action: manipulation;
かねえ
試してみて
URLﾘﾝｸ(w3c.github.io)
URLﾘﾝｸ(triple-underscore.github.io)
205:Name_Not_Found
17/05/25 22:01:09.84 .net
みなさんありがとうございます。
>>201
#canvas2・・・とはどう違うのでしょうか？
>>204
変わりませんでした。
206:Name_Not_Found
17/05/30 22:13:52.27 .net
jQuery UIを少しでもかじったことあるなら>>202のようなレスはしないはずなんだが
207:Name_Not_Found
17/05/31 10:18:56.74 .net
reactをchrome-extensionのUI部分に使ってまして
サイドバーをiframeを使って作って画面に追加してるんですが
その部分をreact-devtoolが反応してくれません。
urlがchrome-extension://XXXX/sidebar.html
になっているからかと思っているんですがdevtoolで動作させる方法ご存じないでしょうか？
208:Name_Not_Found
17/06/01 16:55:51.39 .net
URLﾘﾝｸ(codepen.io)
react公式にあるドキュメントのコードなんですけど
62行目ののメソッド、
this.setState({scale: 'c', temperature});
でなぜ動くのかわかりません
自分は
this.setState({scale: 'c', temperature: temperature });
だと思うのですが、実際コードをこのように書き換えてもちゃんと動きますし
どうしてなのか理由を教えてほしいです
209:Name_Not_Found
17/06/01 17:58:30.69 .net
>>208
すみません自己解決しました
URLﾘﾝｸ(stackoverflow.com)
ES6の新しい表記法みたいです。
210:Name_Not_Found
17/06/13 22:17:04.17 .net
ルーティングのライブラリでおすすめのものはなんでしょうか？
使い方が簡単でシンプルのものが欲しいです。
211:Name_Not_Found
17/06/15 00:59:55.24 .net
>>210
まず、「ルーティング」の定義から説明してみたら？
URLﾘﾝｸ(ja.wikipedia.org)
212:Name_Not_Found
17/06/15 02:16:21.52 .net
病気持ちみたいな性格してるな
こまけー
213:Name_Not_Found
17/06/15 08:41:55.92 .net
いや、オレも分からん
214:Name_Not_Found
17/06/15 08:50:17.14 .net
>>210
ルーティングはフレームワークと密接に
結びついているものなので
単体では存在しません。
215:Name_Not_Found
17/06/15 20:58:53.54 .net
zipなら定番はどれですか？
他にも圧縮率など優れたライブラリがあったら教えて欲しいです
216:Name_Not_Found
17/06/16 00:23:51.16 .net
定番があるほどポピュラーなもんじゃないからなぁ
npmでzipやunzipで検索して使いやすそうなもん選べばいいと思うよ
217:メガネートさん
17/06/29 11:43:27.96 .net
PIXIJSを教えてくれ！(ヽ´ω`)
218:メガネートさん
17/07/01 15:08:55.82 .net
PixiJSでcontainer使って画像表示する場合で
（ container = new PIXI.Container(); ）
幾つかのパーツをひとまとめにした画像をスプライトに分割して使う時はさ
new PIXI.BaseTexture(source, scaleMode, resolution)
でペーステクスチャ作って
new PIXI.Texture(baseTexture, frame, orig, trim, rotate)
でパーツに分けて new PIXI.Sprite(texture) でやるのかなと思ったけど
デフォなやり方ってあるんすか？
あと分割せずにRectangleとかで範囲指定して
表示領域を変化させる方法とかあります？
219:メガネートさん
17/07/02 16:00:10.50 .net
react-pixiの使い心地を教えてくれ!(ヽ´ω`)
220:メガネートさん
17/07/03 15:47:44.30 .net
>>218
あったわ！(ヽ´ω`)
URLﾘﾝｸ(github.com)
221:Name_Not_Found
17/07/03 17:20:07.45 .net
>>218
jsonでテクスチャアトラスデータつくってあとはそこで指定した名前でspriteつくるだけじゃないのかな？
222:メガネートさん
17/07/03 21:40:57.60 .net
>>221
ありがとう
どこかのブログで見かけはしたけど
わたしにはちょいむずいな(ヽ´ω`)
223:メガネートさん
17/07/03 22:13:15.04 .net
テクスチャアトラス記事 真下にあったわ・・・(ヽ´ω`)
224:Name_Not_Found
17/07/07 23:46:58.44 .net
>>215
jsZIPが簡単
だけどjsでM単位のファイルはやめとけよ。
225:Name_Not_Found
17/07/12 15:20:57.31 .net
重たい処理だから直ぐに停止するんだよな。
226:Name_Not_Found
17/07/16 22:27:32.76 .net
html2canvas（要素+canvas）をSVGに変換する方法ありますか？
227:Name_Not_Found
17/07/17 02:40:34.91 .net
jsでZIP処理するときは小さなファイルのみにしておけよ。
Chromeで試したけどどれもこれも止まって使い物にならんかったぞ。
228:Name_Not_Found
17/07/17 12:51:07.82 .net
>>227
使い方が悪いのでは？
巨大なファイルで時間がかかるのはわかりきっているのだから
ライブラリに細かく分割して処理するための機能があるか、
もしなければ別スレッドでやればいいだけだし
229:Name_Not_Found
17/07/20 16:18:21.45.net
その通り
ただ10MBくらいだと同期でもいいくらいのはずだし、
反対に100MBを超えてくるとブラウザのメモリ制限に引っかかる恐れが出てくるので
シーケンシャルに作成しながらDBに保存していったり、サーバに送ると言った手間が要りそう
230:Name_Not_Found
17/07/22 01:19:38.59 .net
>>229
いつの時代の話をしてるんだ？？
231:Name_Not_Found
17/07/22 01:39:46.03 .net
元からnodeの話じゃなかったの？
クアイアント側でzipするの？
232:Name_Not_Found
17/07/22 05:32:42.61 .net
>>230
今の時代だよ
数百MBのファイルを扱うと
実際はその２倍、３倍のメモリを使うことにもなりかねないからね
デスクトップEdgeでも512MBしか保証されていない
233:Name_Not_Found
17/07/22 06:34:46.57 h2s9bK1B.net
速さでは遅延評価する、Lazy.js が速いらしいけど、
Lazy.js > Lo-Dash > Underscore
Lazy.js って使われているの？
version 0.4.2 だけど
234:Name_Not_Found
17/07/22 06:50:16.61 .net
>>230
ZIPファイルをJavaScriptで扱ったけど1.1GBまでできたぞ
235:Name_Not_Found
17/07/22 12:02:02.95 .net
>>232
> 数百MBのファイルを扱うと
> 実際はその２倍、３倍のメモリを使うことにもなりかねないからね
ん？ なんか根拠あっていってんの？
まさか5MBのファイルを扱う時に15MB使っていたから、
100MBなら300MBに違いないとか思ってんの？
5MBのファイルに+10MBのワークメモリを使用するのなら
100MBなら+10MBで110MBですよ
なんで3倍とか思っちゃったのかな？ｗ
236:Name_Not_Found
17/07/22 12:03:02.63 .net
>>233
> 速さでは遅延評価する、Lazy.js が速いらしいけど、
それって遅延評価することで計算が省ける場合に限っての話でしょ？
殆どの計算は遅延評価のオーバーヘッドがないぶん
普通に計算したほうが速いと思うけど
237:Name_Not_Found
17/07/22 14:26:59.72 .net
>>232
ホラ吹きかよ
238:Name_Not_Found
17/07/22 15:28:48.00 .net
>>235
何で煽ってるのかわからないな そりゃ実装の工夫次第だけど、
まず原本ファイルがあって、各チャンクを圧縮したり、暗号化したり、
最後にZIPファイルとしたり固めてたら、
一時的に元ファイルの２倍３倍使ってしまうこともあり得るでしょ
だから512MBが上限だと思うなら、そういう『工夫のない実装』だと
100MBくらいが安心してサポートできる上限だ
100MBを超えてくればメモリ管理を特に意識する必要が出てくる
と言ってるだけなんだよ？ 全くもって自明でしょ？
239:Name_Not_Found
17/07/22 15:58:14.63 .net
工夫のない実装なはずだという妄想でしょｗ
240:Name_Not_Found
17/07/22 18:22:03.58 .net
>>238
でたでた後付け厨w
241:Name_Not_Found
17/07/22 20:33:27.48 .net
>>239,240
俺の至らないレスで気分を害したことは謝る
本当に済まない
本当に済まない
本当に済まない
だけど俺は終始真面目に話をしてるんだから
頼むから煽らずに建設的な話を続けて欲しい
なぜそんなに煽ってくるのか困惑してる
242:Name_Not_Found
17/07/22 20:42:48.59 .net
あと後付け厨とか言うのもよく理解ができない
突っ込みに対して補足を入れたら後付け厨なのか？
それとも最初から突っ込みが絶対入らない呪文を書けるとでも思ってるのか？
いっぺんに思考の全てを文章にして相手にぶつけることなんてできないんだから
こうして会話して行ってお互い真意を探るのは良いことだろうよ
それをあざ笑ったり煽るのは、真意を探ろうとかいう気持ちじゃなくて
最初から攻撃目的の突っ込みじゃないのか？
俺はそれは絶対に間違ってると思うよ
243:Name_Not_Found
17/07/22 21:02:18.06 .net
コミュニケーションを試みるのは立派だと思うけど
たった一行の草生やした煽りレスに一々構うのは労力の無駄だぞ
244:Name_Not_Found
17/07/22 21:15:43.42 .net
心当たりあることを指摘されると許せなくなるような基地外多すぎだろ。
245:Name_Not_Found
17/07/23 03:18:09.42 .net
またいつもの基地外か
こいつは相手したらだめだよ
小学生並の屁理屈で自分が偉いと勘違いするタイプ
そもそも、相手の話のコアが通じない時点で立派なコミュニケーション障害なのにその認識の差異を必死でアピールというどうしようもないやつ
246:Name_Not_Found
17/07/23 03:20:19.58 .net
いつもの基地外は俺のはずだがまあ良いやｗ
247:Name_Not_Found
17/07/23 08:36:36.76 .net
>>234
>>232
>>238
1GBの動画fileをスライス
↓
スライスしたfileをAES暗号化
↓
ローカル上でZIP化
↓
ローカルに保存
IE11で何度か試してみたけど1GBまでは成功したぞ
248:Name_Not_Found
17/07/23 09:59:15.61 .net
>>247
環境による
249:Name_Not_Found
17/07/23 11:49:39.95 .net
保証と上限はまた話が変わってくるだろうからな
逆にブラウザが保証してくれてもOSにブラウザプロセス毎殺されることもあるだろうし
まあ普通のデスクトップツールならファイルとして書き出しながら処理するから
極端な話圧縮辞書くらいしかメモリ使わなくても済むが
WebのJSでやるのはちと大変だろうな
250:Name_Not_Found
17/07/23 11:55:01.36 .net
>>248
環境によるなら、3倍メモリを使うのも環境によるわけで、
えらっそーに（笑）断言するべきじゃなかったですねｗｗｗｗ
251:Name_Not_Found
17/07/23 12:29:18.77 .net
>>250
誰か何を断言したの？
252:Name_Not_Found
17/07/23 14:34:44.02 .net
だれも環境によらず３倍のメモリを使う！なんて断言してはいないな
253:Name_Not_Found
17/07/23 15:16:59.42 .net
>>250
主観が標準
思い込んだことが標準
否定されると事実をねじ曲げて牙を向ける
指摘されると挙げ足をとって話をそらす
またいつものこう言った輩だろ。
主観条件を想像して平気でこんな発言している。
>>実際は2倍、3倍のメモリを使うことにもなりかねないからね
>>230
今の時代だよ
数百MBのファイルを扱うと
実際はその２倍、３倍のメモリを使うことにもなりかねないからね
デスクトップEdgeでも512MBしか保証されていない
254:Name_Not_Found
17/07/23 15:30:10.77 .net
どや？ 不安になってきたろ？
そうや3倍とかにもなりかねんのや
不安だろう？
我が言霊の力じゃよ
255:Name_Not_Found
17/07/23 15:31:34.22 .net
何の根拠もないことでも
こうやって言葉で揺さぶりをかければ
相手に不安を与えるもんなんじゃよ
これが人生経験というものかのう
256:Name_Not_Found
17/07/23 16:57:31.44 .net
よく分からんが、人生経験豊富な揺さぶりで不安になったから噛み付いてたってこと？
257:Name_Not_Found
17/07/23 17:10:42.48 .net
ほっほっほ。3倍じゃよ3倍。3倍にもなるんじゃ。
下手すれば5倍、いや10倍、もっといけば100倍にも
なるかもしれんのう。そうなったらどうするんじゃ？
258:Name_Not_Found
17/07/23 17:22:19.02 .net
思いつきの屁理屈で絡んで、どうにもならなくなったら茶化して煽るとかさ
おまえって生きてて悲しくならないの？
勝てない喧嘩なら最初からふっかけるなよ
その判断すらできないからいつもそんな惨めな人生おくることになるんだぞ
259:Name_Not_Found
17/07/23 17:38:51.58 .net
>>253
そもそもローカルで512Mとか技術ありませんと認めたようなもんだろw
Edgeでjs制御すればGB単位の処理する方法はあるからな。
まるで道具の使い方を知らない土人だな。
260:Name_Not_Found
17/07/23 17:53:05.25 .net
10MBのファイルでも下手すりゃ1GBのメモリ食うよ
261:Name_Not_Found
17/07/23 18:30:10.71 .net
なんで極端な話を持ち出すの？
262:Name_Not_Found
17/07/24 05:39:43.43 .net
ワーキングメモリが512bitしか無いのに、全て思い込みで埋まってる奴が要るようだな
その何GBでもOKな自身のEdgeに少し分けてもらえばいい
263:Name_Not_Found
17/07/24 10:28:13.97 .net
Edge...
264:Name_Not_Found
17/07/26 16:36:16.30 .net
>>261
否定したいからじゃね
265:Name_Not_Found
17/07/26 21:14:19.08 .net
お前が犯人だ！違うっていうのなら証拠を見せろ！
アリバイがないことがお前が犯人の証拠！
266:Name_Not_Found
17/07/27 04:47:56.73 .net
>>261
正論や事実を突きつけられると突拍子も無いことや極端な例えを持ち出す人とたまにいるよね。
267:Name_Not_Found
17/07/27 06:15:32.29 .net
極論と言うか、話の意味が分かっていない
268:Name_Not_Found
17/07/27 06:31:13.42 .net
天の邪鬼、基地外、図星、声闘
これに該当する人も必ず書き込みするよ
269:Name_Not_Found
17/07/27 08:36:35.08 .net
>>261
人と違う考え方が格好いいとかズレた考えの人もいる。
ただ偏屈なだけかも。
270:Name_Not_Found
17/07/27 14:56:38.67 .net
人と違う考えをあえて提示するのは有益だが
今回のは見当違いというか噛み合っていない
271:Name_Not_Found
17/07/27 19:17:22.97 .net
>>261
>>260のことか？
272:Name_Not_Found
17/08/02 01:02:24.56 .net
>>260
天の邪鬼や社会不適合者の類いだな
273:Name_Not_Found
17/08/09 04:10:29.38 KHLiGKM9.net
underscore, lodash の機能を、左右に表示して比較した、サイトはある？
どこかで、見たような気がするのだが、探せない
それと、lodash の日本語訳は無い？
無いよな
結局、lodash厨は、この板で普及活動だけして、日本語訳を作らなかったのか
274:Name_Not_Found
17/08/09 21:27:21.01 .net
偉そうな言い方で英語がわかりませんって言っても
お前の能力の低さは隠せないぞｗ
lodash、英語とか日本語以前に
コードがあるからそれで十分じゃね？
関数の使い方と戻り値から何をしてるのかわかるでしょ
275:Name_Not_Found
17/08/10 01:33:21.15 .net
お年寄りは日本語じゃないと拒否反応起こしちゃうからね
276:Name_Not_Found
17/08/11 22:34:53.27 .net
ブラウザとNode.js両方で使えるライブラリを書くときってisomorphic-fetchとかfetch-ponyfillみたいなfetch API系とrequest(-promise), どっちが流行ってる？
277:Name_Not_Found
17/08/14 05:31:57.47 .net
なにをしたいのか分からんけど
たとえば何か１ファイルを取ってくるのだったら
fetchXxx()という名前の関数にするのが良いと思うぞ
278:276
17/08/14 18:25:31.60 fFVNiceo.net
ライブラリ内部でHTTP通信する場合に採用するライブラリの選定について, であります
279:Name_Not_Found
17/08/15 14:57:42.67 .net
そこはfetchかrequestかに限らずよく吟味した方が良いとも言えるし、
直接ユーザーに出さないのなら殆ど開発者の好みの問題でどうでもいいとも言える
ただね、Fetch APIっていうのはとても素直に見えて、
実は少し細かいことをやると特殊な仕様の宝庫だからね
つまり、結局は、ブラウザ上で「フェッチ」するためのAPIであって、
Nodeでもどこでも使いやすい、汎用的なhttp通信のためのAPIではないということ
だからおれは、もしAPIを提供するときにfetch感を出すときは、取得する物と方法を決め打ちして、
中間を見せないfetchXxxという名前の関数にしなさいといったの
で、結局はfetchでもrequestでも、環境にそぐわないAPIの叩き方、使われ方をされることに
どういう対処しているのかが、例え君がそういう使い方をしないとしても、『良いAPI』を見極めるために重要だと思う
でも一番いいのは、http通信なんてコード量大したことないんだから、自分でラッパーを書くこと
そしてその名前をfetchでもrequestでも無いものにしておくこと
標準的な物に沿うことも重要だけど、それがはっきりしていない場合はあえて開き直って完全独自にすることも重要
280:Name_Not_Found
17/08/15 21:40:56.70 .net
長文なだけで中身がないな
何が言いたいのか
281:Name_Not_Found
17/08/15 22:11:27.63 .net
>>276
俺が先に書いておけばよかったね。といっても「どちらも流行ってない」が答え
事実だけど煽り見えるだけなので書くのが面倒で放置していたら長文野郎に絡まれたねw
まあ俺も長文野郎だけどw
>>279がごちゃごちゃ言い訳がましいことを言ってるのは
"ウェブ標準を推奨したいけど欠点があるから" なんだよ。
はっきり（今の）ウェブ標準はクソと言い放ってしまえばいいのだけれど
この人、ウェブ標準大好きな人だからそれが言えないんだろうねw
まず今の標準化されてるブラウザのFetch APIはクソ。なぜならもともとAjax（XHR）で
できていたはずのキャンセル機能や進捗情報ができなくなってしまっているから。
それもこれもPromiseなんか採用してしまったから。
だからFetchもRequestもPromiseを使っているものは現時点では全部アウト
そして今頑張ってFetch APIにキャンセルと進捗状況を取得できる機能が追加されようとしてる。
本来はPromiseに追加すべき機能だけど、Promise作ってる奴らが動こうとしなから
Fetch APIの方に組み込もうとしている（将来それがうまくいけばPromiseに移植されるかも）
このように現在は "ウェブ標準" のFetch APIは制限があり仕様は過渡期であるため薦めることができない。
そのことをはっきり言わないから>>279はごまかすようなレスになってる。俺ははっきりいう。
（今の）Fetch APIはクソ。Requestはウェブのような標準仕様がないのでクソ
Promiseを採用しているならば、それもクソ。よってどちらも流行ってるなんて言えるもんじゃない。
それから完全独自実装なんて手間がかかるだけ。バカがやること。これだけはやってはいけない。
とは言え現時点では標準もブラウザでネイティブに動かすのも諦めるしかない。
だからSuperAgentなんかが有名でいいんじゃないか？ 将来は別の何かに置き換えることになるかもしれないが
その時、完全独自実装の大量のコードを読み解くよりも、
ライブラリを使って少ないコードでシンプルに書いていれば変更は楽になる。
282:Name_Not_Found
17/08/16 00:41:57.87 .net
この荒らしに同調するのも癪だけど実際そんなところだよ
条件を満たすライブラリがあれば中の人が全部吸収してくれるからベスト
自分でXHRやhttp使ってラッパー書いてもいいけどね
283:276
17/08/16 01:09:41.21 .net
成程, 確かfetchはprogress取得のためにReadableStreamを取れるようにして苦労してるみたいね
この辺はpolyfillで何とかなりそうだけど, これに加えてCookieの取り扱いがブラウザとnode-fetchで違っていて辛そうだと思った
promise自体がクソだとは思わないけど現時点で機能不足だというのは確かにその通りだと思うわ, 少なくともPromise/A+の現時点の規格では時間の掛かる処理にはとても使えない
progressとかcancelは一応under discussionみたいだし将来に期待しておくことにする(それまではQでも使えばいいのかな)
とりあえずSuperAgentとpromiseベースだけどprogressとcancelが出来るaxiosとで比較検討してみますわ
どうもありがとう
284:Name_Not_Found
17/08/16 10:30:28.47 .net
その論調何度か聞くけど、別にfetch自体はまず今の仕様のPromiseを返すのでおかしくないと思うけどな
だってまずはヘッダを取得して、そこから更に何をするかとなるのが自然だから、そこまでは普通
fetchが出すResponseがReadableStreamを返す仕組みなのも苦労とかじゃなくてごく自然
ただReadableStream自体は微妙というかObservableであったほうが良いとは思う
そしてキャンセルはあるべきだけど、なぜか皆Promiseに付けろと思うけどそれは間違い
実際はPromiseに生えてたら凄い使いにくいし、Promiseの概念上分かりにくことになるのは考えたら分かる
だから、.cancelの提案なんてない。代わりにCancelToken型の用に仕組みが分離してあるものが提案されている
これならObservableにも使えるしずっと筋が良い
285:Name_Not_Found
17/08/16 10:48:31.20 .net
> 実際はPromiseに生えてたら凄い使いにくいし
だからFetch APIはPromiseではないものを返すべきだってことなんだが。
お前の結論からもPromiseを返すのがおかしいという結論にたどり着いてるじゃんか
目的はPromiseを返すことではない。Promiseは手段でしかない。
時間がかかるから非同期を使う。ということはよくよく考えてみると
非同期は時間がかかる以上キャンセルと進捗状況の確認機能は必須であることに気づく
だからPromise自体筋が悪い仕様だったってことなんだよ。
286:Name_Not_Found
17/08/16 10:54:22.17 .net
EcmaScriptのPromiseは基本的機能だけをサポートする
という考え方だから便利な機能はサポートされない運命
実用的なPromiseの一つであるbluebirdはキャンセル機能が搭載されている
URLﾘﾝｸ(bluebirdjs.com)
287:Name_Not_Found
17/08/16 11:06:16.91 .net
>>284
> 実際はPromiseに生えてたら凄い使いにくいし、Promiseの概念上分かりにくことになるのは考えたら分かる
それはあなたの感想ですよね？
> だから、.cancelの提案なんてない。
普通にあるが？
288:Name_Not_Found
17/08/16 11:11:26.24 .net
誰かが妄想でFetch APIとPromiseに関する嘘の流れを作る前に
ここまでの流れを示しておくわ
Fetch の中断と Promise のキャンセル方法の標準化
URLﾘﾝｸ(blog.jxck.io)
あーあー、本来はPromiseにキャンセル機能が搭載されて
シンプルになったはずなのになー。
理想の案ではなくて次点の案ですすんでるとはな
289:Name_Not_Found
17/08/16 11:16:39.97 .net
> 代わりにCancelToken型の用に仕組みが分離してあるものが提案されている
今更に否定されたCancelTokenとか持ち出されてもw
> 要約すると以下のようなものだった。
>
> CancelToken (.NET の知見) という API 経由で Promise をキャンセルする。
> キャンセルはエラーとは違うため、 resolve/reject 以外に 3 つめの状態を追加する。
> しかし、結論から言うと議論の途中で頓挫してしまった。
>
> なんで頓挫したかの詳細は、仕様策定の中心だった domenic の悲痛な一言に集約されている。
>
> Why was this proposal withdrawn? #70
290:Name_Not_Found
17/08/17 20:57:58.96 .net
頓挫は大袈裟。stage0から進ませて貰えなかっただけで、.cancelの様に棄却されたわけじゃない。
今最も、そして唯一のPromiseのキャンセル関連の仕様なのは間違いない。
291:Name_Not_Found
17/08/17 22:02:36.28 .net
URLﾘﾝｸ(dictionary.goo.ne.jp)
とん‐ざ【頓挫】の意味
１ 勢いが急に弱まること。また、計画や事業などが途中で遂行できなくなること。
「活動に一頓挫を来?(きた)?す」「不況で事業が頓挫する」
棄却に相当するものは事業が失敗する、会社が潰れるなどのことだよ。
頓挫というのは勢いが急に弱まる事を言う
292:Name_Not_Found
17/08/17 22:15:03.96 .net
なんと言うか、頓挫というのはそれこそES6策定の頃からPromiseの在り方やメソッドに付いての議論がたくさんあって、
誰もが何らかの仕組みが早く欲しいと思い続けてきたキャンセル周りにおいて、その場しのぎにしかならない価値の薄い.cancelではなく
ようやく新しい構文だとか何もかも含めて全体的に上手くいきそうな提案が出てきたけどスムーズに進まなかったという、大きな期待と逸る気持ちがあってこそ出た大袈裟な失望の言葉なのに、
ES DiscussやMeetingを追ってすらもない奴らが自分の意見を肯定するためだけに書かれた気持ちや前提を汲まず悪用するのは気分が悪いね
293:Name_Not_Found
17/08/17 22:20:45.61 .net
>>292
> 大きな期待と逸る気持ちがあってこそ出た大袈裟な失望の言葉なのに、
それはあなたの感想ですよね？
何処かに定義でもあるんですか？
294:Name_Not_Found
17/08/17 22:21:35.44 .net
つまり頓挫、勢いが急激に弱まったと言い換えたら、それはずっと展開を追っていて各人の心の中の燃える期待感というか、安心感であって、
ステージが進まないのなんて珍しくないし、実際提案の勢いに変化が生じた訳ではない、ただキャンセル周りの仕様がサクサク決まることは難しそうという不安感は出てきた
とは言っても.cancelがあり得ない以上、似た仕様になる事は確実
295:Name_Not_Found
17/08/17 22:22:47.03 .net
似た仕様になる もしくは 頓挫です
296:Name_Not_Found
17/08/17 22:28:00.67 .net
>>293
じゃあまずどうして.cancelが失敗したのか、そして今CancelTokenは奴に否定されたのに残ったのかを考えた方が良い
その上で具体的な疑問があれば答えるから
297:Name_Not_Found
17/08/17 22:28:38.38 .net
まあひとつはっきりしてるのは、今すぐFetch APIを使用するのは
リスクが大きいってことだな。
SuperAgentもしくはaxiosを使うのが現実的
298:Name_Not_Found
17/08/17 22:30:06.51 .net
>>296
じゃあなんで頓挫したのか教えて
なんで頓挫したかの詳細は、仕様策定の中心だった domenic の悲痛な一言に集約されている。
URLﾘﾝｸ(github.com)
299:Name_Not_Found
17/08/17 22:31:23.69 .net
URLﾘﾝｸ(github.com)
This proposal has been withdrawn
This proposal has been withdrawn by its champion and is no longer
active in the TC39 process. For reference to previous documentation
and specification work, see the Git commit history.
ちなみにwithdrawnには撤退という意味がある
300:Name_Not_Found
17/08/17 22:33:28.48 .net
更に言うならば、この撤退してリポジトリの中身がすっからかんの
空っぽになってしまった、これこそがCancelTokenである
const cancelToken = new CancelToken(cancel => {
cancelButton.onclick = () => cancel("The cancel button was clicked");
});
performCancelableOperation(cancelToken);
URLﾘﾝｸ(github.com)
301:Name_Not_Found
17/08/17 22:34:21.75 .net
CancelTokenはなぜ仕様の内容が
削除されてしまったのか？
削除されたのにリポジトリを残してるのは
単なるあてつけだとかるが
ではなぜ
CancelTokenはなぜ仕様の内容が
削除されてしまったのか？ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
302:Name_Not_Found
17/08/17 22:38:48.90 .net
>>296
> そして今CancelTokenは奴に否定されたのに残ったのかを考えた方が良い
残ってないよ。
リポジトリの中身は削除されてる
303:Name_Not_Found
17/08/17 22:57:36.26 .net
すまん、完全に俺の言い方が悪い
元をたどれば>>284で
CancelToken『型の用に仕組みが分離してあるもの』
と書いたように、俺はCancelTokenそれだけに拘って考えて言っていたのではない
例えば俺がstage0だなんだ言ったのはCancellation APIを意識してたから
そこんところごっちゃにしてたのは本当に謝る
CancelTokenが消えたのは、結局CancelablePromiseが否定されたのを、
じゃあcancel状態の代わりにelse状態を持ってればいいだろというように
結局皮が剥け切れて無かったから、そこを奴に付かれた
だから逆に言うと、「分離」してある形になるのはより確実になってきたと言える
俺が言いたいのはそこ
304:Name_Not_Found
17/08/17 22:59:43.13 .net
いや、そんな言い訳はいらんわ。
今も生きてる仕様がどこに書いてあるかを言えばいい
305:Name_Not_Found
17/08/19 14:31:35.18 .net
どうせ罵詈雑言に言われると思ったから暫く見れないでいたんだが、お前ら意外と優しいのな
俺が言ってたのはこれ
URLﾘﾝｸ(github.com)
306:Name_Not_Found
17/12/12 03:42:06.77 MrUcGD8N.net
HPで友達が稼げるようになった情報とか
⇒ URLﾘﾝｸ(asaswq3wq.sblo.jp)
興味がある人だけ見てください。
KH0BV0X79E
307:Name_Not_Found
17/12/28 08:15:23.53 .net
URLﾘﾝｸ(uppy.io)
このライブラリすご
308:Name_Not_Found
18/02/18 19:08:55.34 .net
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
309:Name_Not_Found
18/05/01 19:03:22.41 l1wYHpV1.net
誰でもできる在宅ワーク儲かる方法
少しでも多くの方の役に立ちたいです
グーグルで検索するといいかも『金持ちになりたい 鎌野介メソッド』
NHNSG
310:Name_Not_Found
18/06/18 12:09:07.18 9uLJZxfn.net
incsearch.jsについて質問です。
データ内に、リンクなどのHTMLタグを書いた場合、
検索結果にも、そのタグや属性値などが出力されてしまいますが、
これを出力させずに、検索結果として得るにはどうすればいいでしょうか？
例えば、下記サイトの
URLﾘﾝｸ(hiromi-ayase.github.io)
で「http」と入力すると、検索結果に
『URLﾘﾝｸ(mediaarts-db.jp)』
などと出力され、リンクが機能しなります。
これをリンクが機能する『link』として表示したいです。