Open ajcrites opened 7 years ago
Is this the same as https://github.com/alexa-js/alexa-app/issues/102?
No, although they are related in that they are both features that the Alexa SDK has that we don't.
Would be really nice to see as this will be a common issue (as stated by Amazon itself). Not all intents make sense every time. For example Yes/NoIntent
should only be accessible in certain states and not everywhere in your app.
I propose two options for this:
app.intent
which is a function (or Promise) and will be called in order to check whether or not this intent may be called. Pro: very dynamic, Cons: maybe too complex for some use-cases, maybe breaking change.Example:
app.intent(
"OrderSomeItemIntent",
{
check: (req) => { return req.getSession().get('hasLoggedIn') === true; }
},
(req, res) => { console.log("Item ordered"); }
);
alexa/alexa-skills-kit-sdk-for-nodejs
compatible structure to maintain states. Pros: easy to adapt when switching libraries, easy to understand, Cons: not really dynamicExample:
const states = {
states.STARTMODE: {
'NewSession': function () {
this.emit('NewSession'); // Uses the handler in newSessionHandlers
}
//...
},
states.GUESSMODE: {
// Intents only available in GUESSMODE
}
}
Any news on this? Especially when developing skills with a larger complexity state handling would be so useful.
This would be a pretty large change, but the current Amazon Alexa SDK has a concept of states for intents. You can set a state in the session handler and the SDK will trigger a particular callback based on the intent and the recorded state.
We can bake this into the intent handler. I suggest adding a method
response.state()
(or a method on Session) that you can use to manipulate the response state -- set, get, or clear it.Then you can update the intent handler to (optionally) include a state and trigger on a state + intent match.