銀の弾丸

プログラミングに関して、いろいろ書き残していければと思っております。

async / await の基本事項 ― やっぱりPromiseは無視できない

f:id:takamints:20180527125137j:plain
photo credit: simmons.kevin4208 Promise via photopin (license)

JavaScriptのES2017で使えるようになったasync/await。従来Promiseで書いていた非同期処理を、ずいぶん簡潔に書けるようになっていますね。

AWS Lambdaでも、2018年4月から Node.js v8.10(LTS) が使えるようになっており、新規作成したハンドラーは async 関数になっています。

しかし「async/awaitを使えば、Promiseについて知らなくてもよい」とは言えません。 むしろしっかり理解しておく必要がありますよと。

つまり、async / await は Promiseを置き換えるものではなく「Promiseによる非同期処理を同期処理的に記述するための記法」なのです。

ということで、ここには async / await の基本事項と気づいた点やら困った点などを、まとめておきたいと思います(Promiseを理解している人向けの内容です)。

目次:

これからWebをはじめる人のHTML&CSS、JavaScriptのきほんのきほん
たにぐちまこと
マイナビ出版 (2017-03-27)
売り上げランキング: 6,710

async関数とはどういうものか?

async関数は、その記述内容に関わらず、必ずPromiseオブジェクトを返す関数です。 必ずしも非同期動作するわけではないことには軽く注意が必要です。 また、構文的には関数内で後述の await を使えることも示しています。

以降、これらをもう少し細かく書いてます。

見かけによらずPromiseオブジェクトを返します

async関数は、どのように記述されていようと、Promiseオブジェクトを返します。 以下の何もしなさそうに見える関数 foo も、しっかりPromiseを返します。

async function foo() {   }

これをPromiseを明示的に使って書くとこうなります。

function foo() {
    return new Promise(
        (resolve,reject) => {
            resolve();
        }
    );
}

上に示したどちらのfooも、Promiseを返しますので、以下のコードは正しく動作します。

foo().then(()=>{
    console.log("ほらね!");// =>ほらね!
});
async関数 !== 非同期関数

関数定義でasyncを指定しただけで非同期関数にはなりません。 同期的に解決するPromiseはあり得ます。 上の foo も、同期的に解決しています。

Promiseのコンストラクタ内でresolveハンドラが呼ばれており生成されたPromiseを返しているので、明らかに同期的に動作してます。

そのPromiseは見かけ上の戻り値で解決(resolve)される

上のfooが返すPromiseオブジェクトは、undefinedで解決(resolve)されます。 それは見かけ上この関数が何も返していない(≒undefinedを返している)からです。

async function foo() {  return  "ちゃんと動いた!"; }

foo().then( ( result )=>{
    console.log( result ); // => ちゃんと動いた!
});

エラー投入でrejectされる。

Promiseを明示的に生成するときには、エラーの発生はrejectコールバックで伝えましたが、async関数ではErrorをthrowすればよろしい。 そうすると、実質的な戻り値のPromiseオブジェクトはrejectされて、呼び元の catchハンドラが呼ばれます。

async function foo() {
    throw new Error("エラーだよ!");
}
foo().then( () => {} ).catch( err => {
    console.log( err.message ); // => エラーだよ!
});

asyncがコールバック地獄から救ってくれるわけじゃない

妙な言い方になっていますが、つまり、コールバック関数による旧式非同期処理を最新式のPromise化するには直接Promiseを使うしか方法はなく、asyncは直接的に関わらないということです。

例えば、コールバックによる非同期処理の fs.readFile をPromise化するラッパーを作るには、以下のようになります。

function readFile(filename) {
    return new Promise((resolve, reject)=>{
        fs.readFile(filename, (err, data) => {
            if(err) {
                 reject(err);
            } else {
                resolve(data);
            }
        });
    });
}

これを、async関数にもできますが下のようになる程度。 上の実装で既にawaitできますから「確実にPromiseを返すことを宣言する」以外に意味はありません。

async function readFile(filename) {
    return await new Promise((resolve, reject)=>{
        fs.readFile(filename, (err, data) => {
            if(err) {
                 reject(err);
            } else {
                resolve(data);
            }
        });
    });
}

