I have a lot of IPC listeners (more than 30) on my electron application, but I wonder which one is better in terms of performance.
The first solution (Implement IPC listener as many as it needed):
ipcMain.on('appLanguageChange', (event, data) => {
//do something with data
})
ipcMain.on('current-patient-ask', (event, data) => {
//do something with data
})
ipcMain.on('patient-set', (event, data) => {
//do something with data
})
//Still need many listeners below..
The second solution (Using Switch and only implementing one IPC listener):
ipcMain.on('data-flow', (event, topic, data) => {
switch (topic) {
case "appLanguageChange":
//do something with data
case "current-patient-ask":
//do something with data
case "patient-set":
//do something with data
break;
//Still need many cases below..
})
Currently, I am using the second solution, is it a good approach? Because I am aware that some people could get a warning that too many IPC listeners have already implemented. How many maximum IPC listeners could be implemented if there is a limitation? It would be better if someone could explain the pros and cons of the two methods. Thanks in advance.
As Electron uses Node.js underneath and Electron's IPC is based on Node events, any limits would be imposed by Node and not Electron (unless otherwise defined by electron, which I don't believe it is).
As per the latest Node.js Event documentation, once you have more than 10 listeners per event a warning will be emitted. The thing to note here is "more than 10 listeners per event".
See this Node link for more information: events.defaultMaxListeners
As each ipcMain.on('channelName', () => { ... }) is a listener for, in this example, an event named channelName, you
would need more than quantity 10 of the ipcMain.on('eventName', () => { ... }) methods in your code before a warning
is throw.
As all your ipcMain methods seem to be for different event names, there is no operational benefit between either of
your solutions.
That said, your first solution would be the preferred solution, allowing you to place your individual ipcMain calls
into their "associated files". EG: appLangaugeChange events would be coded within your language scripts whilst
your any patient events would be coded within your patient scripts. This will keep your code seperated, logical,
expandable and simple to debug.
Additionally, as your project grows, a particular section of code can listen for an event emitted by an unrelated section of code, if needed. EG: Submitting some new information on a form may update more than one panel in your main window, or update multiple child-windows, all at the same time.
On the discussion of "performance", if your events were firing every couple of milliseconds then one would want to look at micro-optimisation. But based on the event names, this is not the case, so any solution would work. If anything, it would probably be more based on your preferred coding style.
As a closing note, consider the ipcMain method and its associated Electron methods only as an extension of Node
events. They are not special or magical, but only a simple observer design pattern. This way, you will write better,
more modular code.