填(挖)个坑之科学合理地规划和使用nodered可共享数据

这是我自己在使用nr的时候,随着响应应答等各类流程的越来越复杂,维护日趋吃力后反思,
遍历所有流程共通的一些节点和临时数据,总结之后发现,其实之前很多的节点和流都重复了,
很多重复的流可以改成子流程,很多重复的数据获取变量存储都可以简化甚至去除。

举一个例子

企业微信这个节点,相信很多人都用了,

不知道你们有没有发现,它会生成3个全局变量,分别是百度云的access token和企业微信的access token。订正,是我记错了,那个是我自己设的全局变量,节点变量没有显现出来。

于是在某些时候,我们需要用到百度云的access token就不需要再重复去获取,直接引用即可,当然你在申请百度云的时候需要把所有功能全部选上才行。

再比如在不同的流里面使用企业微信服务端节点是不行的,做成子流程,把关键词判断,多次轮询对话这些独立出来到子流程里面,后面只需要接着搞后续的节点即可。这样不需要在一个流页面里面放太多太多的东西,便于阅读和维护。

再比如小爱TTS的节点是不能添加多个的,也需要做成子流,在不同的流里面引入子流即可。

类似的例子很多,如果梳理一下之前的那些流,去掉多余的东西,你会发现不仅仅是在阅读性上还是维护性方面都会有很大的改善。。

后面有空分享一些可以通用的子流 :grinning: 这个坑我先挖了。。

见证,来三木大佬吃水果:banana::pear::peach::peach::tangerine::apple::cherries::melon::strawberry::grapes::watermelon::green_apple::lemon:

很久没见大佬发贴了,确实有这样的体会,很多是可以做成子流共享的,可以极简化流程,更加方便后续更改

翻车王表示做个伸手党真好,翻车一时爽 一直翻车一直爽

你确定小爱TTS节点放在子流程里可行?
我记得子流程的多个实例里面所有节点都有不同实例啊。

我感觉小爱TTS好像有一点问题,之前我也是想用子流程的,发现会有问题,然后我就用link,自己做了个function,顺便重新做了个队列的功能