I'm not the socket specialist, but I see some discrepancy between the code pattern as posted and as found on Espruino internet sockets documentation page.
From your code I read that it is a client... and the events are on the client and not the socket directly, and the client is the result of a .connect() applied on the retrieved module object. To me it also matters what the server is doing... Always - unconditionally - going into a reconnect may not be the final solution. It may work to talk directly to the socket, but it may as well interfere how Espruino socket client handles the life cycle of the socket. I like a higher level interface such as the client, but the client may be to simple because it hides complexity / flexible options. Anyway, take a look at the client.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
I'm not the socket specialist, but I see some discrepancy between the code pattern as posted and as found on Espruino internet sockets documentation page.
From your code I read that it is a client... and the events are on the client and not the socket directly, and the client is the result of a
.connect()
applied on the retrieved module object. To me it also matters what the server is doing... Always - unconditionally - going into a reconnect may not be the final solution. It may work to talk directly to the socket, but it may as well interfere how Espruino socket client handles the life cycle of the socket. I like a higher level interface such as the client, but the client may be to simple because it hides complexity / flexible options. Anyway, take a look at the client.