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

Consider refactoring payloads #65

Open
amoeba opened this issue Feb 8, 2020 · 0 comments
Open

Consider refactoring payloads #65

amoeba opened this issue Feb 8, 2020 · 0 comments

Comments

@amoeba
Copy link
Owner

amoeba commented Feb 8, 2020

From a message I sent Trevis:

And if you set your webhook, say Discord, with a payload of { "content": "@", "username": "$1" }, chat triggers like (.+) says, "(.+)" with a message of $2 will trigger webhooks that look like they're from the character that sent them.

After doing all this refactoring, I started thinking maybe I should remove the Payload aspect of each webhook and make the payload independent of the webhook and let each trigger set it. If you noticed above, to get a Discord webhook to set the username property on the payload, the regex capture group has to be number 1 ($1) which works in the example I gave you but it's not flexible. A more flexible solution is to make the Message field on the triggers the full JSON payload instead of the Payload field on the webhook. This is a breaking change and folks would have to change things and would lose settings. Do you think it's worth it?

Basically, backreference support makes for some nice additional features but isn't as flexible if the Payload is tied to the webhook. It's more flexible if the payload is tied to the trigger.

For now I'm going to keep things how they are but I wanna leave this open for posterity.

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

No branches or pull requests

1 participant