Fetch の中断と Promise のキャンセル方法の標準化 | blog.jxck.io
Intro XHR から fetch() に積極的に移行しづらかった最大のミッシングピースとして、中断できないという問題があった。 これは、 fetch() が選んだ Promise ベースのインタフェースにおいて、キャンセルをどうするかという議論と絡み、長く決着が付かずにいた問題である。 最近、やっと話が前進したので、ここまでの経過を解説する。 Fetch のミッシングピース fetch() は、ブラウザが発行するリクエストと、取得するレスポンスを扱う低レベルなインタフェースとして策定が始まった。 DOM の API が Promise ベースに移行しつつある流れを汲み、 fetch() もまた Promise を返す関数一発スタイルになった。 クラスからインスタンスを生成しメソッドを呼ぶ XHR スタイルでは、インスタンスを再利用した場合の挙動などを含め、オブジェクトのライフサイクルを
Fetch での Stream を用いたプログレス取得とキャンセル | blog.jxck.io
Intro WHATWG が定義する Fetch API は、出たばかりの仕様では、途中でのキャンセルや、プログレスイベントの取得が含まれていなかった。 しかし、後の更新で fetch 結果の Response Body が WHATWG Stream API を実装することになったため、現在の仕様ではプログレスを取ることもキャンセルをすることも可能となっている。 今回は、こうした API のアップデートについて記す。 Update 最初の公開時には、以下のように書いていた。 「XHR ではできるが Fetch ではできない」ことが、仕様上は無くなったことを意味する。 しかし、現時点で仕様としてまだ出来ないことがあることが判明した。 Upload の Progress これに伴い、記事の一部を修正した。 Fetch 最新の Fetch の仕様は以下で確認できる。 Fetch Spec 仕様
Node.js における Promise を使った例外処理 - from scratch
さて、 Node.js のエラーハンドリングは難しいと言われてますが、 2016年現在、つまりNodeの v4 とか v6 が主流になり、 Promise が基本的な処理として採用されている状況ではどうでしょうか。ちょっと考えてみます。 一応これの補足です。 qiita.com TL;DR 未だに難しい。ただし、 Promise で改善されている。async-await や zone まで来たらかなり楽になる。 あと、 unhandledRejection が uncaughtException よりも酷いことにならないので、大分マシになっている。 Node.js のエラーハンドリングの難しさ まず JavaScript には同期と非同期のエラーハンドリングのやり方があります。前者は所謂 try-catch による方法、後者は callback を使って第一引数で実現する方法や emit(
AsyncとAwait : コールバック地獄を避けるための最新のやり方、そしてその未来 | POSTD
(2016/7/7、いただいたフィードバックを元に記事を修正いたしました。) JavaScript、特にNode.jsといえば、 コールバック地獄 がよく連想されます ^(1) 。たくさんの非同期I/Oを扱うコードを書いたことがある方には、おそらく以下のようなパターンはおなじみでしょう。 export default function getLikes () { getUsers((err, users) => { if (err) return fn(err); filterUsersWithFriends((err, usersWithFriends) => { if (err) return fn(err); getUsersLikes(usersWithFriends, (err, likes) => { if (err) return fn (err); fn(null, lik
Promiseとasync-awaitの例外処理を完全に理解しよう - Qiita
はじめに JavaScriptは非同期処理との闘いです。 人類が非同期処理を倒すために、Promiseやasync-awaitという最終兵器を生み出して、劇的にクリーンで平和な世界が生まれたという話は以前しました => (もしかして： JavaScriptは如何にしてAsync/Awaitを獲得したのか Qiita版) しかあぁし！！！ 甘い、甘いのですよ！！！！！ 人類を苦しめ続ける非同期処理が、そんな簡単に完全に倒せるわけがないのですよ。 非同期処理の本当にヤバイ深淵、それが「例外処理」です。 みなさんはPromiseで開発していて、 「なんか途中までうまく行ってたんだけど気づいたら例外が外側に飛ばなくなった…なんでだ…」 「助けて！Promiseにcatch書いてるのに何故か例外がcatch出来ないの！！！」 という経験はないでしょうか。私は何度もあります。 この記事では、具体的に何
About document.ready
About document.readyThere is some effort going on, documented the WHATWG standard repository, in order to bring a document.ready Promise like behavior to any page. Today, a simple tweet of mine simplified the fuss: document.ready = new Promise(r => /^loaded|complete$/.test(document.readyState) ? r() : document.addEventListener('DOMContentLoaded', r)); — Andrea Giammarchi (@WebReflection
Promise-based functions should not throw exceptions
This blog post gives tips for error handling in asynchronous, Promise-based functions. Operational errors vs. programmer errors # In programs, there are two kinds of errors: Operational errors happen when a correct program encounters an exceptional situation that requires deviating from the “normal” algorithm. For example, a storage device may run out of memory while the program is writing data t
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - babel/kneden: Transpile ES2017 async/await to vanilla ES6 Promise chains: a Babel plugin