frodovdr
/
node-red
mirror of https://github.com/node-red/node-red.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Updated Design: Enhancements to Split Join nodes (markdown)

Dave Conway-Jones 2017-04-10 09:37:29 +01:00
parent e2fb84d935
commit 8f9532940d
1 changed files with 13 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
Design:-Enhancements-to-Split-Join-nodes.md

@ -29,7 +29,7 @@ All of these either wait for
- a msg containing a property `msg.complete`
before triggering the send of the joined message.
### Proposal 1 - Accumulate object mode
### Proposal 1a - Accumulate object mode
Whilst broadly similar to the **merged object** mode, this would not wait for a count or timeout. It would instead send the accumulated object every time a new message arrives. This way the contents of an accumulated object can keep being updated (and sent) without the user having to resort to function nodes and context and so on.
For example a user wants to create the following object
@ -46,12 +46,20 @@ Using this new mode all three messages could be combined by the join node into t
In addition if a msg does arrive with a `msg.completed` property - then the accumulated msg is sent and then the object is reset. This is consistent with other modes.
### Proposal 2 - Accumulate name/value pairs mode
Similar in thinking to proposal 1, this should also be a sub mode of the **key/value** mode of operation - ie allow use of a msg property (like the topic) to create the properties - this would be even simpler than Proposal 1 above for use with UI nodes.
### Proposal 1b - Accumulate key/value pairs mode
Similar in to proposal 1, this should also be the equivalent but for the **key/value** mode of operation - ie allow use of a msg property (like the topic) to create the properties - this would be even simpler than Proposal 1a above for use with UI nodes, and general msgs that just have a topic and payload (for example MQTT inputs)
### Potential implementation
These could be implemented,
- either as stand alone modes of operation. IE Accumulate objects and Accumulate name/value pairs. (see below)
- either as stand alone modes of operation. IE Accumulate objects and Accumulate key/value pairs. (see below)
- or as a sub mode of the exiting modes - for example by allowing a "special" use of a count of zero inputs to indicate "infinite" (ie send every time).
![](http://g.recordit.co/SQMEE8pJmD.gif)
![](http://g.recordit.co/SQMEE8pJmD.gif)
### Proposal 2
In the **key/value** mode(s) the outgoing msg.topic is currently set by the last to arrive msg. It should be possible to set a new overall msg.topic for the new merged object. (Actually it can be another property that is used as the key - not just topic - but the thinking is the same).
### Proposal 3
Enhance the Join node to have a name field - All nodes should have a name field - not sure why we forgot it here.