Adding support for events

[dios-david]

I'm using groq-store in a Node server and I'm wondering whether I can get some additional useful information out of that.
What I'm thinking is really basic, like "dataset was loaded with X documents", and a similar update whenever changes are received through the listener API.

My first idea was to support some eventing, like store.on('datasetChanged', () => {...}), so I gave it a go and tried to implement it.

Let me know what you think :)

[stipsan]

Love the initiative! 💖

cc @judofyr and @rexxars to get their insight on this.

I'm wondering if we could solve this use case by adding an adapter API for how datasets load. It would give us more options when setting up experiences like preview-kit when there's a very large amount of documents in your dataset, and includeTypes is insufficient to stay below the documentLimit.
Another interesting use case is hosting your own EventSource instance. Doing so allows custom authentication schemes and self-hosting frees you from our Listeners limits.

[stipsan]

I think this emitter should be throttled, the same way executeAllSubscriptions is.
To avoid a mismatch where you will see datasetChanged events fire, but store.query and such not yet "see" the changes yet since these are throttled.

[judofyr]

What's the purpose of this field? It seems a bit artificial to have dataset (and not projectId) here. And whenever you set up the listener you probably already know which dataset/projectId it's applied to?

[judofyr]

Interesting! Some quick thoughts:

• Would this use case maybe be better handled with support for logging? Does this come from trying to understand what's going on? Maybe we should just support log: true and then we can actually add even more verbose logging in various places?
• It seems like it's not that interesting to have two different events? It could just be a single event and then you know that the second time it's being invoked it's an update?
• Another alternative is to support a function which is called and can be used to even modify the data: transform: (docs: SanityDocument[]): SanityDocument[] and then we always pass it through that one. Then you can accomplish the logging by just returning the same docs input, but you can also do smarter things (like ignoring specific documents). (This is maybe what @stipsan referred to as "adapter API"?)