sendToRenderers acts differently than callRenderer

[Laruxo]

From documentation I expected that these two functions act the same. Only expected difference was callRenderer sending to specific window and sendToRenderers sending to BrowserWindow.getAllWindows().

After digging deeper I found that sendToRenderers does not use the same channel formatting as the other method, so it is impossible to handle incoming messages using ipcRenderer.answerMain.

I have two possible solutions:

1. Exposing additional function in ipcRenderer to handle unchanged channel.
2. Formatting channel in sendToRenderers for every window.

@sindresorhus which one would you prefer?

[sindresorhus]

This behavior is intentional. It's meant as a broadcaster, not a two-way communication channel. Its docs doesn't mention any support for replying.

---

Exposing additional function in ipcRenderer to handle unchanged channel.

Not really clear what you mean. "Unchanged channel"?

Formatting channel in sendToRenderers for every window.

Same here. Not clear what you mean.

---

It could in theory support replying and receive an array of replies, but there are certain things that needs to be decided. Like, what if a renderer sends a rejected promise, should it throw or first wait for all renderers to send their response. I imagine it would also be some overhead of having to wait for all the renderers to respond. Electron IPC is not cheap.

[alaj]

I thought it was a bug when I couldn't receive message from sendToRenderers by answerMain.

[Razboy20]

I know this is an old issue, however is there a way to listen to sendToRenders within electron-better-ipc directly?

[serg06]

Ohh now I understand. ipcMain.callRenderer can only be answered by ipcRenderer.answerMain, and ipc.sendToRenderers can only be listened to by ipcRenderer.on.

For the last 4 years, I thought callRenderer was just broken because I wasn't receiving events. 😅