awaitはPromiseの解決を待つ記法

await は、async関数の中だけで使えて、Promiseオブジェクトの解決した値を同期的な記述で得る記法です。 あくまでも記法なので、Promiseと本質的に動作の違いはありません。だからawaitは処理をブロックしたりしません。

だから async関数でなくても await できます。そもそも関数でなくてもかまいません。

async 関数はPromiseを返す関数だからawait可能なだけなんですね。 Promiseを明示的に返す関数でも await できるし、Promiseオブジェクトを直接 await したってかまいません。

これらは結構最初に勘違いしやすいところだと思います。

以下のconsole.log はすべてOK!を表示します。

async function foo() { return "OK!"; }
function bar() {
    return new Promise( resolve => { resolve("OK!"); });
}
async function main() {
    let result = await foo();
    console.log(result);
    let p = foo();
    console.log(await p);
    console.log(await bar());
    console.log(await (new Promise( resolve => {
            resolve("OK!");})));
    // => OK!
    // => OK!
    // => OK!
    // => OK!
}

main();

※ awaitはasync関数でしか使えないので、async mainを定義しています。無名関数の即時実行でも構いません。

上のmainをPromiseで書き直すと以下のようになりますね。 長いだけじゃなくて、処理のまとまりがわかりにくいですね。 thenを分割すれば、さらにコードが長くなります。

function main() {
    foo().then( result => {
        console.log( result );
        let p = foo();
        return p;
    }). then( result => { 
        console.log( result );
        return bar();
    }). then( result => { 
        console.log( result );
        return new Promise( resolve => {
            resolve("OK!");});
    }). then( result => { 
        console.log( result );
    });
}

awaitしているPromiseがrejectされたらエラー投入

async関数と対になっている感じですけど、awaitしているPromiseがrejectされたら、エラーがthrowされます。

エラーを捕捉したければ、普通に try~catch で括ればよろしいです。

await は async関数の中だけで使えますから、try~catchがないなら、前述の通り async関数が暗黙的に返すPromiseオブジェクトはrejectされます。

その他いろいろ

Promise.all をawaitするのが便利ですね

複数のPromise全部が完了するまで待つための Promise.all もawaitできます。 Promise.all の戻り値は、Promise ですから。

このPromiseは、Promise配列の各要素で解決された値の配列になっています。 これらをきちんと理解すれば、かなり楽に書けますね。

function delayedSquare(n) {
    return new Promise(
        (resolve, reject) => {
            setTimeout( ()=> {
                resolve(n * n);
            }, 3000);
        });
}

(async () => {
    let result = await Promise.all(
        [0,1,2,3].map( async n => {
            return await delayedSquare(n);
        }));
    console.log(JSON.stringify(result));
})();

await書き忘れ問題(未解決)

awaitを書き忘れることがたまにありますが、これ厄介です。 eslintなどでもエラーにならないんですよね。 実行時にも単に処理を待っているだけの(値をawaitしていない)場合はエラーになりません。

async function foo() {
    await bar();
    await baz();
}

上のように順次処理を書いてるつもりが、下のようにawaitをすっかり忘れてもエラーにならず、単に2つのPromiseが宙に浮いて非同期実行されるだけになってしまう。

async function foo() {
    bar();
    baz();
}

リファクタリングしている場合に何度かハマりました。処理順がごちゃごちゃになってしまうんですよね。 どうにかならんかなと思っていますが、未解決です。

async 関数内にしか await が書けない理由?

(これは独り言)

awaitが、async宣言された関数内でしか使えないというのは、必ずしも設けなくてもよい制限のように思えますが、非同期処理の間違いを防ぐための仕様なのだろうと思っています。

awaitを使っているということは明示されていないPromiseオブジェクトのthenのハンドラーで処理されています。 async関数以外では、この暗黙のPromiseを返さないように記述できてしまいますが、そうするとawaitの結果が宙に浮いてしまうことになります。 暗黙的なPromiseの結果を待つ await を使用するのは、暗黙的にPromiseを返す関数、つまり async 関数の中だけに限定しているのではないかなと。

まとめ

