Configuration option to turn off automatically sending a response unless the intent returns false about alexa-app HOT 6 CLOSED

Sounds like a messy solution. I think what you really want is #71

from alexa-app.

I mean, we want the same thing. If we have the option to turn it off, this breaks nothing going backward. If we add some sort of done command, in addition to the send command, what have we added?
The send command already works well to send the response whenever you want. Seems to me like the functionality we want is already there.

Also, so you can see what I'm looking for style wise

`export async function someIntent(req: any, res: any) {

    let networkCallPromise = new Promise<any>((resolve, reject)=> {
        request.get("http://google.com", (err, response) => err ? reject(err) : resolve(response));
    });

    let response = await networkCallPromise;
    res.say(response);
    res.send();
}`

As opposed to

`export async function nextTrip(req: any, res: any) {

    request.get("http://google.com", (err, response) => {
        res.say(response);
        res.send();
    });
    return false;
}`

I know the first one is longer because I don't have the promise wrapper abstracted away (A think I'm doing later), but I still think it's much clearer than returning false for seemingly no reason and before the code above it fires.

from alexa-app.

I don't know why my formatting is screwed up with that comment haha. Sorry about that

from alexa-app.

I don't think it's a bad idea to have some global config to turn off the auto-send behavior, and force intents to call send() manually. It might result in cleaner code than forcing intents to return Promises.

Just to clarify again - the reason why I originally defaulted to sync intents with auto-send was to provide an easy on-ramp for skill developers. It gets tricky to debug skills that time out or don't respond correctly, so my goal was to make the framework very simple to adopt and debug by default, then expose the ability to do things like async intents, which are naturally trickier to debug.

I could imagine someone forking to create alexa-app-async, but I really hope we can avoid that by providing a solution that meets the needs of the async crowd. ;)

from alexa-app.

I get why you did that in the first place yea. I'm pretty sure this would be an easy add. As far as I can tell the library as it stands calls the function and simply checks the return value to see if it should send. We can just set a config var to default off and add an && clause to that fn return check statement.

Honestly, that's really the only thing I can see that makes the lib non-async. Def don't see a need to have alexa-app-async, and certainly share the desire to keep the support for the library united

from alexa-app.

I'm going to make a call on the need to have a switch for calling send vs. not calling it based on an option and just close this. I think if someone says say you want to call send at some point, otherwise what's the purpose of the skill anyway? I agree completely with #71 and that it solves this issue in a better way. Please tell me I am wrong and we'll reopen this :)

from alexa-app.