Cannot access the user id in the "message_changed" event with TypeScript

[okovpashko]

Reproducible in:

The Slack SDK version

3.13.1

Node.js runtime version

v16.15.1

OS info

ProductName: macOS
ProductVersion: 12.6.5
BuildVersion: 21G531
Darwin Kernel Version 21.6.0: Thu Mar 9 20:08:59 PST 2023; root:xnu-8020.240.18.700.8~1/RELEASE_X86_64

Steps to reproduce:

The Slack docs say that there should be the message.user key in the message_changed event containing the Slack user id.

The TypeScript interface for the MessageChangedEvent refers to the MessageEvent interface in the message and the previous_message properties that make TypeScript assume that accessing event.message.user is not allowed because not every subtype of the message event contains a user id.

It seems like the reference to the MessageEvent is incorrect because (I suppose) not every message can be edited and moreover it makes the circular dependency in types when the message_changed event can reference to the message_changed event and so on.

Expected result:

• the message property of the message_changed event has the valid type according to the Slack docs
• no TypeScript errors when accessing event.message.user for the message_changed event.

Actual result:

TS2339: Property 'user' does not exist on type 'MessageEvent'.

[seratch]

Hi @okovpashko, thanks for taking the time to report this issue with details!

I agree that the message/ previous_message in message_changed subtype message event type definition should be corrected as you pointed out. We will resolve it in the next patch version. If you're happy to make a pull request for it, I'd love to have your contribution 🙌

[okovpashko]

Hi @seratch
Thank you for the rapid response!

I will be happy to submit a PR with the fix. The only thing I need to understand beforehand is if there's already an existing type for the object I need or I should introduce a new interface for that. Could you give me a hint please?

[seratch]

The MessageEvent is a union type that consists of all the possible message event types, so we can define a new union type with less subtype patterns. I think removing at least message_changed, message_deleted should be safe enough. But, for the rest, I cannot confidently say anything without thorough tests with real payloads.

[filmaj]

Transferred this from the bolt-js repo, as now event payloads live in this package.

I think this issue is similar to #2025.

Definitely one way to fix this would be to narrow the type of the message on the MessageChangedEvent to reflect the more specific kinds of messages. That could be an initial improvement that could be a minor version upgrade.

However, I think another, perhaps more complete solution would be to use generics (type parameters) to be able to explicitly say what the base message is, e.g. MessageChangedEvent<Message extends EditableMessage = EditableMessage>. This way, developers defining handlers using bolt-js could then specifically type the event payload incoming, if applicable. Bolt could use some generally-applicable union of message types as the default (EditableMessage in the example above - which could leverage the minor-version improvement discussed in the previous paragraph), but we give developers the options to qualify it as they wish.