-
Notifications
You must be signed in to change notification settings - Fork 511
feat: address and proto books #590
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
a1617e6
8dab477
72dea96
d3e4ad2
eb27b8d
f938535
1662065
7dcc78e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
Co-Authored-By: Jacob Heun <[email protected]>
- Loading branch information
There are no files selected for viewing
Large diffs are not rendered by default.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,8 +12,8 @@ const { | |
| * The Book is the skeleton for the PeerStore books. | ||
| */ | ||
| class Book { | ||
| constructor (eventEmitter, eventName, eventProperty) { | ||
| this.eventEmitter = eventEmitter | ||
| constructor (peerStore, eventName, eventProperty) { | ||
| this._ps = peerStore | ||
| this.eventName = eventName | ||
| this.eventProperty = eventProperty | ||
|
|
||
|
|
@@ -28,10 +28,17 @@ class Book { | |
| * Set known data of a provided peer. | ||
| * @param {PeerId} peerId | ||
| * @param {Array<Data>|Data} data | ||
| * @param {Object} [options] | ||
| * @param {boolean} [options.replace = true] wether data received replace stored the one or a unique union is performed. | ||
| */ | ||
| set (peerId, data, options) { | ||
| set (peerId, data) { | ||
| throw errcode(new Error('set must be implemented by the subclass'), 'ERR_NOT_IMPLEMENTED') | ||
| } | ||
|
|
||
| /** | ||
| * Add known data of a provided peer. | ||
| * @param {PeerId} peerId | ||
| * @param {Array<Data>|Data} data | ||
| */ | ||
| add (peerId, data) { | ||
| throw errcode(new Error('set must be implemented by the subclass'), 'ERR_NOT_IMPLEMENTED') | ||
| } | ||
|
|
||
|
|
@@ -45,7 +52,7 @@ class Book { | |
| throw errcode(new Error('peerId must be an instance of peer-id'), ERR_INVALID_PARAMETERS) | ||
| } | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we can skip the type checks of
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I personally don't like to see
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can table this discussion for outside of this PR as we're already doing similar checks elsewhere. In short, I'd rather see us move to support static type checking for users that want it instead of doing runtime checks. While they're not big, doing these type checks everywhere slowly adds to bundle size as well.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we open a general issue to discuss this? |
||
|
|
||
| const rec = this.data.get(peerId.toString()) | ||
| const rec = this.data.get(peerId.toB58String()) | ||
|
|
||
| return rec ? [...rec] : undefined | ||
| } | ||
|
|
@@ -60,14 +67,14 @@ class Book { | |
| throw errcode(new Error('peerId must be an instance of peer-id'), ERR_INVALID_PARAMETERS) | ||
| } | ||
|
|
||
| if (!this.data.delete(peerId.toString())) { | ||
| if (!this.data.delete(peerId.toB58String())) { | ||
| return false | ||
| } | ||
|
|
||
| // TODO: Remove peerInfo and its usage on peer-info deprecate | ||
| const peerInfo = new PeerInfo(peerId) | ||
|
|
||
| this.eventEmitter.emit(this.eventName, { | ||
| this._ps.emit(this.eventName, { | ||
| peerId, | ||
| peerInfo, | ||
| [this.eventProperty]: [] | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can do it in a followup PR but I think we should simplify the data gathering and consumption sections. Reading through this it was hard to figure out where data comes from and who/what/why it's being consumed. I think it would be good to be very direct about what should actually be putting data into the peer store so it's clear, and how someone can get data out of the peer store.
IE:
Submitting records to the PeerStore
Identify
...
Retrieving records from the PeerStore
Protocols
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I totally agree to use that text format. I will PR with that on a followup