Proposal: handle onMessage by message type

[endel]

This would be a big breaking change, I'd like to know your thoughts and opinions about this. Will it be valuable/worth doing? Feedback is highly appreciated!

Server-side

client.send() to replace this.send() + message type:

// new
client.send("skill", { name: "fireball" })

// deprecate
this.send(client, { type: "skill", name: "fireball" }

client.send() a schema-encoded message

This is already supported by the server-side. See below plans to support this from client-side as well.

class SkillMessage extends Schema {
  @type("string") name: string;
}

const skill = new SkillMessage();
skill.name = "fireball";
client.send(skill);

Broadcast with type + data

// new
this.broadcast("skill", { name: "fireball" })

// deprecate
this.broadcast({ type: "skill", name: "fireball" })

onMessage to handle messages sent from the clients

// new
onCreate() {
    this.onMessage("move", (client, message) => {
        // handle "move" message
    });

    this.onMessage(MoveMessage, (client, message) => {
        // handle schema-encoded "SchemaMessage"
        // (get autocompletion for "message")
    });
}

// deprecate
onMessage(client, message) {
}

Client-side

Allow sending the type of a message along with its data:

// new
room.send("move", { angle: 270 });

// deprecate
room.send({ type: "move", angle: 170 });

Allow sending a Schema structure from the client-side (this will be specially useful for strongly-typed languages, such as C#, C++, etc.)

class MoveMessage extends Schema {
    @type("number") angle: number;
}

const message = new MoveMessage();
message.angle = 170;

room.send(message);

Receiving messages by type:

// new
room.onMessage("skill", (message) => {
  // handle "skill" message
});

room.onMessage(SkillMessage, (message) => {
  // handle schema-encoded "skill" message
});

// deprecate
room.onMessage((message) => {
  // handle any type of message
});

---

As always suggestions are welcome.

[seiyria]

I personally welcome this change: I had to write my own wrapper to do this, and I believe many others have had to do similar. Having it be baked in would save people from needing to have varied approaches to doing this (which ultimately all accomplish the same thing).

[damian-pastorini]

Hi @endel , my 2 cents from a newbie dev point of view.

This:

// new
this.broadcast("skill", { name: "fireball" })
// deprecate
this.broadcast({ type: "skill", name: "fireball" })

And this:

// new
room.send("move", { angle: 270 });
// deprecate
room.send({ type: "move", angle: 170 });

Feels really forcing clients to do stuff we sometimes don't need, I understand it could have good impact related to typed code, but if in some cases we just need to send one value, like:
room.send({myVal: 1 }); I would be forced to send a type I just may not need.

Also I'm guessing that would impact on the "traffic" and the amount of data sent?
If try to minimize my traffic as low as possible, in some cases I could be doing something like:
room.send({x: 1 }); and include type would be room.send('x', {x: 1 }); ? is an additional param in every data send.

On the other hand, manage schema classes like this:

// new
room.onMessage(SkillMessage, (message) => {
  // handle schema-encoded "skill" message
});

room.onMessage("skill", (message) => {
  // handle "skill" message
});

// deprecate
room.onMessage((message) => {
  // handle any type of message
});

It looks so much better! You would probably save me so many conditions checking if the message is coming with some specific value to run an action.

[seiyria]

Feels really forcing clients to do stuff we sometimes don't need, I understand it could have good impact related to typed code, but if in some cases we just need to send one value, like:
room.send({myVal: 1 }); I would be forced to send a type I just may not need.

It definitely means this can be typed more strongly, which is good- you can force a message of a type to have certain values, which is good for developers, and sanity.

Additionally, if you are doing something like room.send({ val: 1 }), how does your client know what to do with it? You implicitly have a type there that you're just not sending, but you're still doing the same thing you would if you had a type, only it makes more sense.

The real bandwidth saves don't come from cutting a small type property (a max of a few bytes per message), but rather from not sending large amounts of data.

[endel]

Regarding the number of bytes being sent, room.send('x', 1) would actually result in less bytes than room.send({x: 1}) 👀

[damian-pastorini]

Thanks for the clarification @seiyria , in the commented case the client could know what to do depending on the attribute sent, room.send({ val: 1 }) > could be room.send({ x: 1 }) or room.send({ y: 1 }), that's what I mean, and the same could be applied for broadcast, I could just brodcast({o:12}), and the client could remove the "o" (for object) with ID 12.
@endel now room.send('x', 1) makes much more sense, I was thinking that I was forced to send the second parameter as an object as well in the send method, like in the first example: room.send('x', {x: 1}), if I would be able to just send the type and the value like you just commented room.send('x', 1) that's amazing 😍

[damian-pastorini]

I'll better be mentally preparing for another full refactor on my app 😅

[Zielak]

That'll sure be breaking change for me, but I'll accept it. I'm sending "type" values with every event anyway :)

[stats]

I like this change.

[krazyjakee]

So let's say I have a lot of these around my application, presumably at the moment ALL callback functions are called for every message. Could this mean an optimisation where the callback fires only when that message type is received?

[liana-p]

I'm already kind of doing this manually in my game, so having an "official" way to handle message types would be nice.

It should probably be optional for those who want to send very small efficient messages though...

Also bonus point if it can be a number so we can use enums to reduce bandwidth usage, otherwise including a string type on every message increases the size of the message.

[Bluebang]

cool😁

[zgz682000]

It sounds like an amazing change, and I would more like to use Schema instead of Fossil Delta. Why I choose Fossil Delta but not Schema? Because the schema code generator is not customable. Would you consider to implement the generator by template mechanism？

[endel]

Hi @zgz682000, you mind elaborating the "template mechanism" on a new issue? Cheers!

[AJ92]

i also support the change :)

maybe the old public interface can be kept? it can just call the new stuff where ever possible so not everything has to be refactored ?

[zgz682000]

Hi @zgz682000, you mind elaborating the "template mechanism" on a new issue? Cheers!

of cause, I will write my advice in the schema repository after have a research of it

[Bluebang]

Can you consider adding a one-time request method?

//Current implementation methods
//client side
function JustDoOnce(){
    client.send(getSysCfg,{});
    client.onMessage(getSysCfg, (message) => {
        client.removeListener(getSysCfg);
        //dosomething
    });
}

//My suggestion
//client side
function JustDoOnce(){
    client.send(getSysCfg,{}).then(data=>{
        //dosomething
    })
}

Can I do this?😁

[zgz682000]

0.13.x seems not implement the usage like thisthis.onMessage(MoveMessage, (client, msg)=>{}). Is it still in you future plan?

[endel]

Hi @zgz682000, only the client-side is able to listen to Schema messages.

The client-side is not allowed to send Schema messages so far, because only the JavaScript client has the encoder implemented. Writing the Schema encoder on other languages would be a huge effort.

[zgz682000]

Thank you for response immediately. may it be used as a optional way of listening message, even if temporarily provide for JS/TS ?

[zgz682000]

although I don't know why I hope this, maybe just for looks cool... or... comfortable...