上に書いた以外にも、「async取り除き忘れ問題」とか、「asyncいちいちつけるのメンドクセー問題」とか言いがかりに近いものも含めるといろいろありますが、「async / awaitで非同期処理を簡潔で分かりやすく書けるようになった」のは事実。 しかしPromiseのことが分かっていないとコードを追いかけられないというのもまた事実なんですね(←これが言いたかった)。

mouseenterとmouseoverの違いなどDOMイベントの発生状況を可視化して調べてみたよ

f:id:takamints:20180507065734p:plain

HTML5のDOMイベントに、mouseentermouseoverという、よく似たマウスイベントがあります。ここには、その違いについて調べたことを書いておきます。

どちらもマウスポインターが要素の上に入ってきた時に発生するイベントで、それぞれに対応する「マウスポインタ―が要素から外れた」時のイベントとして mouseleavemouseout もありますね(mouseenter には mouseleavemouseover には mouseout が対応します)。

この2種類のイベント間には、発生要因や伝播(バブリング/プロパゲーション)に関する違いがあります。

私は最近まで、この違いを意識しておらず「歴史的理由による別名?」かと思っていて、その場で適当に思いついた方を使っていました。 先日ふと疑問に思ってMDNで調べてみたら、どうやら上記のように明確な違いがあると知ったのですが、はっきりイメージがつかみきれなかったので確認用に作ってみたのが以下のものです。

マウスイベントを可視化する

以下、4つのDOM要素が入れ子になっていて、各要素が拾ったマウスイベントを表示します(前述の4つのイベントだけ調べるつもりでしたが、せっかくなので他のイベントもListenしました)。要素の上でマウスを動かせば各インジケータがビカビカします(ちょっとうるさいですが目立つと思って)。

各要素には、preventDefaultstopPropagationというチェックボックスがあります。 それぞれチェックを付けると、その要素のイベント処理で event.preventDefault()event.stopPropagation() を実行します。 例えば、‘#Div4‘の上でマウスを動かすとmousemoveが全要素に発生しますが、stopPropagationにチェックを入れた要素の親へは伝播しません (preventDefaultはこれらのイベントに関して変化がなさそうなのですが、とりあえず残しています)。

マウスポインタが要素の「外側から内側」へ移動するとき

全てのstopPropagationのチェックを外した状態で、#Div1の左右または下の外側から*1#Div4の内側までマウスポインタ―を動かしていったとき、以下のことが観察されます(実際にやってみてください)。

*1 - マウスポインターが各要素の上側を通過すると情報を表示している要素の境目でイベントが発生してしまうので避けるべき。

マウスポインタが要素の「内側から外側」へ移動するとき

次に、#Div4 の内側から、左右または下に向かって、#Div1 の外側までマウスポインタ―を動かすと、以下のことが観察できます(全てのstopPropagationのチェックは外したままです)。

各イベントの伝播を確認

上と同じく、全てのstopPropagationのチェックを外したままで、各イベントが発生した場合、

  • mouseovermouseout は親要素へ伝播しますが、
  • mouseentermouseleave は伝播しません。

そして、伝播を抑制するには、イベントハンドラーの中で event.stopPropagation() を呼び出します。

MDNに書いてあること

MDNのmouseenterには、以下のように書かれています。

With deep hierarchies, the amount of mouseenter events sent can be quite huge and cause significant performance problems. In such cases, it is better to listen for mouseover events.

翻訳すると「深い階層では、送信される mouseenter イベントが大量になる可能性があり、重大なパフォーマンスの問題の原因になり得る。その場合は mouseoverイベントを使うといい」とのことですが、これって上で見たことと少し雰囲気が違ってないか?と。 mouseover が全ての親に伝播していて、たくさん発生しているように見えましたけど?

「逆じゃないの?」って、かなりMDNを疑ってみたのですが、しかし、これはこれでどうやら間違いではないみたい。 すべての要素でイベントをListenしているので、大量の mouseover が発生していましたが、通常そんなことはしませんね。 イベントはaddEventListenerしている要素に発生して後は親要素に向かって伝播するだけ。 イベントを処理すべき要素だけにハンドラを設定しておけばなんら問題がないはず。

