Developing Conversational Components

Get an overview on how to develop your own Conversational Components.

• Handler
• Configuration
• Models
• i18n
• Components using Components
  • Installation
  • Configuration of Nested Components
  • General Usage

You're component has to have the whole package of language model, handler, configuration and i18n for people to be able to use it. We will skip, the general description of each of these blocks and go into more detail about the small stuff that's important to develop components. You can revisit the basics here.

You can find an example of a basic Conversational Component here.

Handler

The component's handler has to have a START intent at its root, which the system will route to on delegation. That intent can be used to initialize any kind of data you will need throughout the component as well as begin the conversation with the user:

In the START intent you should check if the user has parsed existing data to your component. In the following example, the component checks whether the user has parsed an existing phone number:

At the time the component finished, or if there was an error, or the user tried to stop the app, you have to send the component's response using sendComponentResponse(response) function. The response object has to have the following interface:

Besides that, it's recommended to include an ON_ERROR, END and Unhandled intent.

In this case of ON_ERROR and END you should route back to the onCompletedIntent just like above, but set the status to ERROR or REJECTED respectively:

Configuration

Specify the component's default configuration in its config.js file. There's no blueprint, which means you can set the config options as you wish, but you should always include an intentMap for your handler.

Models

The language model you provide has to have every intent needed to get the component working. It shouldn't expect the user to have any kind of intent (e.g. AMAZON.StopIntent) or input type predefined. Its structure is the same as the language model you use in your default Jovo project, besides the invocation name

i18n

To allow the user to customize the component's responses easily, it is recommended to use the i18n integration instead of hard coding responses. For that it is also recommended to use a naming convention with a low chance of running into conflicts with the user's existing i18n keys. Here's an example where everything was stored inside an object with a distinct key:

Components using Components

Naturally, components can use components as well. But, the process is slightly different from the usage with a normal Jovo project. In the next bit, we will run through the process of integrating a component within a component.

Installation

Again, the component has to be installed using npm and saved as a dependency:

After that, you add the component to your own component by calling the useComponents(...components) function inside your component's constructor:

With all these set, the Jovo CLI and framework will load your component's component's files on load and add it to the project's active components.

Configuration of Nested Components

Configuration of n-th layer components work in a strict hierarchy. Let's say we have two components: component A and component B, where component A uses B.

At the very bottom of our configuration is component B's own default configuration. After that, we merge the configuration that the developer of component A made into the default config of component B.

Component A adds its configuration using its own config file using the name of component B:

Now, the only one left is the end user, who can also make changes. Their configuration will merged as the very last, which means it can overwrite anything.

The deeper the nesting of components using components, the deeper the configuration will be as well.

General Usage

There's no difference here. Inside your component's handler you can simply delegate to the component, the same way you would do it in a normal Jovo project.