Consider making all plugin APIs async or optionally async via Promises

[atrauzzi]

This one goes along with #1701.

Looks like the node APIs are async, but what about the browser ones? Booting up some of my libraries requires that I be able to do so asynchronously. Right now unfortunately, gatsby runs ahead to replaceRouterComponent before I'm ready to resolve my redux store (or anything for that matter) from my DI container.

Making all these calls optionally async would offer a lot of flexibility for plugin developers.

[KyleAMathews]

Makes sense to me 👍

Perhaps just support sync + async if a 3rd callback argument is passed in?

Want to put up a PR?

[atrauzzi]

I'm definitely interested in helping out. I might need a few tips on where you think the touchpoints are, but I've already got a copy of the Gatsby repo checked out.

Can do here, or ping me on discord if you want.

[atrauzzi]

Right now I'm looking at gatsby/src/cache-dir/app.js and gatsby/src/cache-dir/api-runner-browser.js. These the right places?

My thinking is that app.js needs to detect if any items in the array returned by apiRunner are promises and then wait on them. Which means app.js is going to also become a promise chain ending in ReactDOM.render.

[jquense]

Can we go full promises for the API? It makes stuff a bit simpler and most folks are gonna have a promise polyfill if needed in the browser. Saves potentially having to load the async package in the bundle as well

[atrauzzi]

Definitely prefer pure promise APIs if possible.

[atrauzzi]

@KyleAMathews - #1735

This is a start and of course by no means the final cut. I took a stab at cleaning the file up as well. Would an approach like this work?

[atrauzzi]

Done!