一方「mouseenterが大量に発生して」という部分はよくわかりません。 そのようなケースが今のところ想定できないのですが。 mouseenterは、そもそも親要素に伝播しないし、論理的な自要素の領域内にあればmouseleaveは発生しないので、必要なところでListenしておけば問題ないような気がするし、そもそも用途が違うんじゃないのか?と。

ちょっとモヤモヤしてますが、とりあえず・・・。

リンク

Heroku CLI 7.0.2? のエラーを修正

f:id:takamints:20180422144244p:plain

Git for Windowsから最新版の Heroku CLI を起動するとエラーが発生。バージョンは下に書いてますけど、そもそもエラーが出るので確認できない。Power Shellからなら大丈夫。32ビット版でも64ビット版でも同様ですね。未確認ですが、MSYS とか Cygwinでも同じ現象が起きるんじゃないかなと思います。

とりあえずはインストールされたシェルスクリプトに1文字追加すれば治ります。

直接的な原因が分かったところでGitHubにはIssueを上げてひと安心。「さてIssueも上げたしForkしてCommitしてプルリクしてどや顔するかな相手は天下のセールスフォースドットコム・・・」と、ヤケに日曜朝から心拍数を上げたのですが(おちつけ自分)、結局どこを直せばよいのかわからなくてWatchだけして、そっとGitHubを閉じました。 が、なんと4時間後にはこの問題が改修されててIssueもClose。素早い対応ありがとうございますー。

クラウド開発徹底攻略 (WEB+DB PRESS plus)
菅原 元気 磯辺 和彦 山口 与力 澤登 亨彦 内田 誠悟 小林 明大 石村 真吾 相澤 歩 柴田 博志 伊藤 直也 登尾 徳誠
技術評論社
売り上げランキング: 88,620

インストール直後にエラー

Windows用Heroku CLIの最新版をインストールしてGit Bashから実行すると以下のエラーが発生しました。

$ heroku
sed: -e expression #1, char 7: unterminated `s' command
/c/Program Files/heroku/bin/heroku: line 4: ./../client/bin/heroku.cmd: No such file or directory

sedのsコマンドが終わってない」と言っている。

原因究明

コマンドはC:\Program Files\heroku\bin\herokuという名のシェルスクリプトなので中身を見てみると。

#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\,/,g')")

"$basedir/../client/bin/heroku.cmd" "$@"
ret=$?
exit $ret

2行目で、sedでバックスラッシュ(円記号)をスラッシュに変換しようとしているが、バックスラッシュがエスケープされていませんね。

応急対策

これエスケープするだけで動くんじゃないかね?と

f:id:takamints:20180422095556p:plain

Git Bashを管理者権限で開いてvimで編集したところ、ホントにこれだけで正しく動くようになりました。 (Program Files 以下を変更するには管理者権限が必要)

バージョンは 7.0.2、、、ん?

バージョンは以下のように7.0.2だったのですが、これってホントにリリースバージョンなんですかね。 GitHubリポジトリでは現時点でv6.16.16です。Windows用は別管理ってことはないと思うんだけど。

これ、ダウンロードページから公開しちゃいけないものを公開しちゃっているとかではないのかな。 よくわからなくなってきました。

$ heroku --version
heroku-cli/7.0.2 win32-x64 node-v9.11.1

とりあえずIssueはポスト

しかしまあ、しばしGoogle翻訳と格闘してから、とりあえずIssueをポストしておいた。

で、現在のリポジトリ内の /resources/exe/heroku が問題のスクリプトなんだけど、不思議なことに半年前に追加されたときから、きちんとエスケープされている。 ということで、どこを直せばよいのかわかりません。インストーラを作るところか動作上の問題なのか。

まあ偉い人が直してくれるんだろう。なにしろ天下のセールスフォースドットコムだし。

追記)この記事書いた時点で既にIssueがクローズされていました。早っ! 修正箇所はやっぱりresources/exe/herokuで。バックスラッシュが4つになっていましたわ。 二重にエスケープしなきゃなんなかったのかー。

関連リンク

devcenter.heroku.com

github.com

github.com