Function node context, debug when accessing properties instead of getter/setter?

General
1

Interested in the distinction between context.foo and context.get("foo")/context.set("foo", bar). I thought they were equivalent if not identical. But I can't see context values in sidebar when accessing properties directly (instead of getters/setters). So am I rightfully confused, or are these in fact different?

2

Yes they are different. context.foo is purely only in memory as it is just adding a property to the in memory context object. set and get go via the storage api - so while they may be in memory, they can also be configured to be on disk or database etc - and indeed if the default is set to be on disk then context.set("foo","abc") will not be same as context.foo = abc.

1 Like
3

Thanks that's great info. Perhaps if I use persisent file context by default and one place just need memory, I could simply use this. The context debug sidepanel seems to also be affected? It was empty when using context.foo.

4

Why do you want to not use get/set?

5

I think this context object should be frozen when introduced in order to prevent this 'misuse' but it is what it is now.

6

Indeed that is a sneaky workaround, and indeed a use case I have used myself for exactly that. I wanted most things persisted by default, but not a few working variables within functions etc.
Also you can’t persist non-serialisable objects externally, and occasionally you may want to.

7

Nice hehe. I am going to have to add a comment when doing that so I remember, because this is a detail easily forgotten.

Why not use get/set? It's twofold. With this 'misuse', I can quickly use memory without having to add context store in settings.js. Perhaps more importantly, I'm not fan of the string reference in general. I find myself fumble alot when working with context. Misspelling the name. Lose overview. More so with flow/global when code that uses same flow context is split across multiple function nodes. I'm used to having IDE show me when I misspell something and code refusing to run. Here it "fails" silently. You have to be totally precise and you don't get any help. Further, to see the stored values, you have to open context sidetab then click on nodes, refresh and so forth. While I'm also interested in seeing debug messags, so have to go back and forth. I get what it is and why it is this way, but for me it's just not smooth enough. Accessing props directly just feels a tiny bit easier and natural.

Perhaps my biggest wish for any js environment was that it was typescript instead :joy: It helps for lazy/clumsy and new developers alike.

8

Surely you would want to simply create two context stores - I always create 2 with the following settings:

    contextStorage: {
        default: {
            module: 'memory',
        },
        file: {
            module: 'localfilesystem',
            // config: {
            //     flushInterval: '10', // default is 30s
            //     dir: '/home/user/.node-red/context',
            // },
        },
    },

And I always use get/set because I absolutely know that one day I'll switch store types and things will fail for non-obvious reasons.

1 Like