I need to do something like this:
send('message').user('usr1').message('msg').to('usr2');
So send function accept one argument and has a prototype called user and user accept one argument and has a prototype called message and so on.
I just wrote this
function send(type){
console.log(type);
}
send.prototype.user = function (usr) {
console.log(usr);
}
But how can i go deeply and chaining like in the provided example?
You can use class and flow pattern
class Sender {
constructor(msg) {
this.msg = [msg];
}
user(usr) {
this.usr = usr;
return this;
}
message(msg) {
this.msg.push(msg);
return this;
}
to(usr) {
this.to = usr;
console.log(this);
return this;
}
}
function send(msg) {
return new Sender(msg);
}
send('message').user('usr1').message('msg').to('usr2');
You need your functions to return the specific type like this:
function send(type){
return new User(type); // Return some user
}
function user (usr) {
return new Message(usr); // Return some message
}
You seem to be conflating the prototype chain with function chaining. The former is how javascript does inheritance. The latter is what you seem to want to do: call a function, then call a function on its return value, then call a function on its return value, etc.
In may cases, function chaining involves functions returning a reference to the object on which they reside. For example:
const sampleObject = {
sayHello: function() {
console.log('hello');
return this; // <-- necessary to allow function chaining
},
sayGoodBye: function() {
console.log('good bye');
return this;
}
}
sampleObject.sayHello().sayGoodBye();If you want to have the functions return objects other than this that's possible too, but exactly what to return will depend on what you're trying to do.
Since "Object Oriented" is in your title, I thought I'd take the chance to give an example of an OO way to analyse this.
First of all we'll want to identify the object instigating the actions. "Send" is not an object, it is the name of an action, so that's not going to be our object. There are two candidates left in your code: user and message.
There are two ways to look at this.
The pros of 1.
The cons of 1.
Pros of 2.
Cons of 2.
So, we have a conflict between avoiding bad semantics or avoiding bloating a class.
Perhaps there is a third way. What if we had an object that makes sure messages get where they're meant to go?
In the real world that's the post office.
This essentially gives us a factory pattern type class.
function PostOffice()
{
}
PostOffice.prototype.createMessage = function(messageBody)
{
this.message =
{
"body":messageBody,
"fromUser": null,
"toUser": null
};
return this;
};
PostOffice.prototype.from = function(user)
{
this.message.fromUser = user;
return this;
};
PostOffice.prototype.to = function(user)
{
this.message.toUser = user;
return this;
};
PostOffice.prototype.send = function()
{
//whatever sending means
};
var po = new PostOffice();
po.createMessage('hi').from('user1').to('user2').send();
This is obviously a toy example, but hopefully you get the idea.
