Tengo muchos oyentes de IPC ( más de 30 ) en mi aplicación de electrones, pero me pregunto cuál es mejor en términos de rendimiento.
La primera solución (Implementar el oyente IPC tantos como sea necesario):
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..La segunda solución (usando Switch y solo implementando un oyente IPC):
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.. })Actualmente, estoy usando la segunda solución, ¿es un buen enfoque? Porque soy consciente de que algunas personas podrían recibir una advertencia de que demasiados oyentes de IPC ya han implementado. ¿Cuántos oyentes máximos de IPC podrían implementarse si hay una limitación? Sería mejor si alguien pudiera explicar los pros y los contras de los dos métodos. Gracias por adelantado.
Como Electron usa Node.js debajo y el IPC de Electron se basa en eventos de Node, Node impondría cualquier límite y no Electron (a menos que electron defina lo contrario, lo cual no creo).
Según la última documentación de eventos de Node.js, una vez que tenga más de 10 oyentes por evento, se emitirá una advertencia. Lo que hay que tener en cuenta aquí es "más de 10 oyentes por evento ".
Consulte este enlace de nodo para obtener más información: events.defaultMaxListeners
Como cada ipcMain.on('channelName', () => { ... }) es un oyente para, en este ejemplo, un evento llamado channelName , necesitaría más de la cantidad 10 de ipcMain.on('eventName', () => { ... }) métodos en su código antes de que se arroje una advertencia.
Como todos sus métodos ipcMain parecen ser para diferentes nombres de eventos, no hay ningún beneficio operativo entre ninguna de sus soluciones.
Dicho esto, su primera solución sería la solución preferida, permitiéndole colocar sus llamadas ipcMain individuales en sus "archivos asociados". Por ejemplo: los eventos appLangaugeChange se codificarían dentro de los scripts de su language , mientras que los eventos de sus patient se codificarían dentro de los scripts de sus patient . Esto mantendrá su código separado, lógico, ampliable y fácil de depurar.
Además, a medida que su proyecto crece, una sección de código en particular puede escuchar un evento emitido por una sección de código no relacionada, si es necesario. EG: Enviar alguna información nueva en un formulario puede actualizar más de un panel en su ventana principal, o actualizar varias ventanas secundarias, todo al mismo tiempo.
En la discusión sobre el "rendimiento", si sus eventos se dispararan cada par de milisegundos, entonces uno querría ver la microoptimización. Pero según los nombres de los eventos, este no es el caso, por lo que cualquier solución funcionaría. En todo caso, probablemente se basaría más en su estilo de codificación preferido.
Como nota final, considere el método ipcMain y sus métodos Electron asociados solo como una extensión de los eventos Node. No son especiales ni mágicos, sino solo un patrón de diseño de observador simple. De esta manera, escribirá código mejor y más modular.