Version 0.19.0 is a big release with some changes and refactoring in preparation of the release of [[Mission Control|Mission-Control-Introduction]]. There are no breaking changes but some conventions are changed and this may some flow to work improperly.

The preferred way to pass parameters from an upstream node is using the msg object and not msg.payload. The reason is that conventionally msg.payload is used to carry around the result of the previous node and it happens frequently that a node needs some configuration parameters and the result of previous node (for example the MC Content node, etc), for this reason in order to avoid naming clash it’s better to use msg to pass parameters. The old way is still supported but discouraged.

Some chat contexts keys are now read only: chatId, userId, transport The reason for that is RedBot is meant to be multi-channel, means that the conversation with the same user can be carried on with multiple platforms (i.e. Telegram, Facebook Messenger, etc), for this reason some platform related information like chatId, platform are no longer stored in the chat context (which is a memory space related to a user across different platforms). Back compatibility is granted, so templates using {{chatId}} or {{platform}} tokens or script using msg.chat().get('chatId') still work properly, but trying to write modify these values results in a no-op. It should not be a big problem, trying to mess around with the internal values of RedBot is an anti-pattern.

Improved NLP nodes NLP.js is the favourite way to parse user’s sentences and all *NLP.js ** nodes were improved with a debug flag (to better understand what is going on while the node process the user sentences) and a threshold parameter (this is useful to tune the sensibility of a model)

Chaining messages Previously in order to chain one or more messages was necessary a Sender node with the pass-thru option enabled. This pattern was leading to an unnecessary proliferation of multiple sender nodes. Now it’s easier, just chain the nodes and the messages will be queued and sent in the right order, for example to send a text followed by an image

https://github.com/guidone/node-red-contrib-chatbot/raw/master/docs/images/example-clear-payload.png

Chaining messages

(Previously the image node would overwrite the text message). Some particular flows may be affected by this behaviour, in particular those that have a fork in the flow before a Sender node, in this case the Node-RED message has all the chained messages in the payload, in some other messages are present in the branch ::B:: of the flow, may cause some messages to be sent twice. To fix this side effect just clear the payload in a Function node

msg.payload = null;return msg;

Pop message Some nodes like (like [[NLPjs Process|NLPjs-Process]], [[MC GraphQL|MC-GraphQL]]) overwrites the msg.payload of the Node-RED message, losing any reference with the original message from the chatbot user. The [[Pop Message node|Pop-Message-node]] restores the previous value of msg.payload value in case one of these nodes overwrites it (see the [[node documentation|Pop-Message-node]] for an example).

Chat contexts All nodes support the handlebars-like syntax to use chat context variables in messages or (RedBot) nodes configuration. Now it also supports Node-RED global variables (i.e. {{global.my_global_var}}), values in the payload with dot-notation (i.e. {{payload.shipping.address}},, check the [[node documentation|Chat-Context]] for all details.

SQLite support Red-Bot now supports SQLite as context provider and it’s the preferred way to store the chat context in production environment (more scalable and reliable than Plain File). It uses Sequelize as ORM so it would be easy to port this context provider to work with other databases (like MySql, PostgreSQL, etc.). When Mission Control will be available, chat contexts will be part of the GraphQL schema (it will be possible to query and mutate the context directly with GraphQL).