Moving this discussion to a more appropriate category...
No, just "local" context for each change node -- that way, I can keep any received or computed values between msgs. From the Proposed Changes section of PR #1515:
In order to use the Change node as a toggle (for instance), the previous value received needs to be saved to local context (only available to this change node). This new feature provides a local. pulldown option (similar to flow. and global.) to set/get a named variable.
The local context variables also can be retrieved in JSONata expression, using a new $flowContext(name) function. Again, similar to the $flowContext(name) and $globalContext(name) functions, but without the potential for conflicting variable names.
Now that 0.19 is being actively worked on, is this a good time to add this feature?
For me flow context can induce to many errors so I prefer t avoid the use of them, instead prefer to use global variables and make a good sense and be consistent on the names to avoid issues.
From other side I consider global variables should be persistent, I mean values are recovered after power cycle for instance, for the moment I’m doing it saving all variables into a file and recover at startup however I think this is a feature that most of them expect to have it integrated some day into node red.
From my point of view node-red-contrib-contextbrowser should be also a feature expected to be standard directly coming on node red editor.
I second that: persistance is most wanted (although it can be simulated using file read/write) and the features of node-red-contrib-contextbrowser should be included (but refactored) in the core NR editor.
Reviving an old discussion. Has it been settled whether adding local context to the change node would be a good idea -- or even possible? I am working on a flow that uses function nodes where thechange node would be a better choice if it had this capability.
You're right about "hang-ups", but in this case I expect to have many (perhaps dozens) of similar nodes, and I don't want to have to keep track of a unique variable name for each one. Just keeping it local to the node would be a help.
I completely agree... when i want to make a named variable available to just a single node, why should i be forced to give it a unique name within the whole flow?
That's a nice trick. It probably also makes it easier to see what's happening in the Context Data tab of the sidebar. Still, it just pushes off the problem of unique names from the variable to the properties.
It really shouldn't be a problem at the property level unless you've really lost track of what you are doing. You have to accept somewhere that you need to keep track of data.
Honestly, I don't think I've ever had a name clash in global variables and I use a fair few. I do occasionally forget that I've been maintaining a variable and end up with a 2nd quite similar! That's old age for you
One of the things I like about JavaScript is the ease with which you can process objects which makes it so easy to treat them as small, dynamic databases. So I rarely need an actual database unless I need to handle a lot of data. Node-RED's new ability to keep the variables written to disk extends this idea. If you think of global variables as small data tables, it gives you a different perspective.
No doubt about that. I'm only thinking about the case where a node has some local information that it needs to maintain, and nothing (and no one) else needs to know about it. If I deploy many copies of that node, I would rather not have to edit each copy to assign a variable or property name when I could be doing just copy, paste, and forget. Just a minor inconvenience, really, not a major source of errors.
On the deeper subject of "things I like about JavaScript," most object-oriented languages offer similar facility in manipulating objects. Persistence is a great feature in NR, and perhaps one day some form of it could be implemented in JS. On the other hand, JS has (at least until very recently) done a really poor job of controlling the scope of variables. "Bad" habits brought over from other languages have caused me some headaches.
Agreed on that. And I still have to think really carefully what context things are running in. There is far too much rapid drastic change happening in the JS world.
I love using const and let but it isn't really safe to use on anything front-end related yet unless you use babel.
Similarly, I'd like to switch from require to import in Node.js but that is a complete mess even in the latest versions. Again not safe to use on the front-end without a babel build step.
Its much easier to use a variable called local context variable called count rather than having to remember to rename it to something different - use of local variables has been promoted as "a very good thing" in programming for a long time
I'd love to see local context available for change node and not just the function one
I absolutely agree. When using flow/global variables, or indeed in any programming, I always use meaningful names for things. Even within a program, function or whatever, it is easy enough to end up with a clash if using generic names. i is a popular one for looping but occasionally it will catch you out with an inner loop for example.
So I prefer to use more meaningful names even locally and certainly so the more generic the variable's scope.
countIncomingMsgs for example rather than just count which helps you immediately understand what the content means.
Exactly right. This discussion started with the question of whether a local context ought to be available in the change node. We seem to have reached a consensus (that is, "probably yes") but have not heard anything from the lead developers about the probability of making it happen.
If I understand this correctly from the top of the thread, there was a PR that was set aside temporarily. Either @shrickus or the devs might be able to say whether it is still usable or nearly so.
