[CHAT-1467] Expose webhook_events field

[nmerkulov]

We're extending updateApp API with new property, called "webhook_events". It is used to filter events sent via webhooks/sqs.

• Sending null will reset this filter to default state;
• If no filters were set GetApp response will contain default event types set

[github-actions]

Size Change: 0 B

Total Size: 252 kB

ℹ️ View Unchanged

Filename	Size	Change
dist/browser.es.js	55.1 kB	0 B
dist/browser.full-bundle.min.js	30.1 kB	0 B
dist/browser.js	55.7 kB	0 B
dist/index.es.js	55.1 kB	0 B
dist/index.js	55.8 kB	0 B

_{compressed-size-action}

[vicnicius]

It would also be nice to squash the commits here if possible, even though I see we haven't been super strict with the commit history so far.

[vicnicius]

Are the events the available events the ones listed here: https://getstream.io/chat/docs/other-rest/webhook_events/?language=&q=webhook#webhook-event-types. If yes maybe we could make this type a bit more strict, like:

type WebhookEvents = 'message.new' | 'message.read' | ... | 'user.unflagged';
{
// ...
webhook_events?: Array<WebhookEvents> | null;
// ...
}

And use it on the response as well. Does it make sense?

[mahboubii]

good improvement 👍

[nmerkulov]

Those are events listed there + custom events

We don't have any validation for that column on a backend, it should be "array of strings or null", because we don't have dedicated sorta type for custom events

So i'd say that your suggestion makes perfect sense but not exactly here

[mahboubii]

out of scope of this PR, but the suggestion is still a good improvement, it can be:

webhook_events?: 'message.new' | 'message.read' | ... | 'user.unflagged' | string | null;

[nmerkulov]

it looks good, but that "string" in the end drops benefits of "message.new| message.read" to near zero..
but i'm not ts guy, if you folks want i can include it, no problem =)

[mahboubii]

you're right, this is not helpful for static type checking(could be with the help of Type Guards) but mostly for auto-completion and ref check, pretty common in TS world, however let's keep this change outside of this PR

[nmerkulov]

It would also be nice to squash the commits here if possible, even though I see we haven't been super strict with the commit history so far.

yeah, sure. I'm going to merge it with this

[mahboubii]

It would also be nice to squash the commits here if possible, even though I see we haven't been super strict with the commit history so far.

@vicnicius I've limited the merge options, would be good to set up a workflow for changelog as well

[vicnicius]

It would also be nice to squash the commits here if possible, even though I see we haven't been super strict with the commit history so far.

@vicnicius I've limited the merge options, would be good to set up a workflow for changelog as well

Very true, good reminder. I'll draft something regarding commits and changelog and share it somewhere for us to discuss.