Streaming changes to context (NR5?)

Core Development Feature Requests
1

Discussed here back in 2018, also here

Here's my idea for context explorer.
Optionally could have a little button next to each object that toggles streaming on and off. Would require guard rails in case of accidentally turning on streaming at the top level if user has huge amounts of updates per second to data stored in context. (e.g. auto-off when the sidebar loses focus)

Animation

2 Likes
2

It's certainly a nice idea, the problem is the existing context API doesn't provide an efficient way of being notified that something has changed. This means it would have to constantly poll for changes - and that's not efficient.

This is probably the main reason it hasn't got beyond the previous discussions. But certainly worth not forgetting should we solve the underlying challenge.

3

I have spoken to that previously. It would be massively helpful for the API to be extended to trigger events when a context var changes. So much of Node-RED can be event driven but not context. So people regularly end up maintaining both context and MQTT topics.

4

Then there is no point having a tool that wires things together if half of the wires are now invisible…

1 Like
5

I think we've had this convo before! :smiley:

You don't see "wires" when you subscribe to an MQTT topic do you? Even if that topic was set elsewhere in your flows (or from a completely different device). Subscribing to changes to context vars is absolutely no different. Similarly, there are no wires when you have other event-driven inputs such as filing system changes, websocket inputs, etc.

Having change events on context vars is simply another event-driven option.

Right now, I end up having to output data to MQTT simply to get events even though it would actually be often much easier simply to deal with the data in a context var. I end up having to maintain both.

Such an event architecture on context variables is a simple and common approach. Node.js supports this kind of architecture really well and it massively helps with asynchronous and disaggregated operations.

6

Yes it is different in that Mqtt (and other) services are running externally to Node-RED, and only have one node in or out. I would agree with you more if we just had a single node to get in and out of the wiring from/to context ( eg the change node) but we don’t. We have access to context all over the place with typed inputs and outputs..

I guess I’d be happier if there was a dedicated context in and out node as that would fit the model more clearly.

1 Like
7

That was the first solution that came to my mind when reading this, too. Doing it the Node-RED way, no wires hidden away...

The main benefit I see is that you could use this technique like an internal MQTT broker. If I remember correctly, there has been a discussion about something like this before, using MQTT subscription patterns on an in-process context... :thinking:

1 Like
8

And there is no reason why we shouldn't have these. We would at least need an "in" node to listen for changes in any case. I believe that I may already have a contributed context node - though it hasn't been needed for a long time but it dates from before we could use things like the change node to set context.

Obviously, context can be set from many places as it is a very flexible feature and we cannot undo that, nor would anyone want to. But in my view, that simply reinforces the argument for having an event-driven model for changes. Right now, it is impossible to keep track of what updates a context variable unless you manually build in an extra property and set it, this is fragile. With update events, we would at least know when a variable had been changed even if the event handler couldn't know from where.

1 Like
9

There are options, e.g. :

@ralphwetzel/node-red-context-monitor

A Node-RED node to monitor a context.

What it does

This node allows to setup the reference to a context, then sends a message when this context is written to.

3 Likes
10

Sheesh! Too many great nodes - I missed that one. :smiley: