Developing Conversational Components
Get an overview on how to develop your own Conversational Components.
- Components using Components
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.
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:
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:
||Represents the status of the component. Will be set to
||An object containing the data the component was supposed to collect. The content of the object will be different for each component||
||An error object, which is only present if the status is set to
||Yes, if there was an error|
Besides that, it's recommended to include an
In this case of
END you should route back to the
onCompletedIntent just like above, but set the status to
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.
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
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:
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.
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 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.
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.