I'm building a Javascript client app that has live communication with a Phoenix server, and wants to know if a message pushed to the server has been received. It looks like Phoenix's socket.js wants me to use something like:
channel.push("mymessage", {data: 123})
.receive("ok", function(){ console.log("Message pushed successfully"); });
However, I can't get this event handler to fire unless I change my return value on the Phoenix app to be {:reply, :ok, socket}, like so:
def handle_in("mymessage", %{"data" => data} = payload, socket) do
{:reply, :ok, socket}
# not {:noreply, socket}
end
I guess it makes sense that {:noreply, socket} doesn't actually send a message in response to the client, but in what case would you want to send a message to the server and not have it let you know that it worked? Or am I misunderstanding something? I feel like with normal HTTP requests, you always check if the request was successful from the client.
You're right: {:reply, :ok, socket} will send a reply message with "ok", and {:noreply, socket} won't send anything in response. You should use the former if you want to ensure that the message was sent, but often that's impractical or unnecessary (think of broadcasting a chat message to thousands of connected users--it's impractical to track "ack" messages for all of them).
I feel like with normal HTTP requests, you always check if the request was successful from the client.
WebSockets exist for situations that normal HTTP requests don't work well, and one-way communication is one of those cases.