feat: refactor to use async/await #8
Conversation
|
Depends on |
src/index.js
Outdated
| @@ -28,54 +23,26 @@ class DelegatedPeerRouting { | |||
| * @param {PeerID} id | |||
| * @param {object} options | |||
| * @param {number} options.maxTimeout How long the query can take. Defaults to 30 seconds | |||
| * @param {function(Error, PeerInfo)} callback | |||
| * @returns {void} | |||
| * @returns {Promise} | |||
There was a problem hiding this comment.
| * @returns {Promise} | |
| * @returns {Promise<PeerInfo>} |
There was a problem hiding this comment.
Me, personally, I don't like jsdocs and this is a clear example of why.
This module calls this.dht.findPeer which returns a Promise of... a PeerInfo? Now yes, but in the future maybe not and there's nothing to let us know.
That is, we treat them like types and generate documentation from them as if they are accurate but really they are out of date as soon as they've been typed out.
There was a problem hiding this comment.
The advantage of this for me is that I can get introspection when I'm writing code, and I don't have to go look at docs or readme's. Resolves/Rejects don't have good support yet in jsdocs. I'd prefer the approach mentioned at jsdoc/jsdoc#1467. In reality, having a return type of promise is redundant due to the function declaration of async. Knowing what's going to be resolved/rejected is the valuable bit.
There was a problem hiding this comment.
It's nice when this works but it's just too easy for them to get out of date.
In the case above it wouldn't even be the fault of this module - if this.dht.findPeer changed it's return type and we just blindly pass it through there's nothing (like a compiler) to tell us we are breaking our users.
The closest thing we have to automation there is someone opening an issue or sending a PR which is not ideal.
|
Master now has the travis file if you want to rebase. |
|
Have rebased & updated the jsdoc. Also removed the git url for |
|
Also #7 is quite right - this module doesn't actually appear to do anything. |
Not sure I follow. If you aren't running a DHT or another peer router, you have no way of finding specific peers on the network that you're not connected to. This module allows you to leverage another modules DHT to find a given peer. #7 is in regards to the interface for peer routing, which is incorrect atm. Peer routing in libp2p uses |
|
I just meant that all it does is call through to |
|
Ah yeah, it's super trivial, but the nice thing (if you're also running a dht) is you can add it as another peer router to try the delegate node if your dht fails to find a peer. |
BREAKING CHANGE: API refactored to use async/await Also upgrades all the deps, moves from `ipfs-api` to `ipfs-http-client` and removes a lot of results massaging that is now done in the http client.
|
available in v0.3.0 |
Also upgrades all the deps, moves from
ipfs-apitoipfs-http-clientand removes a lot of results massaging that is now done in the http client.