docs • developing flows • 消息设计

消息设计

流中传递的消息是普通的 JavaScript 对象，可以在其上设置属性。

它们通常具有 payload 属性 - 这是大多数节点将使用的默认属性。

有关 Node-RED 中消息的更多信息，您应该阅读用户指南的处理消息部分。

本节讨论在决定如何结构化流中的消息时需要做出的一些选择。

在创建流时，消息中使用的属性选择通常会根据流中节点的要求而定。

大多数节点会期望使用 msg.payload，这将指导您做出大部分选择。

例如，考虑一个流，它接收一个 MQTT 消息中的负载 id，然后使用该 id 查询数据库以查找匹配的记录。

MQTT 到数据库查询

数据库节点将其结果放在它发送的消息的负载中 - 覆盖原始 id 值。如果流需要能够稍后引用该 id 值，它可以使用更改节点将该值复制到不会被覆盖的另一个属性中。

使用更改节点将负载复制到 msg.id

这突出了一个重要原则：节点不应修改或删除与其功能无关的消息中的属性。

例如，在大多数情况下，功能节点应发送它接收到的同一消息对象，而不是创建新的消息对象。

msg.topic 显示在调试侧边栏消息中

一些节点还将 msg.topic 视为具有特殊含义。它可以用来识别消息的来源，或者识别同一流上不同的“消息流”。它还会在调试侧边栏中与每条消息一起显示。

例如，MQTT 输入节点将 msg.topic 设置为接收消息的主题。然后，延迟节点可以配置为根据其主题限制消息速率。

虽然您的流可能不会直接使用依赖于 msg.topic 的节点，但它可以用来提供有关消息的额外上下文信息。但如果您稍后在流中引入依赖该值的节点时，您应该小心。

在设计可重用的节点或子流时，它所处理的消息属性和它设置的属性都是其暴露的 API 的一部分。与所有 API 一样，它需要经过仔细和认真地设计。这同样适用于流。

一种方法是将所有内容放在负载下。例如：

{
    "payload": {
        "temperature": 123,
        "humidity": 50,
        "pressure": 900
    }
}

这可能方便将数据放在一起，但也可能导致在后面的节点期望在 msg.payload 而不是其下的属性上操作时需要移动很多属性。

另一种方法，如 Twitter 节点所示，是将最“有趣”的信息放入负载中，在本例中是推文的文本，而将 API 还提供的完整元数据放入单独的 msg.tweet 属性中。

关于如何构建消息没有单一的正确答案，但它应该侧重于节点或流在最常见情况下如何使用。

与编程一样，选择良好的属性名称也很重要。它们应该具有自描述性，以帮助后续调试和理解流。例如，msg.temperature 比 msg.t 更易于理解。

它们还应避免使用某些节点具有特殊含义的常用属性，例如 reset 和 parts。