-
Notifications
You must be signed in to change notification settings - Fork 42
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: filter subscription API #1683
Comments
Maybe an event listener usually has the following signature:
but here, we are need to have the decoder instead of a string. To me this feels even less intuitive. |
Maybe it's should be a two step process?
|
@danisharora099 Looking at this in more detail now In your proposed API, are you actually subscribing during the If that is the case, then it sounds good to me, as that would match the approach I took in dispatcher:
That said, dispatcher is higher level abstraction, so I have many more event types, but I could still see js-waku Filter API have events like:
On the other hand, if the flow is
Then it may not really help the devexp |
The flow is simply:
That's it. No
we're not actually passing the decoder, but creating a unique key identifier (which is a string) using the decoder. The way key gen happens is by concatenating the |
With autosharding only the content topic would be needed. Hence, I suggest to only pass the content topic to
Exception should be thrown if there are no active or pending subscription for said content topic to help developer ensure they use the API right. There is one corner case where a developer uses the same content topic on 2 different static shard and wants different event processing. In this case, the API does not allow the developer to register different callback. I think it's a rare scenario and can easily be mitigated by having the developer call |
Independently from this discussion I implemented Takes I have so far (some of which are relevant to existing API too):
Also points from previous posts are valid. And to confirm other opinions in this thread - I don't see anything bad in |
I agree with your point and we can easily remove the overhead of managing pubsub topics for key, especially since each addressed this architecture here: 1e732a9 |
This would be handled with |
yes |
Yes, for the subscribe request but not invocation - wrong wording. I see how we can handle - is to expose type CustomEvent = Event & {
detail: {
payload?: any,
error?: any,
}
};
filter.addEventListener("/content/topic", (event: CustomEvent) => {
...
}); |
Notes from js-waku pm 2023-11-07
|
tracking followup as discussed in PM meeting here: #1713 |
waku-org/docs.waku.org#132 (comment) ping API can also be improved |
Weekly update:
|
Weekly update:
|
Moved to Triage till 11th of Jan. To discuss by team:
What work is ongoing:
cc @waku-org/js-waku-developers |
I would recommend to keep the filter API as close as possible to the protocol. Even if it means the dev ex is not the best, Instead, I would focus on waku-org/pm#114 and from there, provide the best API to the user. This API can then be simple and abstract a lot: API to dev: pass callback and content topic In the background:
|
@danisharora099 removing this |
Problem
The current Filter implementation has a few gaps:
Dev Ex
await filter.subscribe(xyz, callback)
works can be improved as it unintuitive to useawait
in a scenario like suchfilter.subscribe.addEventListener(xyz)
feels more intuitiveReadability and Maintainability
js-waku/packages/core/src/lib/filter/index.ts
Line 417 in 1ec0c20
js-waku/packages/core/src/lib/filter/index.ts
Line 151 in 1ec0c20
Proposed Solutions
API:
which users are more familiar with.
Along with that, improvements like:
Filter
andSubscription
filesdecoders
onFilter.createSubscription()
and calls it internally to avoid an extra stepSubscription
Notes
Filter
to an event-based API #1682The text was updated successfully, but these errors were encountered: