You should probably populate the relevant fields for each API call in order to handle various types of user inputs. The key is used to identify the item that is being said. If a list is shown, you will need to use the key to identify which is clicked. The user may click on the list item to select it. However, they could also say the thing they want. That is where the aliases are useful.
Let's say you were grabbing a list of scholarly articles. While long articles may not lend themselves well to voice, it could be designed like:
function list () {
const app = new DialogflowApp({request, response});
app.askWithList('Alright! Here are some articles about memristors! Which do you want?',
// Build a list
app.buildList('Memristor Research')
// Add the first item to the list
.addItems(app.buildOptionItem('TITLE_OF_FIRST_PAPER',
['title of first paper', 'first'])
.setTitle('Title of First Paper')
.setDescription('S. Smith, Ph. D')
// Add the second item to the list
.addItems(app.buildOptionItem('TITLE_OF_SECOND_PAPER',
['title of second paper', 'second'])
.setTitle('Title of Second Paper')
.setDescription('H. Paul, Ph. D')
)
);
}
In this snippet, if I say I want the first article, it will give me that one without me having to give the full title while still keeping the interaction hands-free. The key will let me identify the article that should be read.
You can use the title of the paper or perhaps the link URL in order to handle it and present a card with more information including the URL.
You do not need to have each URL manually approved. The documentation states:
- Links to sites outside the developer's domain are allowed.
- Link text cannot be misleading. This is checked in the approval process.
As long as you are being straightforward about it, users will be able to directly open the paper in a browser by clicking on the link in the card.
More information is available in the documentation
