Starting with v1.1, the function node now has the setup and close tab. This initially got me very excited.
However, when thinking about possible use cases with the current functionality in more detail, I mostly can see the purpose in initializing context variables.
I came up with a few other ideas which would require quite a different philosophy of the node, so I would like to hear your opinions on that and maybe also what other use cases are you can think of with the functionality as it is today.
As far as I can see, the setup handler does not support all features of the main function body.
For example, node.status cannot be used (workaround working today __node__.status).
But more importantly, I thought about using the setup handler to access an npm module, call its constructor and maybe establish some callbacks from the module, which then would send out a message if they are called. An example would be an npm module that connects to some service and has a callback when a message from the service is received. In order to do so, one would need access to the send and done function in the setup handler.
It seems that such a functionality is against the philosophy of the function node in its current form. For example, the node would "wait" (in the async sense) until the code in setup handler has finished and then only goes on with processing messages.
It is also not clear to me if storing an instance of the npm module in the context is a good idea in this case (to share it between the setup and the main function body)
The code in the close handler does, as far as I can see, not allow async function calls, which would also be required if the above mentioned functionality would be considered.
I personally would not be sure if I would use it much, since I could also just create a custom node, but maybe for one time things where you also don't need to create a ui for configuration, this might be an interesting idea, I think.
That then feeds into being able to export subflows themselves as npm modules. That would only work if the subflow was able to package it's dependencies without the user having to edit their settings file.
It terms of what node APIs are then exposed in the setup/close stages of the function, we've started small, exposing a bare minimum. It is easier to add then it is to take away. So yes, working through some more concrete uses of the new features will help identify what makes sense to expose.
(it was no critique in any way, I think it is totally sensible to start with a bare minimum, I just wanted to start a discussion for possible extensions)
I have read the design note and it is good idea to more easily add npm dependencies.
If I would summarize my requirements:
expose send, done in the setup handler (when done is called, resolve the promise)
expose status, log, warn, error (maybe also id, name etc.) both in setup and closing handler
make closing handler optionally async by exposing done.
This would make the function node quite equivalent to a custom node (ignoring the ui).
I guess this would then allow to resolve the problem the user in this thread Use a Wiegand RFID Reader wants to solve without writing a custom node.
I looked a little into this and implemented a "minimally invasive" version (i.e. with as little code changes as possible) of exposing status, log, warn, error, debug, trace as well as send in the setup handler.
Having done in the setup handler does not make too much sense I guess, since being an async function, one can achieve the behavior right now and since the setup code is executed in the constructor of the node, the done behavior of the runtime is not available anyway, is it?
I could file a PR, but maybe more discussion is needed first?
About the closing handler, if one would make it an async function, then exposing done would also not be needed.
Yes, more discussion is needed. Raise the PR against the dev branch. At this point, that's where this discussion should happen regardless of what ends up going in.
But like I said, we aren't rushing to throw everything in, regardless of how "minimally invasive" the code change is. What matters is whether the functionality makes sense and doesn't cause unintended issues.
I know that double underscore is the most clear way to state that you are not supposed to use it