node-red / node-red/node-red.github.io

msg transport - by reference issue

Abierto
#50 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
JavaScript
Estrellas
118
Forks
161
Merge medio
8 h 18 min
PR fusionados (30 d)
4

Descripción

Following discussions elsewhere I made a node called "node-red-contrib-diode" after discovering something I should have known already - that messages are passed by referrence, not by value. This can cause issues as someone may use a message twice in a function - sending it out with node-send and then re-using it. Should the receiving function or node alter the message in any way, because it was sent by reference - this can actually damage the original message. "diode" stops this - but I think this should be clearly pointed out in the documentation.

I found this...

ttp://nodered.org/docs/creating-nodes/node-js
Section "receiving messages"

Suggest you add: "Please note that a reference to the original message is passed here. Altering that message could, in edge cases, affect the calling function."

http://nodered.org/docs/writing-functions
Section "Writing functions"
Subsection "Writing a function"...

You say:

"The returned message object does not need to be same object as was passed in; the function can construct a completely new object before returning it. For example:
var newMsg = { payload: msg.payload.length };
return newMsg;
Note: constructing a new message object will lose any message properties of the received message. This will break some flows, for example the HTTP In/Response flow requires the msg.req and msg.res properties to be preserved end-to-end. In general, function nodes should return the message object they were passed having made any changes to its properties."

So firstly - why would construction a new message lose properties of the old. Using the code DaveCJ provided:

var newMsg = RED.util.cloneMessage(msg);

does not lose any of the original message - I tested it... so you seem to be saying NOT to make a new object - but you don't warn of the consequences. Why not change that example to use the code above which will ensure everything is copied across - scrap the warning that data could be lost and instead tell readers that this might slightly increase overhead - but will eliminate any chance of interaction with the original message.

In my diode node - here you see the unprocessed output - and the output through the node - they are identical down to the msgID - except for the payload which I deliberately altered to show the feedback effect.

msg : Object
{ _msgid: "e5a704f0.1a58f8", topic: "", payload: "goodbye", blah: "fred" }
6/26/2017, 2:31:23 PMnode: d9f3747f.7ef978
msg : Object
{ _msgid: "e5a704f0.1a58f8", topic: "", payload: "hello", blah: "fred" }

Hope this is helpful.

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Revisa la sección «receiving messages» de la documentación de creating-nodes/node-js y la subsección «Writing a function» de writing-functions. Comprueba las afirmaciones del issue sobre las referencias a mensajes, RED.util.cloneMessage(msg) y la conservación de propiedades antes de decidir qué orientación es correcta. Se considera terminado cuando ambas secciones explican claramente el comportamiento y sus consecuencias sin contradecirse entre sí.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
javascript
Área
documentation
Tipo de issue
Documentación
Dificultad
2/5
Tiempo estimado
Medio día
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
35/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.