The envelope
{
"type": "inventory.changed",
"data": {
"sku": "A-104",
"available": 8
}
}type usually chooses the route or event. data usually carries the payload. Either may be absent, and js-message does not impose a vocabulary or schema inside either value. Applications can layer validation above this transport convention.
{ "type": "ping" }A payload-free signal loads with data === undefined and serializes without a dummy data key.
What load() does
| Input | Outcome |
|---|---|
| JSON string with any available message fields | Parsed and assigned |
| Buffer, boxed string, typed view, or other JSON-coercible text | Native text coercion, then parsing |
| Existing plain object | Available fields assigned by reference |
| Field omitted | The corresponding instance field becomes undefined. |
| Extra object key | Accessible on the input but excluded from normalized serialization. |
| Malformed JSON text | Recoverable error message whose live err is a SyntaxError. |
| Null or uncoercible input | Recoverable error message whose live err is a TypeError. |
If an application requires type, data, or a payload schema, validate that policy above js-message.
Normalization rules
- Extra keys in loaded input are ignored when the message is serialized.
- Object input keeps the original
datareference; js-message does not clone payloads. - Missing
typeordatafields assignundefinedfor compatibility. - Direct assignment to either field is unrestricted.
JSONuses nativeJSON.stringifybehavior, including omission, conversion, and errors.- A later valid
load()replaces an earlier error state, so one instance can recover.
If a message must cross JSON, prefer strings, numbers, booleans, null, arrays, and plain objects. Cycles and BigInt make native serialization throw.