The EventParser utility in the Alexa Skills Kit Node.js SDK
In the last post in the Dig Deep series, we looked at the recently-added utilities in the Alexa Skills Kit Node.js SDK that built text and image objects to send to the Alexa platform. In this post, we look at a a class that was released with the new skill events:
As a reminder, this is the Dig Deep series, where we look line-by-line at the tools and libraries we use to build voice-first experiences. This is not the place to go for tutorials, but if you want to learn interesting little nuggets about what you use every day, off we go…
What are skill events?
Skill events are triggered when events relating to your skill, rather than in your skill, are triggered. There are five events:
- Account linked
- Skill enabled
- Skill disabled
- Permission (e.g. location) accepted
- Permission (e.g. location) changed
These events must be subscribed to in the skill manifest. Wait wait… skill manifest? Where in the developer console does the skill manifest go? It doesn’t. Skill events can only be used in skills that are configured using the ASK CLI. This post won’t go into the skill manifest (that will be for a future post), but know that you subscribe through
events.subscriptions and an array of strings corresponding to events to which you wish to subscribe.
You can’t have Alexa speak to the user when these events are triggered. What, then, is the use? For one use case, imagine a skill that is coupled to an existing web site. The user’s dashboard inside the website can show whether the skill is connected. This is easy enough on the initial account linking, but it has until now been difficult to know if that skill is later disabled. Subscribing to the skill disabled event can update that status in the database of the website.
You can read more about skill events for Alexa skills in a previous blog post.
This new utility has been created to handle all incoming events and parse out which event to emit. In the past, this was done inside the main
alexa.js file. Not much has changed other than the functionality has been isolated. It’s still being used in the
If the incoming session is new and there’s a
NewSession handler for the current state, that’s our
eventString. Otherwise, it’s up to
EventParser.parseEventName to provide the string. It does so according to simple rules:
- If the request type is an intent, the string is the intent name
- Otherwise, for anything related to the display (Echo Show), audio playback, or the playback controller video, the request is namespaced, so the returned string lops out the parent namespace
- Otherwise, it’s just directly what was passed—this is how all newly developed requests are supposed to be handled; possibly to make it easier for SDK developers
EventParser doesn’t add any new functionality, just ties it up in a new package. It is a key piece for events like the skill events, or, one would imagine, the newly announced Echo Buttons.