Comunicazione IPC tra processi

ipcMain.handle registra un canale denominato nel processo principale che risponde alle richieste del renderer. Accetta una funzione gestore asincrona e il suo valore restituito diventa il valore risolto della Promise nel renderer, rendendolo ideale per operazioni come la lettura di file o le query a un database.

ipcRenderer.invoke invia un messaggio su un canale denominato e restituisce una Promise che si risolve con il valore restituito dal gestore del processo principale. In questo modo si crea un pattern asincrono chiaro di richiesta-risposta, che funziona naturalmente con async/await sia nello script di preload sia nei componenti React.

Lo script di preload racchiude le chiamate a ipcRenderer.invoke e le espone tramite contextBridge. Ad esempio: api.readFile = (filePath) => ipcRenderer.invoke('read-file', filePath). Il renderer chiama window.api.readFile(path) e riceve una Promise: un'interfaccia chiara e sottoposta a sandbox.

Con contextIsolation abilitato, il processo renderer non può eseguire require('electron') né importare direttamente ipcRenderer: il modulo non è semplicemente disponibile. Tutte le comunicazioni IPC devono passare dall'esposizione tramite contextBridge dello script di preload. È una scelta intenzionale: impedisce agli attacchi XSS di ottenere accesso a IPC.

ipcMain.on ascolta i messaggi unidirezionali inviati con ipcRenderer.send (non invoke). Non esiste un canale di risposta automatico: questo pattern è adatto per notifiche o comandi per i quali il renderer non necessita di una risposta, come registrare eventi o attivare una notifica nativa.

Il processo principale può inviare dati al renderer utilizzando webContents.send('channel-name', data). Questo è il metodo principale con cui il processo principale avvia la comunicazione, ad esempio per inoltrare eventi di monitoraggio del file system o azioni dei menu nativi all'interfaccia React.

Nello script di preload, ipcRenderer.on('update', callback) registra un listener per i messaggi push provenienti dal processo principale. Il callback riceve l'evento e tutti i dati inviati dal processo principale, che poi inoltra al renderer tramite la funzione esposta da contextBridge.

Un pattern pulito per gli eventi push è il seguente: api.onUpdate = (callback) => ipcRenderer.on('update', (_event, data) => callback(data)). I componenti React si iscrivono chiamando window.api.onUpdate(setData), e il callback aggiorna lo stato quando il processo principale invia nuovi dati.

Ogni listener ipcRenderer.on deve essere rimosso quando non è più necessario, per evitare perdite di memoria e callback duplicati. La funzione di preload dovrebbe restituire una funzione di pulizia (ad es., () => ipcRenderer.removeListener('update', callback)) che React richiama nel return di pulizia di useEffect.

Gli input IPC provenienti dal renderer devono essere trattati come dati non attendibili nel gestore del processo principale. Convalidi sempre i percorsi dei file (per prevenire gli attacchi di path traversal), sanifichi i parametri delle query e verifichi che l'origine del mittente sia quella prevista. Non esponga mai un canale IPC generico per eval o exec.

Man mano che l'app cresce, organizzi i canali IPC usando convenzioni di denominazione con namespace: 'fs:read-file', 'db:query', 'window:minimize'. Mantenga i nomi dei canali in un file di costanti condiviso, importato sia da main.js sia dallo script di preload, per evitare errori di battitura e rendere più sicuro il refactoring.

Che cosa accade al valore restituito da un gestore ipcMain.handle?

IPC è la dorsale della comunicazione in Electron. ipcMain.handle e ipcRenderer.invoke formano una coppia richiesta-risposta basata su Promise per le operazioni avviate dal renderer. Per gli eventi push avviati dal processo principale, webContents.send e ipcRenderer.on lavorano insieme. Tutte le comunicazioni IPC nel renderer devono passare attraverso il contextBridge del preload e i listener devono essere sempre rimossi per evitare perdite di memoria.