node-slack-sdk
node-slack-sdk copied to clipboard
types: add event payloads
Edits
What about adding types for event payloads to the types package? This could be used to then help address a variety of issues across different packages (bolt, socket-mode, deno-sdk):
- #1768
- Better typing of interactivity handler payloads in slackapi/deno-slack-sdk
- https://github.com/slackapi/bolt-js/issues/904
- https://github.com/slackapi/bolt-js/issues/796
- https://github.com/slackapi/bolt-js/issues/1572
- https://github.com/slackapi/bolt-js/issues/1661
- https://github.com/slackapi/bolt-js/issues/1835
- https://github.com/slackapi/bolt-js/issues/2122
Original Message
Is really necessary to use the type generator instead of manually improve types? I've found out that the ModalView is missing some parameters, like app_installed_team_id
, id
and state
. About the state
, on the places that have references to it, it is just a string, it could be so much better. Depending on your answer, I can help you with the types that I've created.
Packages:
Select all that apply:
- [ ]
@slack/web-api
- [x]
@slack/types
- [ ]
@slack/rtm-api
- [ ]
@slack/webhooks
- [ ]
@slack/oauth
- [ ]
@slack/socket-mode
- [ ] I don't know
Hi @JMauroNeto, thank for writing in!
Could you elaborate a bit more? I might not fully understand the issue you mention here.
the ModalView is missing some parameters, like app_installed_team_id, id and state
You've selected web-api package in the description but are you talking about https://github.com/slackapi/node-slack-sdk/blob/%40slack/types%402.4.0/packages/types/src/index.ts#L42-L53 ? If so, the types package is not auto-generated.
We are happy to improve it. The bolt-js project has a duplicated but more complete type definition https://github.com/slackapi/bolt-js/blob/main/src/types/view/index.ts Is this something similar to your own type definition?
If you mean the ViewsXXX response types in web-api package, they have the properties that you mentioned correctly (only the too simple State
interface can be improved). Indeed, they are auto-generated but the benefit is not just code-generation. Our other SDK's integration tests have been detecting newly added properties in production API responses and the code generation utilize the outputs by those tests. Thanks to that, we can easily make the updates on the Node SDK in a timely manner.
If we stop doing so, maintaining the types can be harder. Actually, before starting doing this, we didn't have any type definitions for the API responses. We are not planning to change this approach at least in the short term (if future maintainers want to change this, I'm totally fine with it, though).
Thanks again for taking the time to write in here.
Hey @seratch, thanks for your quick response.
Sorry, I've checked the incorrect option, I was actually referring to the file that you mentioned, on @slack/types.
And yes, my type definitions are more similar to the types on the bolt-js project.
So, can we improve the node sdk, since we have this project as a reference?
PS: Btw, I've been using [your types](https://github.com/seratch/seratch-slack-types) for a while, and helped me a lot, thanks again!
So, can we improve the node sdk, since we have this project as a reference?
Yes, we are happy to improve it. If you have time and interest, your pull requests are always welcome! If you are busy, this project's maintainers will improve it sometime soon.
PS: Btw, I've been using your types for a while, and helped me a lot, thanks again!
Wow, I'm so glad to hear that (and a bit sorry about that I haven't been updating the package for a while 🙇 )
@seratch what do you think about trying to integrate https://github.com/seratch/seratch-slack-types into @slack/types
as part of the next major version release I am (slowly) working on? My intention is to have @slack/types
be the source of truth for payloads/events/block kit/any kind of shapes related to Slack's business domain.
@filmaj That sounds great. Perhaps, we may need to manually adjust some parts of it as it's auto-generated, but merging good parts from it should be a good approach. Also, you may be interested in https://github.com/seratch/slack-web-api-client/tree/main/src/block-kit for Block Kit too. The Block Kit typing is more sophisticated than any others.
Ooo nice! Absolutely interested! I have updated the title of this issue and assigned it to the 3.0 milestone for the types
package.
Sorry, I left the project where I used to work with the types mentioned when I opened the issue. By the way, can I help with something?
👋 Hi @JMauroNeto
One thing perhaps that you can assist with: in your original submission you mentioned:
I can help you with the types that I've created.
Do you have any types that you created that you found helpful for your projects? I'm trying to aggregate projects where devs are formalizing the types that are useful to them. I'd like to make improvements to the @slack/types
package - it is very popular and I think there is a lot of room for improvement.