JavaScript ライブラリ総合質問所 vol.5 [無断転載禁止]©2ch.net
JavaScriptライブラリ を自ら学ぶ人のための質問スレッドです。
■質問を書く上で
(1) 質問にならない投稿はご遠慮ください。(煽り、コード制作依頼など)
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 長い間連続して質問する場合にレス番を名前にしてあれば、質問の流れが回答者に伝わりやすくなります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。質問テンプレートを活用してみてください。
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【ライブラリ】使用しているライブラリ名を記入してください。(ex: jQuery)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/ ルーティングのライブラリでおすすめのものはなんでしょうか？
使い方が簡単でシンプルのものが欲しいです。 >>210
ルーティングはフレームワークと密接に
結びついているものなので
単体では存在しません。 zipなら定番はどれですか？
他にも圧縮率など優れたライブラリがあったら教えて欲しいです 定番があるほどポピュラーなもんじゃないからなぁ
npmでzipやunzipで検索して使いやすそうなもん選べばいいと思うよ 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とかで範囲指定して
表示領域を変化させる方法とかあります？ react-pixiの使い心地を教えてくれ!(ヽ´ω`) >>218
jsonでテクスチャアトラスデータつくってあとはそこで指定した名前でspriteつくるだけじゃないのかな？ >>221
ありがとう
どこかのブログで見かけはしたけど
わたしにはちょいむずいな(ヽ´ω`) テクスチャアトラス記事 真下にあったわ・・・(ヽ´ω`) >>215
jsZIPが簡単
だけどjsでM単位のファイルはやめとけよ。 html2canvas（要素+canvas）をSVGに変換する方法ありますか？ jsでZIP処理するときは小さなファイルのみにしておけよ。
Chromeで試したけどどれもこれも止まって使い物にならんかったぞ。 >>227
使い方が悪いのでは？
巨大なファイルで時間がかかるのはわかりきっているのだから
ライブラリに細かく分割して処理するための機能があるか、
もしなければ別スレッドでやればいいだけだし その通り
ただ10MBくらいだと同期でもいいくらいのはずだし、
反対に100MBを超えてくるとブラウザのメモリ制限に引っかかる恐れが出てくるので
シーケンシャルに作成しながらDBに保存していったり、サーバに送ると言った手間が要りそう 元からnodeの話じゃなかったの？
クアイアント側でzipするの？ >>230
今の時代だよ
数百MBのファイルを扱うと
実際はその２倍、３倍のメモリを使うことにもなりかねないからね
デスクトップEdgeでも512MBしか保証されていない 速さでは遅延評価する、Lazy.js が速いらしいけど、
Lazy.js > Lo-Dash > Underscore
Lazy.js って使われているの？
version 0.4.2 だけど >>230
ZIPファイルをJavaScriptで扱ったけど1.1GBまでできたぞ >>232
> 数百MBのファイルを扱うと
> 実際はその２倍、３倍のメモリを使うことにもなりかねないからね
ん？ なんか根拠あっていってんの？
まさか5MBのファイルを扱う時に15MB使っていたから、
100MBなら300MBに違いないとか思ってんの？
5MBのファイルに+10MBのワークメモリを使用するのなら
100MBなら+10MBで110MBですよ
なんで3倍とか思っちゃったのかな？ｗ >>233
> 速さでは遅延評価する、Lazy.js が速いらしいけど、
それって遅延評価することで計算が省ける場合に限っての話でしょ？
殆どの計算は遅延評価のオーバーヘッドがないぶん
普通に計算したほうが速いと思うけど >>235
何で煽ってるのかわからないな そりゃ実装の工夫次第だけど、
まず原本ファイルがあって、各チャンクを圧縮したり、暗号化したり、
最後にZIPファイルとしたり固めてたら、
一時的に元ファイルの２倍３倍使ってしまうこともあり得るでしょ
だから512MBが上限だと思うなら、そういう『工夫のない実装』だと
100MBくらいが安心してサポートできる上限だ
100MBを超えてくればメモリ管理を特に意識する必要が出てくる
と言ってるだけなんだよ？ 全くもって自明でしょ？ >>239,240
俺の至らないレスで気分を害したことは謝る
本当に済まない
本当に済まない
本当に済まない
だけど俺は終始真面目に話をしてるんだから
頼むから煽らずに建設的な話を続けて欲しい
なぜそんなに煽ってくるのか困惑してる あと後付け厨とか言うのもよく理解ができない
突っ込みに対して補足を入れたら後付け厨なのか？
それとも最初から突っ込みが絶対入らない呪文を書けるとでも思ってるのか？
いっぺんに思考の全てを文章にして相手にぶつけることなんてできないんだから
こうして会話して行ってお互い真意を探るのは良いことだろうよ
それをあざ笑ったり煽るのは、真意を探ろうとかいう気持ちじゃなくて
最初から攻撃目的の突っ込みじゃないのか？
俺はそれは絶対に間違ってると思うよ コミュニケーションを試みるのは立派だと思うけど
たった一行の草生やした煽りレスに一々構うのは労力の無駄だぞ 心当たりあることを指摘されると許せなくなるような基地外多すぎだろ。 またいつもの基地外か
こいつは相手したらだめだよ
小学生並の屁理屈で自分が偉いと勘違いするタイプ
そもそも、相手の話のコアが通じない時点で立派なコミュニケーション障害なのにその認識の差異を必死でアピールというどうしようもないやつ >>234
>>232
>>238
1GBの動画fileをスライス
↓
スライスしたfileをAES暗号化
↓
ローカル上でZIP化
↓
ローカルに保存
IE11で何度か試してみたけど1GBまでは成功したぞ 保証と上限はまた話が変わってくるだろうからな
逆にブラウザが保証してくれてもOSにブラウザプロセス毎殺されることもあるだろうし
まあ普通のデスクトップツールならファイルとして書き出しながら処理するから
極端な話圧縮辞書くらいしかメモリ使わなくても済むが
WebのJSでやるのはちと大変だろうな >>248
環境によるなら、3倍メモリを使うのも環境によるわけで、
えらっそーに（笑）断言するべきじゃなかったですねｗｗｗｗ だれも環境によらず３倍のメモリを使う！なんて断言してはいないな >>250
主観が標準
思い込んだことが標準
否定されると事実をねじ曲げて牙を向ける
指摘されると挙げ足をとって話をそらす
またいつものこう言った輩だろ。
主観条件を想像して平気でこんな発言している。
>>実際は2倍、3倍のメモリを使うことにもなりかねないからね
>>230
今の時代だよ
数百MBのファイルを扱うと
実際はその２倍、３倍のメモリを使うことにもなりかねないからね
デスクトップEdgeでも512MBしか保証されていない どや？ 不安になってきたろ？
そうや3倍とかにもなりかねんのや
不安だろう？
我が言霊の力じゃよ 何の根拠もないことでも
こうやって言葉で揺さぶりをかければ
相手に不安を与えるもんなんじゃよ
これが人生経験というものかのう よく分からんが、人生経験豊富な揺さぶりで不安になったから噛み付いてたってこと？ ほっほっほ。3倍じゃよ3倍。3倍にもなるんじゃ。
下手すれば5倍、いや10倍、もっといけば100倍にも
なるかもしれんのう。そうなったらどうするんじゃ？ 思いつきの屁理屈で絡んで、どうにもならなくなったら茶化して煽るとかさ
おまえって生きてて悲しくならないの？
勝てない喧嘩なら最初からふっかけるなよ
その判断すらできないからいつもそんな惨めな人生おくることになるんだぞ >>253
そもそもローカルで512Mとか技術ありませんと認めたようなもんだろw
Edgeでjs制御すればGB単位の処理する方法はあるからな。
まるで道具の使い方を知らない土人だな。 10MBのファイルでも下手すりゃ1GBのメモリ食うよ ワーキングメモリが512bitしか無いのに、全て思い込みで埋まってる奴が要るようだな
その何GBでもOKな自身のEdgeに少し分けてもらえばいい お前が犯人だ！違うっていうのなら証拠を見せろ！
アリバイがないことがお前が犯人の証拠！ >>261
正論や事実を突きつけられると突拍子も無いことや極端な例えを持ち出す人とたまにいるよね。 天の邪鬼、基地外、図星、声闘
これに該当する人も必ず書き込みするよ >>261
人と違う考え方が格好いいとかズレた考えの人もいる。
ただ偏屈なだけかも。 人と違う考えをあえて提示するのは有益だが
今回のは見当違いというか噛み合っていない underscore, lodash の機能を、左右に表示して比較した、サイトはある？
どこかで、見たような気がするのだが、探せない
それと、lodash の日本語訳は無い？
無いよな
結局、lodash厨は、この板で普及活動だけして、日本語訳を作らなかったのか 偉そうな言い方で英語がわかりませんって言っても
お前の能力の低さは隠せないぞｗ
lodash、英語とか日本語以前に
コードがあるからそれで十分じゃね？
関数の使い方と戻り値から何をしてるのかわかるでしょ お年寄りは日本語じゃないと拒否反応起こしちゃうからね ブラウザとNode.js両方で使えるライブラリを書くときってisomorphic-fetchとかfetch-ponyfillみたいなfetch API系とrequest(-promise), どっちが流行ってる？ なにをしたいのか分からんけど
たとえば何か１ファイルを取ってくるのだったら
fetchXxx()という名前の関数にするのが良いと思うぞ ライブラリ内部でHTTP通信する場合に採用するライブラリの選定について, であります そこはfetchかrequestかに限らずよく吟味した方が良いとも言えるし、
直接ユーザーに出さないのなら殆ど開発者の好みの問題でどうでもいいとも言える
ただね、Fetch APIっていうのはとても素直に見えて、
実は少し細かいことをやると特殊な仕様の宝庫だからね
つまり、結局は、ブラウザ上で「フェッチ」するためのAPIであって、
Nodeでもどこでも使いやすい、汎用的なhttp通信のためのAPIではないということ
だからおれは、もしAPIを提供するときにfetch感を出すときは、取得する物と方法を決め打ちして、
中間を見せないfetchXxxという名前の関数にしなさいといったの
で、結局はfetchでもrequestでも、環境にそぐわないAPIの叩き方、使われ方をされることに
どういう対処しているのかが、例え君がそういう使い方をしないとしても、『良いAPI』を見極めるために重要だと思う
でも一番いいのは、http通信なんてコード量大したことないんだから、自分でラッパーを書くこと
そしてその名前をfetchでもrequestでも無いものにしておくこと
標準的な物に沿うことも重要だけど、それがはっきりしていない場合はあえて開き直って完全独自にすることも重要 >>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なんかが有名でいいんじゃないか？ 将来は別の何かに置き換えることになるかもしれないが
その時、完全独自実装の大量のコードを読み解くよりも、
ライブラリを使って少ないコードでシンプルに書いていれば変更は楽になる。 この荒らしに同調するのも癪だけど実際そんなところだよ
条件を満たすライブラリがあれば中の人が全部吸収してくれるからベスト
自分でXHRやhttp使ってラッパー書いてもいいけどね 成程, 確かfetchはprogress取得のためにReadableStreamを取れるようにして苦労してるみたいね
この辺はpolyfillで何とかなりそうだけど, これに加えてCookieの取り扱いがブラウザとnode-fetchで違っていて辛そうだと思った
promise自体がクソだとは思わないけど現時点で機能不足だというのは確かにその通りだと思うわ, 少なくともPromise/A+の現時点の規格では時間の掛かる処理にはとても使えない
progressとかcancelは一応under discussionみたいだし将来に期待しておくことにする(それまではQでも使えばいいのかな)
とりあえずSuperAgentとpromiseベースだけどprogressとcancelが出来るaxiosとで比較検討してみますわ
どうもありがとう その論調何度か聞くけど、別にfetch自体はまず今の仕様のPromiseを返すのでおかしくないと思うけどな
だってまずはヘッダを取得して、そこから更に何をするかとなるのが自然だから、そこまでは普通
fetchが出すResponseがReadableStreamを返す仕組みなのも苦労とかじゃなくてごく自然
ただReadableStream自体は微妙というかObservableであったほうが良いとは思う
そしてキャンセルはあるべきだけど、なぜか皆Promiseに付けろと思うけどそれは間違い
実際はPromiseに生えてたら凄い使いにくいし、Promiseの概念上分かりにくことになるのは考えたら分かる
だから、.cancelの提案なんてない。代わりにCancelToken型の用に仕組みが分離してあるものが提案されている
これならObservableにも使えるしずっと筋が良い > 実際はPromiseに生えてたら凄い使いにくいし
だからFetch APIはPromiseではないものを返すべきだってことなんだが。
お前の結論からもPromiseを返すのがおかしいという結論にたどり着いてるじゃんか
目的はPromiseを返すことではない。Promiseは手段でしかない。
時間がかかるから非同期を使う。ということはよくよく考えてみると
非同期は時間がかかる以上キャンセルと進捗状況の確認機能は必須であることに気づく
だからPromise自体筋が悪い仕様だったってことなんだよ。 EcmaScriptのPromiseは基本的機能だけをサポートする
という考え方だから便利な機能はサポートされない運命
実用的なPromiseの一つであるbluebirdはキャンセル機能が搭載されている
http://bluebirdjs.com/docs/api/cancellation.html >>284
> 実際はPromiseに生えてたら凄い使いにくいし、Promiseの概念上分かりにくことになるのは考えたら分かる
それはあなたの感想ですよね？
> だから、.cancelの提案なんてない。
普通にあるが？ 誰かが妄想でFetch APIとPromiseに関する嘘の流れを作る前に
ここまでの流れを示しておくわ
Fetch の中断と Promise のキャンセル方法の標準化
https://blog.jxck.io/entries/2017-07-19/aborting-fetch.html
あーあー、本来はPromiseにキャンセル機能が搭載されて
シンプルになったはずなのになー。
理想の案ではなくて次点の案ですすんでるとはな > 代わりにCancelToken型の用に仕組みが分離してあるものが提案されている
今更に否定されたCancelTokenとか持ち出されてもw
> 要約すると以下のようなものだった。
>
> CancelToken (.NET の知見) という API 経由で Promise をキャンセルする。
> キャンセルはエラーとは違うため、 resolve/reject 以外に 3 つめの状態を追加する。
> しかし、結論から言うと議論の途中で頓挫してしまった。
>
> なんで頓挫したかの詳細は、仕様策定の中心だった domenic の悲痛な一言に集約されている。
>
> Why was this proposal withdrawn? #70 頓挫は大袈裟。stage0から進ませて貰えなかっただけで、.cancelの様に棄却されたわけじゃない。
今最も、そして唯一のPromiseのキャンセル関連の仕様なのは間違いない。 https://dictionary.goo.ne.jp/jn/162000/meaning/m0u/
とん‐ざ【頓挫】の意味
１ 勢いが急に弱まること。また、計画や事業などが途中で遂行できなくなること。
「活動に一頓挫を来?(きた)?す」「不況で事業が頓挫する」
棄却に相当するものは事業が失敗する、会社が潰れるなどのことだよ。
頓挫というのは勢いが急に弱まる事を言う なんと言うか、頓挫というのはそれこそES6策定の頃からPromiseの在り方やメソッドに付いての議論がたくさんあって、
誰もが何らかの仕組みが早く欲しいと思い続けてきたキャンセル周りにおいて、その場しのぎにしかならない価値の薄い.cancelではなく
ようやく新しい構文だとか何もかも含めて全体的に上手くいきそうな提案が出てきたけどスムーズに進まなかったという、大きな期待と逸る気持ちがあってこそ出た大袈裟な失望の言葉なのに、
ES DiscussやMeetingを追ってすらもない奴らが自分の意見を肯定するためだけに書かれた気持ちや前提を汲まず悪用するのは気分が悪いね >>292
> 大きな期待と逸る気持ちがあってこそ出た大袈裟な失望の言葉なのに、
それはあなたの感想ですよね？
何処かに定義でもあるんですか？ つまり頓挫、勢いが急激に弱まったと言い換えたら、それはずっと展開を追っていて各人の心の中の燃える期待感というか、安心感であって、
ステージが進まないのなんて珍しくないし、実際提案の勢いに変化が生じた訳ではない、ただキャンセル周りの仕様がサクサク決まることは難しそうという不安感は出てきた
とは言っても.cancelがあり得ない以上、似た仕様になる事は確実 >>293
じゃあまずどうして.cancelが失敗したのか、そして今CancelTokenは奴に否定されたのに残ったのかを考えた方が良い
その上で具体的な疑問があれば答えるから まあひとつはっきりしてるのは、今すぐFetch APIを使用するのは
リスクが大きいってことだな。
SuperAgentもしくはaxiosを使うのが現実的 https://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);
https://github.com/tc39/proposal-cancelable-promises/tree/0e769fda8e16bff0feffe964fddc43dcd86668ba CancelTokenはなぜ仕様の内容が
削除されてしまったのか？
削除されたのにリポジトリを残してるのは
単なるあてつけだとかるが
ではなぜ
CancelTokenはなぜ仕様の内容が
削除されてしまったのか？ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) >>296
> そして今CancelTokenは奴に否定されたのに残ったのかを考えた方が良い
残ってないよ。
リポジトリの中身は削除されてる すまん、完全に俺の言い方が悪い
元をたどれば>>284で
CancelToken『型の用に仕組みが分離してあるもの』
と書いたように、俺はCancelTokenそれだけに拘って考えて言っていたのではない
例えば俺がstage0だなんだ言ったのはCancellation APIを意識してたから
そこんところごっちゃにしてたのは本当に謝る
CancelTokenが消えたのは、結局CancelablePromiseが否定されたのを、
じゃあcancel状態の代わりにelse状態を持ってればいいだろというように
結局皮が剥け切れて無かったから、そこを奴に付かれた
だから逆に言うと、「分離」してある形になるのはより確実になってきたと言える
俺が言いたいのはそこ いや、そんな言い訳はいらんわ。
今も生きてる仕様がどこに書いてあるかを言えばいい どうせ罵詈雑言に言われると思ったから暫く見れないでいたんだが、お前ら意外と優しいのな
俺が言ってたのはこれ
https://github.com/tc39/proposal-cancellation HPで友達が稼げるようになった情報とか
⇒ http://asaswq3wq.sblo.jp/article/181819223.html
興味がある人だけ見てください。
KH0BV0X79E ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 誰でもできる在宅ワーク儲かる方法
少しでも多くの方の役に立ちたいです
グーグルで検索するといいかも『金持ちになりたい 鎌野介メソッド』
NHNSG 
