Hapi: Confused about "reply()" vs "return reply()"

[paulovieira]

In the route handler, should I call
reply("some payload")
or
return reply("some payload")?

I see both versions in the documentation.

Suppose I don't want to use the response object returned by reply. Is there any difference then?

In the first case the handler will return undefined back to the router. In the second, it will return the response. Is the response used for anything?

Thanks.

[arb]

return reply('some payload') is a JavaScript convention used to stop code execution at that point rather than continuing "down the page."

Example

function (request, reply) {

  if (someCondition) {
    return reply('someCondition was true');
  }
  reply('someCondition was false');
}

In this example, if return was omitted, reply would be called twice which would generate an error because you won't call reply twice for the same request.

That being said, the documentation should be consistent :smile:

[paulovieira]

Thanks.

So in the route handler I might as well be explicit and always call return reply.

[hueniverse]

Calling return callback() is a general best practice because it calls attention to the fact that execution is moving elsewhere.

[csrl]

@paulovieira

I agree that the convention is confusing, as it creates uncertainty whether the return value matters or not. Early in learning the new environment it adds an unnecessary stumbling block. Personally, I always put the return statement on the following line, like so:

  reply("some payload");
  return;

This makes it perfectly clear that the return value of reply() has no significance and the containing function has no intention to return anything.

However, you can generally assume that if the containing function has a callback parameter, then the return value has no significance.

[isaldarriaga]

Just to complement the information (suggested read):

Use A Return Statement When Invoking Callbacks, Especially In A Guard Statement
By Ben Nadel on February 1, 2012

http://www.bennadel.com/blog/2323-use-a-return-statement-when-invoking-callbacks-especially-in-a-guard-statement.htm

[clivend]

+1 do we have a best practice in the end?

[johnbrett]

@clivend as @hueniverse mentioned return callback() is always considered best practice.

[clivend]

@johnbrett sorry I didn't notice this is a "question" so maybe there's no "closed" event :)

[kswope]

As somebody with 20+ years of development and 3+ days of hapi I just have to say this is a horrible 'best practice'. I think @csrl style, although messy, is so much more clear. As somebody learning hapi I had to find this obscure github issue to figure out whats going on. I'm still not sure because I wouldn't be surprised if someday (maybe even today) returning a promise from a handler does something.

In an untyped language seeing something like this below tells most programmers that returning the return value from B is important. There is NO WAY anybody would think this means "run B and then return". This means "return the return value of B".

function A(){
  return B()
}

This is the kind of stuff that is making typescript and flow so popular now.

[tikotus]

Totally agree with @kswope, here for the same reason.

Also, what if the handler does a db query and does the reply asynchronously? Wasn't sure if that's allowed because of return in all examples.

[humoyun]

So if I understood correctly, reply just returns response object and that response is not sent to the client (if the return is not used) until later in the request lifecycle?

[mtharrison]

and that response is not sent to the client (if the return is not used) until later in the request lifecycle?

return or not has no bearing on lifecycle behaviour. Either way the response isn't sent until later.

[hueniverse]

In v16. None of this is relevant to v17.

[lock[bot]]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.