This is what happens on the server side:

1. We defined two namespaces, "/en" and "/es", then added a new event listener, getData, to the socket object.
2. When the getData event is fired in any of the two defined namespaces, it will emit a data event and send an object, that contains a title and a message property, to the client

On the client side, inside the script tag in our HTML document:

1. Initially, a new socket is created for the namespace "/en":

      const socket = manager.socket('/en')

2. At the same time, we created two new sockets for the namespaces "/en" and "/es". They will act as reserved connections:

      manager.socket('/en')
      manager.socket('/es')

3. After, an event listener connect was added that sends a request to the server on connection
4. Then, another event listener data was added that is fired when data is received from the server
5. Inside the event listener that handles onclick events for our button, we change the nsp property to switch to a different namespace. However, for this to happen, we had to disconnect the socket first, and call the open method to make a new connection again using the new namespace

Let's see one of the confusing parts about reserved connections. When you create one or more sockets in the same namespace, the first connection is reused, for example:

const first = manager.socket('/home')
const second = manager.socket('/home') // <- reuses first connection

On the client side, if there were no reserved connections, then switching to a namespace that was not used before would result in a new connection being created.
If you are curious, remove these two lines from the nsp-client.html file:

manager.socket('/en')
manager.socket('/es')

Afterwards, restart or run the Socket.IO server again. You will notice that there is a slow response when switching to a different namespace because a new connection is created instead of being reused.

There is an alternative way of achieving the same goal. We could have created two sockets that point to two different namespaces, "/en" and "/es". Then, we could have added two event listeners connect and data to each socket. However, because the first and second socket would contain the same event names and receive data in the same format from the server, we would have gotten repeated code. Imagine the case if we had to do the same for five different namespaces that have the same event names and receive data in the same format, there would be too many repeated lines of code. This is where switching namespaces and reusing the same socket object is helpful. However, there may be cases were two or more different namespaces have different event names for different kinds of event, in that case, it is better to add event listeners for each of the namespaces separately. For example:

const englishNamespace = manager.socket('/en')
const spanishNamespace = manager.socket('/es')
// They listen to different events
englishNamespace.on('showMessage', (data) => {})
spanishNamespace.on('mostrarMensaje', (data) => {})