chore: apply suggestions from code review

Co-Authored-By: Jacob Heun <[email protected]>
libp2p · Apr 9, 2020 · db2e890 · db2e890
1 parent 1662065
commit db2e890
Show file tree

Hide file tree

Showing 2 changed files with 4 additions and 4 deletions.
diff --git a/doc/API.md b/doc/API.md
@@ -519,7 +519,7 @@ const key = '/key'
 const { from, val } = await libp2p.contentRouting.get(key)
 ```
 
-### peerStore.addressBook.Add
+### peerStore.addressBook.add
 
 Adds known `multiaddrs` of a given peer. If the peer is not known, it will be set with the provided multiaddrs.
 
@@ -574,7 +574,7 @@ peerStore.addressBook.delete(peerId)
 
 ### peerStore.addressBook.get
 
-Get the known [`MultiaddrInfos`](multiaddr-info) of a provided peer.
+Get the known [`MultiaddrInfos`][multiaddr-info] of a provided peer.
 
 `peerStore.addressBook.get(peerId)`
 
@@ -588,7 +588,7 @@ Get the known [`MultiaddrInfos`](multiaddr-info) of a provided peer.
 
 | Type | Description |
 |------|-------------|
-| `Array<MultiaddrInfo>` | Array of peer's multiaddr with their relevant information [`MultiaddrInfo`](multiaddr-info) |
+| `Array<MultiaddrInfo>` | Array of peer's multiaddr with their relevant information [`MultiaddrInfo`][multiaddr-info] |
 
 #### Example
 

diff --git a/src/peer-store/README.md b/src/peer-store/README.md
@@ -26,7 +26,7 @@ It is also possible to gather relevant information for peers from other protocol
 
 When the PeerStore data is updated, this information might be important for different parties.
 
-Every time a peer needs to dial another peer, it is essential that it knows the multiaddrs used by the peer, in order to perform a successful dial to it. The same is true for pinging a peer. While the `AddressBook` is going to keep its data updated, it will also emit `change:multiaddrs` events so that subsystems/users interested in knowing these changes can be notifyied instead of pooling the `AddressBook`.
+Every time a peer needs to dial another peer, it is essential that it knows the multiaddrs used by the peer, in order to perform a successful dial to it. The same is true for pinging a peer. While the `AddressBook` is going to keep its data updated, it will also emit `change:multiaddrs` events so that subsystems/users interested in knowing these changes can be notified instead of polling the `AddressBook`.
 
 Everytime a peer starts/stops supporting a protocol, libp2p subsystems or users might need to act accordingly. `js-libp2p` registrar orchestrates known peers, established connections and protocol topologies. This way, once a protocol is supported for a peer, the topology of that protocol should be informed that a new peer may be used and the subsystem can decide if it should open a new stream with that peer or not. For these situations, the `ProtoBook` will emit `change:protocols` events whenever supported protocols of a peer change.