Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normalize Payload Dispatching - prep for more payload types #15

Merged
merged 8 commits into from
Jun 24, 2022

Conversation

selfcontained
Copy link
Contributor

Summary

This was some work I did to prep for adding support for more payload types that we'll be receiving for interactive events.

I've consolidated how the payloads are dispatched in DispatchPayload() that both the hosted and local-run entry points use now. Each now provides a list of the function files that should be looked for when dispatching, which allows us to diverge in the local run scenario and use the file defined in the function definitions source_file. This let me remove the payload callback_id overriding we were doing as well.

I've also set things up so we can drop in some handlers for the interactivity payloads as well, which will come in a followup PR.

Testing

I've updated the LoadModule() tests to account for the changes I made.

To test manually, you can pull this repo down and update your slack.json file's start hook like so:

"start": "deno run -q --config=deno.jsonc --allow-read --allow-net file:///Users/<your-user>/<path-to>/deno-slack-runtime/src/local-run.ts"

Then run deno run to run locally and it will use the local runtime.

Requirements (place an x in each [ ])

// deno-lint-ignore no-explicit-any
let resp: any = {};

switch (validEventType) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is where we'll add a few more case statements for new interactivity event types.

body: Body;
context: {
bot_access_token: string;
variables: EnvironmentVariables;
};
};

export type ValidInvocationPayloadBody = FunctionInvocationBody;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will get extended to support new interactivity event payloads as well, so just setting it up.

@selfcontained selfcontained force-pushed the bradh-normalize-payload-dispatch branch from 30b24d2 to 737d94e Compare June 23, 2022 19:29
@@ -0,0 +1,62 @@
import { LoadFunctionModule } from "./load-function-module.ts";
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bulk of the logic in this file come from consolidating mod.ts and local-run.ts

@selfcontained selfcontained requested a review from shapirone June 23, 2022 19:32
Copy link
Collaborator

@shapirone shapirone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Verified local run still works and added comments but none are blocking 🎉

// The CLI expects a JSON payload to be output to stdout
// This is formalized in the `run` hook of the CLI/SDK Tech Spec:
// https://corp.quip.com/0gDvAsqoaaYE/Proposal-CLI-SDK-Interface#temp:C:fOC1991c5aec8994d0db01d26260
console.log("{}");
console.log(JSON.stringify(resp || {}));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❔Do we get anything from logging the response here for the CLI?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yah, the CLI uses this output as the response to the HTTP request that delivered the event/payload. It will let some interactivity handlers, like view_submission, to do things like return validation error responses.

},
Error,
const jsModule = await LoadFunctionModule(
[`${functionsDir}/nonexistnent.ts`],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: It literally doesn't matter at all, but this nonexistent filename has a typo 😂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤣 feels slightly appropriate then

},
);

await t.step("should load the correct file when given multiple", async () => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💭 Wondering if we should have two tests here:

  1. Validates that a ts file will be used instead of a js file when they both exist.
  2. Validates that it'll use the existing js file over a ts file that doesn't exist.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call, I'll add this as an issue and flag it good first issue (and also turn on issues for this repo)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#16

Comment on lines +84 to +87

export const EventTypes = {
FUNCTION_EXECUTED: "function_executed",
} as const;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I feel like our types.ts files normally only contain TS types, but EventTypes is also an actual value. I feel like there is not really a perfect spot for it that already exists, but I was thinking we could:

  • Put this in a separate file named something like event-types.ts
  • Place it at the top of dispatch-payload.ts until we need it somewhere else
  • Leave it here 🤷

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll move it to it's own file, but if it's ok I'll do it in the PR that adds the new types, it'll be a bit easier there w/ the changes I have around that area. By easier, I mean I won't have to deal with merge conflicts cause I'm lazeeee

@selfcontained selfcontained merged commit ba6eea9 into main Jun 24, 2022
@selfcontained selfcontained deleted the bradh-normalize-payload-dispatch branch June 24, 2022 22:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants