The next, and hopefully finally, beta of 0.20.0 is now available.
For the background on why we're doing betas, please read the post for the previous betas:
The CHANGELOG has the full set of changes.
Highlights
These beta introduces a number of new features to Subflows.
Subflow Status
There is a new option to add a 'status' output to a subflow. This can be used to update the Status of subflow instance nodes. With subflows currently, if any node inside the subflow emits a status event, it would pass up to the flow containing the subflow instance - but it wouldn't appear to have come from the subflow instance. Now, if this new status output is used, only messages passed to it will get passed to the parent flow and they will be properly identified as having come from the subflow. This gives a lot more control and flexibility of working with status events and subflows.
Adding a status output:
Status appears against the subflow instance node just like any other node with status
Redirecting status events from inside a subflow
Accessing parent flow context
When using context within a subflow, it is now possible to access the context of the flow the subflow instance is on. This is done by prepending the context key name with $parent.. For example, if a flow has a context value of foo, a subflow could use flow.get("$parent.foo"); to access it.
Accessing parent flow context in a Change node
Subflow Instance properties
It is now possible to define environment variables in a subflow. These are values that any node in the subflow can then reference in the same way as they can normal environment variables:
- by setting a node property to
$(ENV_VAR_NAME) - by choosing the 'env' type in a typedInput
- by using
env.get('ENV_VAR_NAME')in a Function node
These properties can be set on the Subflow template, but also on individual instances of the subflow. That means you can design a subflow that can be customised on a per-instance basis. Unlike the process-wide environment variables which can only be Strings, the env vars defined on a subflow can be multiple types - string, number, boolean, JSON, Buffer or even a reference to another env-var. This last option means you can create composite env-vars made up of other env vars... and oh my just think of the possibilities.
When a flow references an environment variable, if it is not defined on the subflow (or the subflow containing the subflow, or the subflow containing that subflow... and so on), it will fallback to the process-wide environment variables. If it isn't set there either, it will return an empty string "" - not undefined.
Adding env vars to a Subflow template
Here an environment variable
FOO is defined with the value "red".
Adding env vars to a Subflow instance
When editing the subflow instance, the env var table lists the env vars defined on the subflow template. In this image you can see
FOO is listed. Its value can be customised for this instance - if you do customise it, a button appears to the right that lets you revert it back to the value the parent subflow defined. You can also add new env vars just for this instance - as shown above with BAR.
These new subflow features address a lot of common requests and feedback we get about them. We think this will make them a much more powerful tool within Node-RED.
Node updates
- The Catch node has a new option to only handle node errors that have not been caught by another catch node. This means you can have catch nodes targeting specific nodes in a flow, and then one that catches everything else.
- The HTTP Request node can optionally automatically encode msg.payload as query string parameters for a GET request. It also has a new option to url-encode cookies (if, in rare circumstances, they need encoding rather than leave as plain text)
- The MQTT In node can now be configured to assume messages it receives are JSON and to emit the parsed object. That will save you from adding a JSON node after your MQTT In nodes if you are sure that everything you receive will be valid JSON. If the node receives something that isn't valid JSON, it'll log an error that can be handled with a Catch node.
Installing the beta
If you want to try out the beta, you will need specify node-red@next when you use npm to update. Without the @next you'll still get 0.19.5.
So on a Pi you'd do:
sudo npm install -g --unsafe-perm node-red@next
Reporting problems
If you hit any problems, please report them either as a reply on this topic, or in the #dev slack channel. Please do not post new topics to the forum regarding the beta as that could confuse users who are not using the beta.
Outstanding work
The list of outstanding issues and PRs for 0.20 is very small now. The main focus is documentation around the runtime/editor split packaging.
The goal is to publish 0.20.0-final before the end of February.
