async refactor - refactor internal methods as async

[kumavis]

This is an experiment in taking some of the excellent async refactors in #82 and applying them as non-breaking changes

The goal of this PR is to reduce the amount of unmerged code in the PR that is blocked by dependencies undergoing their own async refactors. Unmerged refactors will inevitably conflict with other ongoing contributions (e.g. #107)

A question - is the introduction of async/await if event used internally a breaking change to minimum platform support (e.g. node@6)? If so would something like @babel/register be considered a sufficient solution?

I tried to match code style and compared the feat/async-await and master branches with great care.

Some notes:

• _sendCorrectionRecord was broken out as per feat/async-await
• _getValueOrPeers return signature unchanged but _getValueOrPeersAsync returns an object as per feat/async-await
• includes some doc improvements from fix: performance improvements #107
• _findNProvidersAsync is not refactored into an async iterator as per feat/async-await but could be
• additional portions of feat/async-await could be included without breaking changes, but I thought this should undergo review before continuing work

[dirkmc]

@kumavis the async refactor will be a breaking change. We need to wait for the dependencies to be ready before we can merge it in. In the mean time there have been some other big changes in the way that the queries work (eg #107), so I think we will need to use that as a starting point rather than my refactors (some of which have already been ported into master).

I'm sorry we can't use this, as I see you've put a lot of effort into it.

[kumavis]

I'm sorry we can't use this

@dirkmc can you clarify your reasoning here

In the mean time there have been some other big changes in the way that the queries work (eg #107), so I think we will need to use that as a starting point rather than my refactors (some of which have already been ported into master).

this is why I created this PR. in order to:

• start using async/await internally asap
• avoid long standing refactors that are blocked by dependencies
• avoid long standing refactors that conflict with refactors

this PR was also made specifically with #107 in mind, with an eye on reducing conflicts

[dirkmc]

@kumavis thanks for putting this PR together. We would prefer to refactor everything at once rather than piece-meal. There will likely be further changes to the DHT code before that big refactor can be made, so we would like to hold off on any more async/await refactoring for the time being. When we are ready to do so we will look at using this PR as part of the big refactor.

[kumavis]

I strongly recommend against needing a big refactor in the first place if it can be avoided

We would prefer to refactor everything at once rather than piece-meal.

can you provide reasoning here. I think this is a bad idea and hinders contribution to this project

[kumavis]

my philosophy:
👍 small incremental non-breaking improvements merged quickly, with small breaking changes of changing public interface
👎 large monolithic refactors requiring lots of coordination

[kumavis]

@dirkmc can i get some more concrete criticism on this approach, thanks

[dirkmc]

@kumavis I'm just a contributor to this repo. There's an endeavour for converting a lot of our repos to async/await: ipfs/js-ipfs#1670. I'm sure they could use your help.

[kumavis]

@dirkmc whoops, didnt realize. thanks

[vasco-santos]

Thanks for this work @kumavis

Once I have some time, I will have a look and sync with you and @dirkmc as he has also been working a lot in this refactor for the DHT

[alanshaw]

Code LGTM. @kumavis am I correct in assuming you're willing to send subsequent PRs to continue the conversion in bytesized (pun intended) chunks? You'll need to use #82 as inspiration (as you have bneen already) and include the additional fixes from there also.

[vasco-santos]

Looked into the changes and everything looks good!

Only needs the pify to be replaced, as stated by Alan!

[kumavis]

@alanshaw @vasco-santos

• replace pify with promisify-es6

This is ready to merge 🚀

Will continue breaking off little pieces of async refactor in separate PRs 😸

[kumavis]

@dirkmc thanks for kicking off this refactor!

[dirkmc]

Thanks for putting in the work to take this on @kumavis 💪👍