respose.setHeader() should return response to allow chaining

[SrBrahma]

Currently, response.setHeader() doesn't return anything. It really should simply return the response to allow chainings like response.setHeader(xxx).send(yyy)

[ttsugriy]

this can be easily accomplished by adding return this to https://github.com/nodejs/node/blob/master/lib/_http_outgoing.js#L550 but it would make usage of this function inconsistent with the rest of the setter APIs. While the pattern you're referring to is very common and is also known as builder, technically it violates the command-query separation principle. If Node maintainers don't mind this change, I'd be happy to send a PR :)

[awwright]

Is this related to #25935?

However, I would like to discourage this, because of the command-query separation principle; which is to say, methods that return things should not also mutate the state of the object.

[SrBrahma]

Is this related to #25935?

However, I would like to discourage this, because of the command-query separation principle; which is to say, methods that return things should not also mutate the state of the object.

Yes, looks the same issue. However, I really don't understand why this principle should be followed in this particular case. In the case that I mentioned,

response.setHeader(xxx).send(yyy)

as chaining isn't allowed, must currently be written as

response.setHeader(xxx)
response.send(yyy)

Chaining is a natural thing in JS. Wouldn't code like [1,2,3].map(...).filter(...).reduce(...) also violate this "principle"? For me, it only reduces productivity and readability having to follow something that doesn't make too much sense in this language.

This may be closed as duplicate, if wanted.

[ttsugriy]

@SrBrahma, I'm not a contributor to nodejs project, but I can answer your question as to if [1,2,3].map(...).filter(...).reduce(...) does or does not present the same API issue. The answer is no, because each call returns a new list instead of modifying an existing one, so all of these calls are "queries".

[awwright]

Chaining is a natural thing in JS

@SrBrahma I would disagree about "natural". It's tolerated; and I know some places do promote it; but there's also a strong tradition for functional programming, and when I see code like response.setHeader(xxx).send(yyy) my first thought is "Ah, setHeader must be a pure function, because it has a return value; and send must be a mutating function because the return value isn't used for anything".

The fact it's named setHeader does not suggest it's a mutating function; this naming scheme often suggests it returns a copy of response except with one thing changed.