-
Notifications
You must be signed in to change notification settings - Fork 446
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
feat: invoke onProgress callback with events during routing #1975
base: main
Are you sure you want to change the base?
feat: invoke onProgress callback with events during routing #1975
Conversation
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.
Looks good, some conflicts need to be resolved, but it is also strange to me that the interfaces are so verbose.
@@ -235,7 +244,15 @@ export interface Libp2pEvents<T extends ServiceMap = ServiceMap> { | |||
* }) | |||
* ``` | |||
*/ | |||
'start': CustomEvent<Libp2p<T>> | |||
'start': CustomEvent<Libp2p< |
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.
This is pretty verbose, should we have this as a seperate interface?
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'm not a massive fan of how this is implemented so I'm certainly open to suggestions of how to make it simpler.
The idea is to derive the types of content/peer routing progress events you'll get from the config so they can be type safe. I not sure it's reliably possible, and it leads to these sorts of generics contortions - we may be better off just making it untyped.
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.
Yes I agree there, I don't see any type safety benefits as is, I think we are better off with
export interface Libp2pEvents<
Services extends ServiceMap = ServiceMap,
ProgressEvents extends ProgressEvent = ProgressEvent
> {
'start': CustomEvent<Libp2p<Services, ProgressEvents>>;
'stop': CustomEvent<Libp2p<Services, ProgressEvents>>;
}
given the DHTContentRouting
class already specifies the ProgessEvent types in it's methods.
Allow passing an `onProgress` callback to the peer/content routers that can receive DHT query events. Refs #1574
616b0a8
to
61aa0ce
Compare
bd30ffd
to
d153d4c
Compare
242fd96
to
bca8d6e
Compare
6453a80
to
c2bc7fe
Compare
Allow passing an
onProgress
callback to the peer/content routers that can receive routing events.Refs #1574