Open chmac opened 1 year ago
export interface NostrEvent {
id: string;
pubkey: string;
created_at: number;
kind: NostrKind;
tags: Array<any>;
content: string;
sig: string;
}
The filter method returns three methods: collect, each, and the default return of async iterable. The collect method returns the result in the form of NostrEvent[], which is the same as each. The default return only returns NostrEvent in async iterable returns. NostrEvent is a type that is compatible with the nostr default event type as you mentioned. I couldn't understand your exact needs here, but we are always open to improvements. If you want, you can create a PR while maintaining backwards compatibility.
Ah, okay, so then I think I found a bug. Maybe it's here:
The return type of collect seems to be Promise<any[]>
Perhaps it's as simple as adding changing line 27952 to be const events: NostrEvent[] = []
?
Ah, wait, now I see that mod.ts
is built, when I look at what is maybe the input:
There the types are set correctly. Could it be that this change is not yet published? I'm looking locally at the files that were downloaded by deno cache
. Or, maybe there's a problem occurring during the deno bundle
step?
Hmm, just checked the published version (0.2.7) which I'm using, and it does have the correct types in the lib/nostr.ts
file:
https://deno.land/x/nostr_deno_client@v0.2.7/lib/nostr.ts?source
So maybe that suggests the types are being lost during the deno bundle
step?
Can't properly display the return of the Collect method during code completion?
I will check the type resolution by importing mod.ts with a clean cache.
@KiPSOFT I'm on my phone now, but I remember it that the types are missing in the bundled file, but present in the source file. So I think something in the build (bundle) process is going wrong. Maybe it's actually a bug on the deno side. I didn't try running the bundle on my machine to see if it creates the same output though.
It looks like the
.filter()
function returns events of typeany
:https://github.com/KiPSOFT/nostr-deno/blob/f56d6c01868c3b041c15a3065e3deb1e496f0013/lib/nostr.ts#L151-L165
Are you open to adding types to the events which are output? There's an
Event
type in the nostr-tools package that could serve as a starting point. Although it hasid
andsig
as optional which is not the case when receiving events from a relay. I tend to wrap it in aRequired<Event>
when I'm typing events from relays.