■質問を書く上で
(1) 質問にならない投稿はご遠慮ください。(煽り、コード制作依頼など)
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 長い間連続して質問する場合にレス番を名前にしてあれば、質問の流れが回答者に伝わりやすくなります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は
ttp://validator.w3.org/ で [Check] してみてください。 (8) 質問を具体的かつ詳細に書くと回答を得られやすいです。質問テンプレートを活用してみてください。
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【ライブラリ】使用しているライブラリ名を記入してください。(ex: jQuery)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
ttp://jsdo.it/ ttp://jsbin.com/ ttp://jsfiddle.net/ ttp://ideone.com/ JavaScript ライブラリ総合質問所 vol.4
ttp://toro.2ch.net/test/read.cgi/hp/1400809255/ ■関連スレ
+ JavaScript の質問用スレッド vol.115 +
ttp://toro.2ch.net/test/read.cgi/hp/1399072595/ JavaScript Tips コレクション
ttp://toro.2ch.net/test/read.cgi/hp/1070611524/ 1行javascriptプログラミング
ttp://toro.2ch.net/test/read.cgi/hp/1066750037/ 【node.js】サーバサイドjavascript 2【Rhino】
ttp://toro.2ch.net/test/read.cgi/tech/1358937029/ ■各種ライブラリ
jQuery API Documentation
ttp://api.jquery.com/ jQuery Mobile API Documentation
ttp://api.jquerymobile.com/ API Docs - YUI Library
ttp://yuilibrary.com/yui/docs/api/ Underscore.js
ttp://underscorejs.org/ lodash documentation
ttps://lodash.com/docs ■関連スレ
+ JavaScript の質問用スレッド vol.120 + [無断転載禁止]©2ch.net
ttp://echo.2ch.net/test/read.cgi/tech/1463914293/ + JavaScript の質問用スレッド vol.130 + [無断転載禁止]©2ch.net
ttp://echo.2ch.net/test/read.cgi/hp/1463395557/ JavaScript Tips コレクション
ttp://toro.2ch.net/test/read.cgi/hp/1070611524/ 1行javascriptプログラミング
ttp://toro.2ch.net/test/read.cgi/hp/1066750037/ 【node.js】サーバサイドjavascript 2【Rhino】
ttp://toro.2ch.net/test/read.cgi/tech/1358937029/ 総合スレが復活して良かった
+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
ttp://echo.2ch.net/test/read.cgi/hp/1465566635/ こっちに答え書いてあるよｗ
具体的な情報が書いてないがな
ttp://echo.5ch.net/test/read.cgi/hp/1465566635/8">
ttp://echo.2ch.net/test/read.cgi/hp/1465566635/8 ： Name_Not_Found [sage] 2016/06/12(日) 22:51:25.15ID:???
アップグレードガイドを読む限り、jQuery 3.0 は IE9+ 対応とある
ttp://jquery.com/upgrade-guide/3.0/#browser-support こちらではIE6-8は1.12を使ってくれ、とある
ttp://blog.jquery.com/2016/05/20/jquery-3-0-release-candidate-released/ こちらでは「jQuery Compat」は死んだ、といってる
ttp://blog.jquery.com/2016/01/14/jquery-3-0-beta-released/ というわけで「jQuery Compatはない」が正解
不確かな情報に踊らされないように
> そのため予定されていたjQuery Compat 3.0がなくなり、
> jQueryは3.0に一本化されました。
って
+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
ttp://echo.2ch.net/test/read.cgi/hp/1465566635/ に書いてあるのにｗ
読んでんだろｗｗｗ
正しい情報書いてあるな。
なんだこのスレｗｗｗ
ありがとう
【翻訳まとめ】jQuery 3.0 アップグレードガイド - Qiita
ttp://qiita.com/fmy/items/345a264a1cf2e2a73f62 また荒らされて終わるでしょ
ttp://qiita.com/fmy/items/345a264a1cf2e2a73f62#warning-document-ready%E3%81%8C%E5%B8%B8%E3%81%AB%E9%9D%9E%E5%90%8C%E6%9C%9F%E3%81%AB 「document-readyが常に非同期に」はこういうことか
ずいぶんとトリッキーな動きだな
'use stirct';
document.addEventListener('DOMContentLoaded', function (event) {
console.log(document.readyState);
jQuery(function () {
console.log(2);
});
console.log(1);
}, false);
DOMContentLoaded 的には何もしないのが正解なのだろうが
そこまでして向こうのみならずスレを盛り上げたいのか…
+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
ttp://echo.2ch.net/test/read.cgi/hp/1465566635/ DOMContentLoadedハンドラの後で動作するようにしてるのね
DOMContentLoadedのショートハンドとしてはありえない動きだけど、イベントを知らない初心者向けとしてはありがたい挙動なのかもね
それ本家質問スレに常駐してる荒らしが立てたスレだからだよ
以前も自分の建てた乱立スレに本スレから質問コピペ→自己レスして伸ばしてた
ttp://echo.2ch.net/test/read.cgi/hp/1463395557/ 現行はこれ
【jQuery】JavaScript ライブラリ総合質問所 vol.3
ttp://echo.2ch.net/test/read.cgi/hp/1369444026/ JavaScript ライブラリ総合質問所 vol.4
ttp://echo.2ch.net/test/read.cgi/hp/1400834117/ JavaScript ライブラリ総合質問所 vol.5 [無断転載禁止]©2ch.net
ttp://echo.2ch.net/test/read.cgi/hp/1465399470/ ■jQueryスレ
※前スレは「【jQuery】JavaScript ライブラリ総合質問 vol.3」(総合スレ)で「jQueryスレ vol.3」はない。
つまり、ライブラリスレの乗っ取り行為。
jQuery ライブラリ 総合質問所 vol.4
ttp://peace.2ch.net/test/read.cgi/hp/1400313626/ + JavaScript & jQuery 質問用スレッド vol.5 + [無断転載禁止]©2ch.net
ttp://echo.2ch.net/test/read.cgi/hp/1452081417/ + JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
ttp://echo.2ch.net/test/read.cgi/hp/1465566635/ jQueryスレとこっちを比較しているならこっちが本家
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);
ttp://qiita.com/fmy/items/345a264a1cf2e2a73f62#new-%E6%96%B0%E3%81%97%E3%81%84escapeselector%E9%96%A2%E6%95%B0 そんな馬鹿な、と思って試してみた
<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 でも実装できるな(エスケープ関数が用意されてなかっただけ)
var a = jQuery('#a');
var b = jQuery('#b');
var c = jQuery('#d');
var abc = jQuery('#a,#b,#c');
変数a,b,cから変数abcを一つの関数で生成したいのですが、APIが見つかりませんでした。
var c = jQuery('#c');
ありがとうございます。出来ました。
jQueryにmerge機能が付いていたんですね。
ヒントを頂いたのでjQueryオブジェクト以外も試してみましたが、NodeListやHTMLCollectionはmergeしてくれませんでした…。
console.log(jQuery([document.querySelectorAll('p'), document.getElementsByTagName('div')]));
ttp://echo.2ch.net/test/read.cgi/hp/1452081417/894がいってたjQuery版は16日経過した今も出てこないな 彼がどんなコードを書くのか興味があったんだが…、まあいいか
このスレで聞いても間違いしか出てこないよ。
こっちにjQueryを混ぜようとしたいだけで
jQueryが好きでもないやつがjQueryの話をしているだけだから。
あなたの疑問に対する答えはこっちに書いた。あとはこっちでやるように。
ttp://echo.2ch.net/test/read.cgi/hp/1465566635/63 間違いを指摘してくれた事には感謝しますが、このスレで満足していますのでそちらに書いて頂かなくて結構です。
にあるように本スレはこちらだと思っています。
.add()はa.add(b, c)が期待通りに動かず、a.add(b).add(c)と書いてようやく要件を満たします。
(勿論、2回関数を呼び出してしまっていますので完全ではありません)。
.add()はどちらかといえば機能限定版(非破壊的、可変引数ではない)のArray.prototype.pushに近いメソッドだと認識しています。
そういえば、jQuery APIで可変引数の関数は見ないですね。
ttps://api.jquery.com/add/ 反面、jQuery.mergeが可変引数でない仕様が謎です…。
jQuery作者はjQuery.merge(a, b, c);と書くニーズがないと思ってるんですかね。
ttps://api.jquery.com/jQuery.extend/ ttps://api.jquery.com/jQuery.merge/ jQuery([...a,...b,...c]);
が、Babelを使うならjQueryを使う必要性が激減します。
jQuery APIの範囲内では何ともならないのでしょうかね…。
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);
動きをドヤ顔で説明したくなるようなコードはだめ
向こうの回答よりも自分で導き出したコードの方が洗練されてるから、どこで質問しても結果は同じだっただろうな
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]
ありがとうございます。出来ました。
自作自演バレバレなんだよなぁ
は私の確認ミスですので言い訳するつもりはありませんが、,30には回答してくれた事に感謝しています。
私にとっては回答の正誤はどうでもよく、最終的に最適解に辿りつければ良いのです。
質問や回答に優劣をつける事に価値はありません。
これで可読性落ちるっていうならreduceを理解してないだけ
jQueryにreduceないから知らんのかもしれんけど
上でreduceが挙がったけど、jQueryは配列操作関数としては物足りないところがあるよね
あくまで配列的に合成してしまうのでは
ArrayLikeObjectを引数にとるから大丈夫だよ
ttps://api.jquery.com/jQuery.merge/ いや、そっちじゃなくて
添字とlength以外が適切に処理されないのではと
たとえば.add() の場合は前回選択している部分が残されて
.end() で取り出せるわけだけどそういう処理が行えないんではないかな
ごめん、何を言ってるのかわからなかった
の実装ならどちらも a を基本としているから a にあるプロパティは引き継がれると思うんだけど、どういうコードで弊害が発生するんだろう？
わかった、こういう事ね
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]
abc.slice(0, -1);
(jQuery的にやっていいのかわからないけど)プラグインで内部に値を持つとか
将来jQueryが機能拡張されて…
とかいう意味での危険ね
まあ、そうなっていると認識していればOKかなあ
前方互換性を考慮するなら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オブジェクトの設計を知っているべきだと思う
> reduceは可読性落ちてないよなあ
> これで可読性落ちるっていうならreduceを理解してないだけ
reduceを理解していれば、reduceの戻り値を
捨てるなんてありえないと思うがね。
reduceの機能を理解しているかどうかじゃなくて、
reduceはどういうときに使うものかっていう話だよ。
例えばmapかいてmapの戻り値を捨てるようなもんだよｗ
最初からeach使えという話。
素直にaddを二回使う
reduceは一つの値を連続処理する関数なのだから返り値を使わなくてもいいんだよ
返り値を使えばもっと短く書けるけど、「可読性を低くしてまで」は関係ない
var abc = [b, c].reduce(jQuery.merge, jQuery(a));
関数型を理解してくださいとしか言いようがないな。
関数型言語から来たものなのに副作用に依存するとか
ちょっとセンスがわるい
君にセンスを理解してもらう必要はないんだけど…、頭が固いと大変だね
自分の世界観から抜けられないだけのような
ttp://echo.2ch.net/test/read.cgi/hp/1465566635/90 冗長合戦したいなら$()が冗長だから出直しておいで
相手の為を思って叱ってくれる人も中にはいるが、こいつのはただjQueryスレに誘導するためにこき下ろしているだけだからな
なんの問題があるんだ？ｗ
荒らしのたてたスレに誘導する必要もない
向こうはJavaScriptとjQueryのスレってことでいいじゃないか
お前もその一人なのか？
タイトルで誤魔化してるが、向こうはただのjQueryスレ
JavaScriptの質問はスレ違い
もっと思い切ったAPI変更が欲しかったら
もう完成されているんだよ。
アドビ イラストレータと同じww
Deferedを廃止してPromiseを使うとか、classListを実装するとか、eachをforEach互換にするとか、標準に近づけてほしかったな
互換性をなくしてまで仕様を変える意味は？
メジャーバージョンアップで互換性がなくなるなんて良くあること
個人的にはDeferedはPromiseに変えて良かった気がしないでもない
> 学習コストの低下と汎用性じゃない？
学習コストは一度覚えればいいだけ
過去のソースを書き換えるほうが手間がかかる。
汎用性は意味不明。標準よりも高機能のほうが汎用性は高いし。
機能が低下している。
標準のPromiseを使うことはできないのだ。
さすがにこれはない
jQuery一色に染まってるな
Promiseは内部的にPolyfillを作ればいいだけでPromisesの実装が進めばPolyfillは削除できる
event.pageXの独自拡張が削除されたように標準を使ってもらう形の進化は有りだと思う
実装が整ったからAPI削除ってjQuery 3.0でもいくつかあったよね
kwsk
削除されたAPIはajaxのcompleteが記憶に新しいが
$.parseJSONの非推奨も次で削除する為の準備段階な印象
ありがとうございます。
リンク先参照します
> Promiseは内部的にPolyfillを作ればいいだけでPromisesの実装が進めばPolyfillは削除できる
それをいうなら、jQuery 3.0のDefferedはPromise互換なので、
Promiseを使ってDefferedを実装すれば良いだけ。
Fetch APIはあまり関係ないと思うよ。
Slim build
ttps://blog.jquery.com/2016/06/09/jquery-3-0-final-released/ > 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関連はいろんなライブラリに搭載されてるから機能が重複しやすかった。
> 実装が整ったからAPI削除ってjQuery 3.0でもいくつかあったよね
実装が整ったという理由で消えたAPIはないよ。
jQueryの互換性は高い。
jQueryはDOM APIよりも使いやすいという利点のライブラリなんだから
実装が整った程度じゃAPI削除する理由にはなりえない。
> Promiseを使ってDefferedを実装すれば良いだけ。
Promiseをprototype拡張するつもりか
prototype拡張は駄目なやり方だという設計してるのがjQueryなんでぇ。
当然jQueryと同じようにラップするに決まってるでしょう（笑）
将来はイベントハンドラとか全部Promiseに置き換わるはず
標準のPromiseは基本機能しかサポートしてないから
普通はQとかを使うのが常識だと思ってたが。
Promiseをラップするぐらいなら、現行のPrpmise互換オブジェクトの方が数段マシだと思うが
拡張部分とPromise互換部分の整合性をとるのが面倒で内部的にPromiseを使うメリットが感じられん
ttp://http://blog.toshimaru.net/jquerydeferred-is-most-important-client/">ttp://blog.toshimaru.net/jquerydeferred-is-most-important-client/> 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を使えって言うならば、足りない機能を実装するしか無いだろ。
そして ： Name_Not_Found [sage] 2016/06/30(木) 21:35:32.91ID:???
反論するなら相手の立場になって反論しないとな
でなければ、ただの宗教戦争だ
そうか？単に標準のXMLHttpRequestで必要とされている機能を
満たすにはPromiseの機能だけでは不足しているから
拡張する必要があるってことに気づいているかどうかだと思うぞ。
XMLHttpRequestと同じ方法ってことは、
Promiseを返さないってこと？
そういうことになるね
はjQueryの既存概念にとらわれすぎているようだけど、DOMのInterfaceで実装する仮定で想像してみればいいたい事の大体はわかると思うよ
そもそも、Ajaxの返り値の話なんて誰もしてないから
意味不明だなｗ
結局のところPromiseを使う理由はないってことか。
互換性を切るなんてもっての外だし、
あえて互換性を切ってまでDefferedの仕様を変える意味はないし、
やはり今の仕様が一番最善ってことか。
独り合点してないでもう一度、読み直して来たら？
jQuery.Defered === Promise && ajax() !== jQuery.Defered
互換性の問題があるから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に意味がないと言ってる人は、関数型の考え方を理解していないはず。
読み直した。それであなたが言いたいポイントは？
君は「相手の立場で物事を考える」って出来る？
「インデントにタブ/半角スペースのどちらを使うべきか」の命題でタブ派が半角スペース派に「誰でも納得出来る明確なメリット」を主張できると思う？
元々の立ち位置が絶対的に違うのに、自分の立場でしか物事を考えられない人は議論に向いてないと思うよ
What your point ?
自分が言いたいポイントを明確に答えられなければならない。
それが言えないってことは、そもそもお前は議論していない。
が読めないの？
ajaxの返り値がPromiseでなく、jQuery.Defered === Promise であればいいでしょ
の「結局のところPromiseを使う理由はないってことか」は文意を読めてないだけでしょ
いい加減、疲れるんだけど
に対して「jQueryマンセー」な反論を返すのはただの思想の押しつけ
明らかな間違いを是正するならともかく、どちらが正しいという問題でもないよね
なぜそこまで確信的な論調になるのか、俺には理解できないよ
なんで互換性をなくしてまで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を用意したというのに。
あのさ（苦笑）jQueryの機能が素晴らしいって言ってるんじゃなくて
jQueryの選択は正しいって言ってるの。論理的にね。
どうもjQueryを擁護したら、なんにも考えずにjQueryを叩くやつがいるよな。
jQueryに親でも殺されたか？ｗ
思想の違いってものが理解できないタイプなんだね
他人の思想にいちいち噛みつく辺りが嫌われてるのが理解できないか、理解した上でスルーしてるのか知らないけど
俺からすれば君はjQueryの布教活動しているようにしか見えないけどね
互換性を保ちましょう。（Deferredの仕様は変えない）
標準への対応をしましょう。（DeferredのPromise互換）
将来への対応をしましょう。（Ajax部分を取り除いたSlim Buildの作成）
が俺とjQueryの思想だが、
じゃあお前の思想は？ｗ
お前の思想は何も考えずに適当に思いついたことを言ってるだけだろｗ
jQueryの話題をすることが荒らしというならば
それはお前がjQueryが憎いだけだｗ
ここはjQueryの話題OKのスレのはずだがね
ttp://dictionary.goo.ne.jp/jn/67123/meaning/m0u/ ［名］(スル)《「啓」はひらく、「蒙」はくらいの意》人々に正しい知識を与え、
合理的な考え方をするように教え導くこと。「大衆を―する」「―書」
・標準のAPIを使いましょう
・標準に準拠する為なら後方互換性は切り捨てても構いません
何のために？
念の為に言っておくけど、 jQueryの本質は
DOM操作を関数型風にやること。
で標準のAPIっていうのはFetch APIのことだと思うけど、
jQuery（Slim build） + Fetch APIをすればいいよね？
jQueryは本来の用途であるDOM操作に専念させる。
Fetch APIを使えばいいのに何のために中途半端な対応を選んでいるの？
$.ajaxの戻り値だけをPromiseに変更するの互換性を切り捨てているのに
中途半端対応でしか無いんだけど
jQueryの標準への対応方法（Slim build）ではなくて
中途半端な対応をするべきだという合理的な理由を言ってくれ。
標準のAPIを搭載していないブラウザがあるよね
Android 4.4とか
ってことの意味を理解してないんじゃないだろうか？
互換性があるからこのようにPromiseとDeferredは混ぜて使える。
ttps://jsfiddle.net/axL7p4d4/ 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')
});
反論してる奴は話にならん
jQuery3.0が後方互換性重視な事はで指摘済み
現行jQueryの思想から外れている事は百も承知
標準に合わせるメリットは「学習コスト」と「コードの可搬性」だけで十分だ
上の掛け合いは保守派と革新派が言い争っているに過ぎない
お互いの理想の形が一致しない議論に参加するのは時間の無駄
文体が似ているやつは全員一緒ですよねｗ
> 標準に合わせるメリットは「学習コスト」と「コードの可搬性」だけで十分だ
だから標準＝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ごと導入するがねｗ
面倒くさいから名前もIDも書くつもりはないけど別に隠すしてないよ？
だから、わかると言われても・・・。
もしかして見抜いたり！とか思ってる？
jQueryのDefferedがPromise互換になった今
どんな学習コストがかかるのかも聞いてなかったね。
お前が問題にしているのは「jQuery.ajaxの返り値」であってPromiseは関係ない
ajaxの返り値はjQuery.DeferredでもPromiseでもない抽象オブジェクトで十分だが、それは別の話だ
お前が勝手に話を広げただけ
jQueryでPromiseが使われてるのはajax関連（getやpost含む）ぐらいなもんだろ。
少なくとも俺はajax関連以外でDeferredを使った記憶はない。
他にjQueryの一体どこでDeferred使えっていうんだよｗ
ajaxを標準にしろって言うならば、Fetch APIを使えばいいわけで
非標準のjQueryのajax と 標準のPromiseを混ぜる理由がない。
それに結局Android 4.4はどうするのかにも答えてないし。
jQueryでDeferredが使われてるのはajax関連（getやpost含む）ぐらいなもんだろ。
別にPromiseだけに拘ってはいない
お前がしつこいほどに「jQuery.ajaxの返り値」を論旨に置いてるだけだ
Promiseについては前方互換性、可搬性が主だが、「Promise.allがjQuery.jQuery.Deferred.allに存在しない」もあるので学習コストが同じわけではないだろうな
あー、なるほどねｗ やっとわかったわ。
お前、Promise.all みたいに Deferred.allしたいと思ってるだろｗ
そんなのする必要ねーよ？
jQueryを使っていてDeferredが出てくるのは戻り値としてだけ。
自分でDeferredオブジェクトを作る必要はない。（作りたいなら作ってもいいがね）
っていうかなんのために作るのさ？ｗ
Promise.allを使いたければ、Promise.allをそのまま使え。
その引数にDeferredオブジェクトを渡すことができる。
互換性があるからね。
> jQueryでDeferredが使われてるのはajax関連（getやpost含む）ぐらいなもんだろ。
それはお前が自前でPromiseを使った非同期処理を書いたことがないからそう思うだけだ
何の為にjQuery.Deferredが公開APIになっているのか、を良く考えろ
> それはお前が自前でPromiseを使った非同期処理を書いたことがないからそう思うだけだ
そういうレスするってことはは正しかったようだなｗ
レスするならそうじゃなくてお前がいつどこでjQuery.Deferredを使うのか答えてほしいもんだがｗ
jQuery.DeferredがでてくるのはjQuery ajax関連の戻り値としてだけ。理解した？OK？
> 何の為にjQuery.Deferredが公開APIになっているのか、を良く考えろ
いや、単に世の中にPromiseが普及する前（標準化される前、ブラウザに搭載される前）に
jQuery.Deferredが世に出ただけの話だけど？？？
お前は何のためだと思ってたんだい？
ttps://api.jquery.com/category/deferred-object/ The Deferred object, introduced in jQuery 1.5,
ttps://blog.jquery.com/2011/01/31/jquery-15-released/ jQuery 1.5 Released Posted on January 31, 2011 by John Resig
ttp://caniuse.com/#search=Promise Firefox 27, Chrome 32 Partial Support
2014年01月15日 11時39分 更新 「Google Chrome 32」の安定版リリース
ttp://www.itmedia.co.jp/news/articles/1401/15/news061.html ttps://ja.wikipedia.org/wiki/Mozilla_Firefox%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AE%E5%A4%89%E9%81%B7#Firefox_27 > 2014年2月4日にリリースされ、
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。
jQuery.Deferredは自前でDeferredオブジェクトを作れるようにする為に存在するのであってそれ以上でもそれ以下でもない
お前が「jQuery.Deferredを使う必要がない」というならお前と議論するのは時間の無駄だ
jQuery.Deferredが要らんというならさっさと廃止するようにリクエストしろ
「お前が必要と思うもの」を他人に押し付けるな
なに一人で空回りしてるんだよｗ
「お前が必要と思うもの」を押し付けてるのはお前だろ。
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にしたほうが互換性なくなるから
その違いを埋めるための学習コストやコード修正コストがかかるんだが。
もう少し論理的に考えな。お前は一体どうしてほしいんだ？
重要なのはDeferredがPromise互換になることであって
Deferredをなくすことじゃないんだよ。
DeferredがPromise互換になることで、Promise.allなどの引数に使えるようになる。
そしてDeferredがPromise互換になることは実現済み。
だからこれ以上Deferredを変える必要はない。
むしろDeferredいらん、Promiseに変えろと言っていたのは
お前だったはずだが？廃止するようにリクエストしろよｗ
> 「お前が必要と思うもの」を押し付けてるのはお前だろ。
お前は俺に反論してきたが、俺はお前に何も要求していない(不当な反論があれば釈明はする)
例えば、の「Promise.allをそのまま使え」は余計なお世話だ
(これにはさすがにカチンときて「jQuery.Deferredを廃止するようリクエストしろ」と要求したが、本意ではない)
jQuery.Deferredを使うならjQuery.whenで事足りるからな
「jQuery.Deferredを（今の時代は）使う必要がない」とかいうお前の勝手な考えはどうでもいい
> 新しく使う人→Fetch API使うからDeferredの学習コストは0
お前が何度も指摘しているFetch APIもまるで関係がない
に書いたようにajax()の返り値がPromiseになることを望んでないからな
お前は異常なほどに「jQuery.ajaxの返り値」に拘っているが、俺は一言もajax()には触れてない
> jQueryは自前でPromsiseを実装しなければいけなくなる。
その通り
jQuery.DeferredはPromiseのPolyfillであれば良い
ここまでの流れは基本的にはの指摘通り
俺は俺の思想を主張するが、お前はお前の思想を主張するだけ
思想の違いを理解するために説明しあうことは有意義だが、相手の思想を撤回させようとするのは無駄な事だ
お前はそれをしようとしてる
確かにjQuery.Deferredを書き換えるよりも現実的だな
> 例えば、の「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を（今の時代は）使う必要がない」とかいうお前の勝手な考えはどうでもいい
それをいうなら、お前の勝手な考えはどうでもいいｗ
> お前は異常なほどに「jQuery.ajaxの返り値」に拘っているが、俺は一言もajax()には触れてない
お前がなぜajaxに触れていないかのほうが問題。
jQueryでDeferredがでてくるのはajaxの戻り値としてだけだ。
jQuery.ajaxの返り値に拘るなというのなら、じゃあ聞こう。
どこで Deferred がでてくるんだ？
お前は何にこだわっているのかという質問だよ。
> jQuery.Deferredを廃止してjQuery.Promiseが実装されればの望みは達成できるのかもしれないね
そこはの望みってなんだよｗｗｗって笑うところだねｗ
さて何だったかねぇ。
jQuery.Deferredが気に食わないからjQuery.Promiseに変えろと言ってるだけ
気に食わないだけで、肝心の気に食わない理由がない。
「確かにjQuery.Deferredを書き換えるよりも現実的だな」
「jQuery.Promiseが実装されれば何が嬉しいんだい？」
「jQuery.PromiseはES6のPromiseと全く同じだから学習コストが下がる！」
「全く同じというのならPromiseをそのまま使えばいいのでは？」
「・・・」
ここまでが想定済みの流れｗ
jQueryを使うなら他にPolyfillライブラリを適用するコストをかけたくないからjQueryだけで完結できれば一番良いというだけ
俺の望みはで書いたことですべて
お前に伝わってないようだが、釈明するのは時間の無駄だと悟ったのでもうしない
悪しからず
ttps://jsfiddle.net/axL7p4d4/1/ 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])
});
> 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操作用のライブラリに専念させろよ。
> お前に伝わってないようだが、釈明するのは時間の無駄だと悟ったのでもうしない
それがいいんじゃね？ｗ
俺はお前の言うこと全てに対して反論をしている。
そしてお前は言い返すのをやめた。
万事解決ｗ
jQueryが提供しているAPIにはjQuery.eachやjQuery.mapのように
当時は標準JavaScriptにはなかったが、今は標準で提供されている機能がある。
超古いブラウザのサポートが必要ならjQueryのメソッドを使うが
そうでない場合には俺は標準のメソッドを使っているよ。
Promiseも同じ扱いだろ。現在非対応のブラウザにも対応する必要があるなら
jQuery.Deferred（もしくは PromiseのPolyfill）を使うことになるが、
近い将来Promiseを使えば良くなる。jQuery.Deferredを使う必要はない。
その今の時代においてjQuery.Promiseに仕様変更してまで
jQuery.Promiseを使いたいっていう考えが意味不明。
素直に標準のPromiseを使えばいいじゃねーかw
ここは相変わらずだな
「意味不明なら無理に反論しなけりゃいい」っていう考えがおかしい。
意味不明なことを言っているのなら、意味不明と言ってあげることが本人のためだし
意味不明ということで、相手に反論の余地を与えている。
そこで相手がちゃんと意味を説明できれば、それでいいんだが、
意味不明と言われて黙るってことは、どういうことかがわかるでしょう？
意味不明だっていうことは反論じゃない。
誤字脱字の指摘と同様、意味を明確にしろっていう指摘でしかないよ
（誤字脱字を指摘した程度で、反論したって思うやつはいないｗ）
意味不明な理由を「相手が自分よりはるかに知識量が低いから頓珍漢な事しか言えない」と決めつけて理解を放棄している時点で議論が成り立ってない
自分が相手より格上だと確認して優越感に浸っているだけ
> 意味不明なら意味を理解しようと努力するのが普通
じゃああんたは努力すれば？ｗ
あれだけ説明されてまだ意味不明とか言ってる時点で読解力が欠如してる
じゃあまとめてみる？
の主張・・・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オブジェクトを作ったりすることにすでになれてるから変わらない方が学習コストが下がる。
反論あるのならお待ちしています。
ホント論理のすり替えが好きだよな
> 99のいう学習コストはDOM API習得済/jQuery初心者が対象だろうに
話をちゃんと読む気がないのか？
DOM API習得済であれば、当然標準のPromiseとFetch APIも習得済みだろ
jQueryはDOM操作専用に使って、Ajax部分はFetch APIを使うから、
Defferedは出てこないって話なんだが。
そんなんならjQueryなんか要らんわ
jQuery使ってんのにPolyfillまで適用するのは面倒くさすぎる
あまえのFetch APIを使えという指示に従う必要はないから
→jQueryが気に入らないなら使わなければいいよ
→く( ﾟдﾟ)ﾎﾟｶｰﾝ
なんでわざとらしく間違えるから。
どうせやると思ったからあえて
「jQueryはDOM操作専用」って言ったにもかからわず
俺がjQueryを使うなと言ったことにする。
はっきり言うけど、あんた卑怯だよね。
> jQuery使ってんのにPolyfillまで適用するのは面倒くさすぎる
ならjQuery使えば？
> あまえのFetch APIを使えという指示に従う必要はないから
誰もお前に言ってないよ。標準を使いたいって人はFetch APIを使えばいいと言ってるだけ。
jQueryのAjax関連の戻り値をPromiseにしたって、一部しか標準になってない。
標準がいいならばFetch APIを使うのが一番だろ？
そしてjQueryはDOM操作専用で使えば良い。
> 「jQueryはDOM操作専用」って言ったにもかからわず
「jQueryはDOM操作専用」なら、ajaxもDeferredも存在しないはずだが？
てめーの勝手なイメージを押し付けているだけという事にいい加減気が付け
まーたわざとらしく間違える
「jQueryはDOM操作専用に使って」って言ったのに
「jQueryはDOM操作専用だ」と言ったことにしようとしてる。
本当にお前卑怯だな。
jQueryは最初はDOM操作＋ブラウザ間の違いの吸収＋Ajaxとして作られた。
ブラウザ間の違いが減って、使いやすいAPIがでてきて
ようやくjQueryに追いついてきたから、
jQueryはDOM操作専用として使えば十分だって話だ。
逆に言えば、DOM APIの設計が変わらない限り
jQueryはDOM操作用のすぐれたライブラリといえる。
（設計を変えるっていうのはjQueryオブジェクトのようなDOMコレクションに
DOM操作メソッドを追加するっていうことね。これをやらずにいくら
メソッドを増やしたところでjQueryには追いつけない）
標準に合わせる意義をお前が理解してないから「jQueryに追いついてきた」とかいう発想になるのさ
お前にとっては変わらず「>99の意見は意味不明」
まーた意味がわからんことを言う。
標準のAPIの仕様がjQueryのシンプルさに
追いついてきたって話だろうが。
「非標準なもの」を使うと、特定のブラウザでしか
動かないものになるからだ。
という話がある。だから「標準」という言葉を使った。
だがよく考えてみよう。
標準の反対は非標準、つまり標準ではないものを使うことであって
標準なものを使っているライブラリにたいして
標準のメリットを言ったところで意味は無いのである。
俺は人がいるところに行くだけだから。
あの議論は何だったんだ
そんなの関係なく俺は適当にやるし、
仲間（？）割れしてなにやってるんだろうなって感じだよなｗ
このスレの住民が向こうに書き込んでるとは考えなかったんだろうね
jQueryの話をする場所が増えているだけなのに気づいていない。
俺としてもスルーしてほしいんだが（笑）
そうすれば、質問者 と それに答える俺 という
素晴らしい流れてできるだろう？
炎上商法と比べたらド過疎の方がいくらかマシ
感想を書くだけで炎上するとは思えないが
さっぱり分からないが、まあ俺としてはNGIDにしてくれることで
反論が一切されないっていうのは楽な状況でもある
（だってNGIDにしたら見えなくなるから反論したくても分からない）
俺がいなくても荒れるじゃねーかって話。
あの例のテンプレ押し付けようとしているやつが
一番の元凶なんだよな。本人がわかってないのが一番たちが悪い。
言っとくけどあれ俺じゃないよｗ
ageればIDでるんでよろしく
2chブラウザで sage チェック外すだけだから「面倒くさい」は理由にならないけどな
○ 何かと理由をつけてIDを出さないだろうな
定義リストをforで回したいです
<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; で重ねています。
よろしくお願いします。
試してないのでごめんだけど
透明なdivをcanvasの上に乗せちゃうってのはどうだろ?
そもそも、それは無理だろ。
イベントハンドラーの中で、if文で処理を分けるとか？
disableは普通あるぞ
touch-action: manipulation;
かねえ
試してみて
ttps://w3c.github.io/pointerevents/#the-touch-action-css-property ttps://triple-underscore.github.io/pointerevents-ja.html#the-touch-action-css-property #canvas2・・・とはどう違うのでしょうか？
変わりませんでした。
サイドバーをiframeを使って作って画面に追加してるんですが
その部分をreact-devtoolが反応してくれません。
urlがchrome-extension://XXXX/sidebar.html
になっているからかと思っているんですがdevtoolで動作させる方法ご存じないでしょうか？
ttps://codepen.io/valscion/pen/jBNjja?editors=0010 react公式にあるドキュメントのコードなんですけど
62行目ののメソッド、
this.setState({scale: 'c', temperature});
でなぜ動くのかわかりません
自分は
this.setState({scale: 'c', temperature: temperature });
だと思うのですが、実際コードをこのように書き換えてもちゃんと動きますし
どうしてなのか理由を教えてほしいです
すみません自己解決しました
ttps://stackoverflow.com/questions/42863367/weird-setstate-usage ES6の新しい表記法みたいです。
使い方が簡単でシンプルのものが欲しいです。
まず、「ルーティング」の定義から説明してみたら？
ttps://ja.wikipedia.org/wiki/%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0 こまけー
ルーティングはフレームワークと密接に
結びついているものなので
単体では存在しません。
他にも圧縮率など優れたライブラリがあったら教えて欲しいです
npmでzipやunzipで検索して使いやすそうなもん選べばいいと思うよ
（ container = new PIXI.Container(); ）
幾つかのパーツをひとまとめにした画像をスプライトに分割して使う時はさ
new PIXI.BaseTexture(source, scaleMode, resolution)
でペーステクスチャ作って
new PIXI.Texture(baseTexture, frame, orig, trim, rotate)
でパーツに分けて new PIXI.Sprite(texture) でやるのかなと思ったけど
デフォなやり方ってあるんすか？
あと分割せずにRectangleとかで範囲指定して
表示領域を変化させる方法とかあります？
あったわ！(ヽ´ω`)
ttps://github.com/kittykatattack/learningPixi#make-a-sprite-from-a-tileset-sub-image jsonでテクスチャアトラスデータつくってあとはそこで指定した名前でspriteつくるだけじゃないのかな？
ありがとう
どこかのブログで見かけはしたけど
わたしにはちょいむずいな(ヽ´ω`)
jsZIPが簡単
だけどjsでM単位のファイルはやめとけよ。
Chromeで試したけどどれもこれも止まって使い物にならんかったぞ。
使い方が悪いのでは？
巨大なファイルで時間がかかるのはわかりきっているのだから
ライブラリに細かく分割して処理するための機能があるか、
もしなければ別スレッドでやればいいだけだし
ただ10MBくらいだと同期でもいいくらいのはずだし、
反対に100MBを超えてくるとブラウザのメモリ制限に引っかかる恐れが出てくるので
シーケンシャルに作成しながらDBに保存していったり、サーバに送ると言った手間が要りそう
いつの時代の話をしてるんだ？？
クアイアント側でzipするの？
今の時代だよ
数百MBのファイルを扱うと
実際はその２倍、３倍のメモリを使うことにもなりかねないからね
デスクトップEdgeでも512MBしか保証されていない
Lazy.js > Lo-Dash > Underscore
Lazy.js って使われているの？
version 0.4.2 だけど
ZIPファイルをJavaScriptで扱ったけど1.1GBまでできたぞ
> 数百MBのファイルを扱うと
> 実際はその２倍、３倍のメモリを使うことにもなりかねないからね
ん？ なんか根拠あっていってんの？
まさか5MBのファイルを扱う時に15MB使っていたから、
100MBなら300MBに違いないとか思ってんの？
5MBのファイルに+10MBのワークメモリを使用するのなら
100MBなら+10MBで110MBですよ
なんで3倍とか思っちゃったのかな？ｗ
> 速さでは遅延評価する、Lazy.js が速いらしいけど、
それって遅延評価することで計算が省ける場合に限っての話でしょ？
殆どの計算は遅延評価のオーバーヘッドがないぶん
普通に計算したほうが速いと思うけど
ホラ吹きかよ
何で煽ってるのかわからないな そりゃ実装の工夫次第だけど、
まず原本ファイルがあって、各チャンクを圧縮したり、暗号化したり、
最後にZIPファイルとしたり固めてたら、
一時的に元ファイルの２倍３倍使ってしまうこともあり得るでしょ
だから512MBが上限だと思うなら、そういう『工夫のない実装』だと
100MBくらいが安心してサポートできる上限だ
100MBを超えてくればメモリ管理を特に意識する必要が出てくる
と言ってるだけなんだよ？ 全くもって自明でしょ？
でたでた後付け厨w
俺の至らないレスで気分を害したことは謝る
本当に済まない
本当に済まない
本当に済まない
だけど俺は終始真面目に話をしてるんだから
頼むから煽らずに建設的な話を続けて欲しい
なぜそんなに煽ってくるのか困惑してる
突っ込みに対して補足を入れたら後付け厨なのか？
それとも最初から突っ込みが絶対入らない呪文を書けるとでも思ってるのか？
いっぺんに思考の全てを文章にして相手にぶつけることなんてできないんだから
こうして会話して行ってお互い真意を探るのは良いことだろうよ
それをあざ笑ったり煽るのは、真意を探ろうとかいう気持ちじゃなくて
最初から攻撃目的の突っ込みじゃないのか？
俺はそれは絶対に間違ってると思うよ
たった一行の草生やした煽りレスに一々構うのは労力の無駄だぞ
こいつは相手したらだめだよ
小学生並の屁理屈で自分が偉いと勘違いするタイプ
そもそも、相手の話のコアが通じない時点で立派なコミュニケーション障害なのにその認識の差異を必死でアピールというどうしようもないやつ
1GBの動画fileをスライス
↓
スライスしたfileをAES暗号化
↓
ローカル上でZIP化
↓
ローカルに保存
IE11で何度か試してみたけど1GBまでは成功したぞ
環境による
逆にブラウザが保証してくれてもOSにブラウザプロセス毎殺されることもあるだろうし
まあ普通のデスクトップツールならファイルとして書き出しながら処理するから
極端な話圧縮辞書くらいしかメモリ使わなくても済むが
WebのJSでやるのはちと大変だろうな
環境によるなら、3倍メモリを使うのも環境によるわけで、
えらっそーに（笑）断言するべきじゃなかったですねｗｗｗｗ
誰か何を断言したの？
主観が標準
思い込んだことが標準
否定されると事実をねじ曲げて牙を向ける
指摘されると挙げ足をとって話をそらす
またいつものこう言った輩だろ。
主観条件を想像して平気でこんな発言している。
>>実際は2倍、3倍のメモリを使うことにもなりかねないからね
今の時代だよ
数百MBのファイルを扱うと
実際はその２倍、３倍のメモリを使うことにもなりかねないからね
デスクトップEdgeでも512MBしか保証されていない
そうや3倍とかにもなりかねんのや
不安だろう？
我が言霊の力じゃよ
こうやって言葉で揺さぶりをかければ
相手に不安を与えるもんなんじゃよ
これが人生経験というものかのう
下手すれば5倍、いや10倍、もっといけば100倍にも
なるかもしれんのう。そうなったらどうするんじゃ？
おまえって生きてて悲しくならないの？
勝てない喧嘩なら最初からふっかけるなよ
その判断すらできないからいつもそんな惨めな人生おくることになるんだぞ
そもそもローカルで512Mとか技術ありませんと認めたようなもんだろw
Edgeでjs制御すればGB単位の処理する方法はあるからな。
まるで道具の使い方を知らない土人だな。
その何GBでもOKな自身のEdgeに少し分けてもらえばいい
否定したいからじゃね
アリバイがないことがお前が犯人の証拠！
正論や事実を突きつけられると突拍子も無いことや極端な例えを持ち出す人とたまにいるよね。
これに該当する人も必ず書き込みするよ
人と違う考え方が格好いいとかズレた考えの人もいる。
ただ偏屈なだけかも。
今回のは見当違いというか噛み合っていない
のことか？
天の邪鬼や社会不適合者の類いだな
どこかで、見たような気がするのだが、探せない
それと、lodash の日本語訳は無い？
無いよな
結局、lodash厨は、この板で普及活動だけして、日本語訳を作らなかったのか
お前の能力の低さは隠せないぞｗ
lodash、英語とか日本語以前に
コードがあるからそれで十分じゃね？
関数の使い方と戻り値から何をしてるのかわかるでしょ
たとえば何か１ファイルを取ってくるのだったら
fetchXxx()という名前の関数にするのが良いと思うぞ
直接ユーザーに出さないのなら殆ど開発者の好みの問題でどうでもいいとも言える
ただね、Fetch APIっていうのはとても素直に見えて、
実は少し細かいことをやると特殊な仕様の宝庫だからね
つまり、結局は、ブラウザ上で「フェッチ」するためのAPIであって、
Nodeでもどこでも使いやすい、汎用的なhttp通信のためのAPIではないということ
だからおれは、もしAPIを提供するときにfetch感を出すときは、取得する物と方法を決め打ちして、
中間を見せないfetchXxxという名前の関数にしなさいといったの
で、結局はfetchでもrequestでも、環境にそぐわないAPIの叩き方、使われ方をされることに
どういう対処しているのかが、例え君がそういう使い方をしないとしても、『良いAPI』を見極めるために重要だと思う
でも一番いいのは、http通信なんてコード量大したことないんだから、自分でラッパーを書くこと
そしてその名前をfetchでもrequestでも無いものにしておくこと
標準的な物に沿うことも重要だけど、それがはっきりしていない場合はあえて開き直って完全独自にすることも重要
何が言いたいのか
俺が先に書いておけばよかったね。といっても「どちらも流行ってない」が答え
事実だけど煽り見えるだけなので書くのが面倒で放置していたら長文野郎に絡まれたねw
まあ俺も長文野郎だけどw
がごちゃごちゃ言い訳がましいことを言ってるのは
"ウェブ標準を推奨したいけど欠点があるから" なんだよ。
はっきり（今の）ウェブ標準はクソと言い放ってしまえばいいのだけれど
この人、ウェブ標準大好きな人だからそれが言えないんだろうねw
まず今の標準化されてるブラウザのFetch APIはクソ。なぜならもともとAjax（XHR）で
できていたはずのキャンセル機能や進捗情報ができなくなってしまっているから。
それもこれもPromiseなんか採用してしまったから。
だからFetchもRequestもPromiseを使っているものは現時点では全部アウト
そして今頑張ってFetch APIにキャンセルと進捗状況を取得できる機能が追加されようとしてる。
本来はPromiseに追加すべき機能だけど、Promise作ってる奴らが動こうとしなから
Fetch APIの方に組み込もうとしている（将来それがうまくいけばPromiseに移植されるかも）
このように現在は "ウェブ標準" のFetch APIは制限があり仕様は過渡期であるため薦めることができない。
そのことをはっきり言わないからはごまかすようなレスになってる。俺ははっきりいう。
（今の）Fetch APIはクソ。Requestはウェブのような標準仕様がないのでクソ
Promiseを採用しているならば、それもクソ。よってどちらも流行ってるなんて言えるもんじゃない。
それから完全独自実装なんて手間がかかるだけ。バカがやること。これだけはやってはいけない。
とは言え現時点では標準もブラウザでネイティブに動かすのも諦めるしかない。
だからSuperAgentなんかが有名でいいんじゃないか？ 将来は別の何かに置き換えることになるかもしれないが
その時、完全独自実装の大量のコードを読み解くよりも、
ライブラリを使って少ないコードでシンプルに書いていれば変更は楽になる。
条件を満たすライブラリがあれば中の人が全部吸収してくれるからベスト
自分でXHRやhttp使ってラッパー書いてもいいけどね
この辺はpolyfillで何とかなりそうだけど, これに加えてCookieの取り扱いがブラウザとnode-fetchで違っていて辛そうだと思った
promise自体がクソだとは思わないけど現時点で機能不足だというのは確かにその通りだと思うわ, 少なくともPromise/A+の現時点の規格では時間の掛かる処理にはとても使えない
progressとかcancelは一応under discussionみたいだし将来に期待しておくことにする(それまではQでも使えばいいのかな)
とりあえずSuperAgentとpromiseベースだけどprogressとcancelが出来るaxiosとで比較検討してみますわ
どうもありがとう
だってまずはヘッダを取得して、そこから更に何をするかとなるのが自然だから、そこまでは普通
fetchが出すResponseがReadableStreamを返す仕組みなのも苦労とかじゃなくてごく自然
ただReadableStream自体は微妙というかObservableであったほうが良いとは思う
そしてキャンセルはあるべきだけど、なぜか皆Promiseに付けろと思うけどそれは間違い
実際はPromiseに生えてたら凄い使いにくいし、Promiseの概念上分かりにくことになるのは考えたら分かる
だから、.cancelの提案なんてない。代わりにCancelToken型の用に仕組みが分離してあるものが提案されている
これならObservableにも使えるしずっと筋が良い
だからFetch APIはPromiseではないものを返すべきだってことなんだが。
お前の結論からもPromiseを返すのがおかしいという結論にたどり着いてるじゃんか
目的はPromiseを返すことではない。Promiseは手段でしかない。
時間がかかるから非同期を使う。ということはよくよく考えてみると
非同期は時間がかかる以上キャンセルと進捗状況の確認機能は必須であることに気づく
だからPromise自体筋が悪い仕様だったってことなんだよ。
という考え方だから便利な機能はサポートされない運命
実用的なPromiseの一つであるbluebirdはキャンセル機能が搭載されている
ttp://bluebirdjs.com/docs/api/cancellation.html > 実際はPromiseに生えてたら凄い使いにくいし、Promiseの概念上分かりにくことになるのは考えたら分かる
それはあなたの感想ですよね？
> だから、.cancelの提案なんてない。
普通にあるが？
ここまでの流れを示しておくわ
Fetch の中断と Promise のキャンセル方法の標準化
ttps://blog.jxck.io/entries/2017-07-19/aborting-fetch.html あーあー、本来はPromiseにキャンセル機能が搭載されて
シンプルになったはずなのになー。
理想の案ではなくて次点の案ですすんでるとはな
今更に否定されたCancelTokenとか持ち出されてもw
> 要約すると以下のようなものだった。
>
> CancelToken (.NET の知見) という API 経由で Promise をキャンセルする。
> キャンセルはエラーとは違うため、 resolve/reject 以外に 3 つめの状態を追加する。
> しかし、結論から言うと議論の途中で頓挫してしまった。
>
> なんで頓挫したかの詳細は、仕様策定の中心だった domenic の悲痛な一言に集約されている。
>
> Why was this proposal withdrawn? #70
今最も、そして唯一のPromiseのキャンセル関連の仕様なのは間違いない。
ttps://dictionary.goo.ne.jp/jn/162000/meaning/m0u/ とん‐ざ【頓挫】の意味
１ 勢いが急に弱まること。また、計画や事業などが途中で遂行できなくなること。
「活動に一頓挫を来?(きた)?す」「不況で事業が頓挫する」
棄却に相当するものは事業が失敗する、会社が潰れるなどのことだよ。
頓挫というのは勢いが急に弱まる事を言う
誰もが何らかの仕組みが早く欲しいと思い続けてきたキャンセル周りにおいて、その場しのぎにしかならない価値の薄い.cancelではなく
ようやく新しい構文だとか何もかも含めて全体的に上手くいきそうな提案が出てきたけどスムーズに進まなかったという、大きな期待と逸る気持ちがあってこそ出た大袈裟な失望の言葉なのに、
ES DiscussやMeetingを追ってすらもない奴らが自分の意見を肯定するためだけに書かれた気持ちや前提を汲まず悪用するのは気分が悪いね
> 大きな期待と逸る気持ちがあってこそ出た大袈裟な失望の言葉なのに、
それはあなたの感想ですよね？
何処かに定義でもあるんですか？
ステージが進まないのなんて珍しくないし、実際提案の勢いに変化が生じた訳ではない、ただキャンセル周りの仕様がサクサク決まることは難しそうという不安感は出てきた
とは言っても.cancelがあり得ない以上、似た仕様になる事は確実
じゃあまずどうして.cancelが失敗したのか、そして今CancelTokenは奴に否定されたのに残ったのかを考えた方が良い
その上で具体的な疑問があれば答えるから
リスクが大きいってことだな。
SuperAgentもしくはaxiosを使うのが現実的
じゃあなんで頓挫したのか教えて
なんで頓挫したかの詳細は、仕様策定の中心だった domenic の悲痛な一言に集約されている。
ttps://github.com/tc39/proposal-cancelable-promises/issues/70#issuecomment-267414933 ttps://github.com/tc39/proposal-cancelable-promises 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には撤退という意味がある
空っぽになってしまった、これこそがCancelTokenである
const cancelToken = new CancelToken(cancel => {
cancelButton.onclick = () => cancel("The cancel button was clicked");
});
performCancelableOperation(cancelToken);
ttps://github.com/tc39/proposal-cancelable-promises/tree/0e769fda8e16bff0feffe964fddc43dcd86668ba 削除されてしまったのか？
削除されたのにリポジトリを残してるのは
単なるあてつけだとかるが
ではなぜ
CancelTokenはなぜ仕様の内容が
削除されてしまったのか？ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
> そして今CancelTokenは奴に否定されたのに残ったのかを考えた方が良い
残ってないよ。
リポジトリの中身は削除されてる
元をたどればで
CancelToken『型の用に仕組みが分離してあるもの』
と書いたように、俺はCancelTokenそれだけに拘って考えて言っていたのではない
例えば俺がstage0だなんだ言ったのはCancellation APIを意識してたから
そこんところごっちゃにしてたのは本当に謝る
CancelTokenが消えたのは、結局CancelablePromiseが否定されたのを、
じゃあcancel状態の代わりにelse状態を持ってればいいだろというように
結局皮が剥け切れて無かったから、そこを奴に付かれた
だから逆に言うと、「分離」してある形になるのはより確実になってきたと言える
俺が言いたいのはそこ
今も生きてる仕様がどこに書いてあるかを言えばいい
俺が言ってたのはこれ
ttps://github.com/tc39/proposal-cancellation ⇒
ttp://asaswq3wq.sblo.jp/article/181819223.html 興味がある人だけ見てください。
KH0BV0X79E
ttps://uppy.io/examples/dashboard/ このライブラリすご
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
少しでも多くの方の役に立ちたいです
グーグルで検索するといいかも『金持ちになりたい 鎌野介メソッド』
NHNSG
