Communication IPC entre les processus

ipcMain.handle enregistre un canal nommé dans le processus principal, qui répond aux requêtes du processus de rendu. Il accepte une fonction de traitement asynchrone, et sa valeur de retour devient la valeur résolue de la promesse dans le processus de rendu. Cette méthode convient donc parfaitement aux opérations telles que la lecture de fichiers ou l'interrogation d'une base de données.

ipcRenderer.invoke envoie un message sur un canal nommé et renvoie une promesse qui se résout avec la valeur renvoyée par le gestionnaire du processus principal. Cela crée un modèle asynchrone clair de requête-réponse, qui s'utilise naturellement avec async/await dans le script de préchargement comme dans les composants React.

Le script de préchargement encapsule les appels à ipcRenderer.invoke et les expose via contextBridge. Par exemple : api.readFile = (filePath) => ipcRenderer.invoke('read-file', filePath). Le processus de rendu appelle window.api.readFile(path) et récupère une promesse : l'ensemble reste propre et isolé.

Lorsque contextIsolation est activé, le processus de rendu ne peut pas appeler require('electron') ni importer directement ipcRenderer : le module est tout simplement indisponible. Tout l'IPC doit passer par l'exposition de contextBridge dans le script de préchargement. C'est intentionnel : cela empêche les attaques XSS d'obtenir un accès à l'IPC.

ipcMain.on écoute les messages unidirectionnels envoyés avec ipcRenderer.send, et non avec invoke. Aucun canal de réponse automatique n'est prévu. Ce modèle convient aux notifications ou aux commandes qui ne nécessitent pas de réponse du processus de rendu, par exemple pour journaliser des événements ou déclencher une notification native.

Le processus principal peut envoyer des données au processus de rendu à l'aide de webContents.send('channel-name', data). Il s'agit du principal moyen pour le processus principal d'initier une communication, par exemple pour transmettre des événements de surveillance du système de fichiers ou des actions de menus natifs à l'interface React.

Dans le script de préchargement, ipcRenderer.on('update', callback) enregistre un écouteur pour les messages envoyés par le processus principal. La fonction de rappel reçoit l'événement ainsi que toutes les données envoyées par le processus principal, que vous transmettez ensuite au moteur de rendu par l'intermédiaire de la fonction exposée par contextBridge.

Un modèle clair pour les événements envoyés est le suivant : api.onUpdate = (callback) => ipcRenderer.on('update', (_event, data) => callback(data)). Les composants React s'abonnent en appelant window.api.onUpdate(setData), et la fonction de rappel met à jour l'état lorsque le processus principal envoie de nouvelles données.

Chaque écouteur ipcRenderer.on doit être supprimé lorsqu'il n'est plus nécessaire afin d'éviter les fuites de mémoire et les appels de rappel en double. La fonction du script de préchargement doit renvoyer une fonction de nettoyage (par ex. () => ipcRenderer.removeListener('update', callback)) que React appelle dans la fonction de nettoyage renvoyée par useEffect.

Les données d'entrée IPC provenant du moteur de rendu doivent être considérées comme des données non fiables dans le gestionnaire du processus principal. Validez toujours les chemins de fichiers (pour empêcher les attaques par traversée de chemin), assainissez les paramètres de requête et vérifiez que l'origine de l'émetteur est bien celle attendue. N'exposez jamais un canal IPC générique pour eval ou exec.

À mesure que votre application grandit, organisez les canaux IPC à l'aide de conventions d'espaces de noms : 'fs:read-file', 'db:query', 'window:minimize'. Conservez les noms des canaux dans un fichier de constantes partagé, importé à la fois par main.js et le script de préchargement, afin d'éviter les fautes de frappe et de sécuriser les opérations de restructuration.

Que devient la valeur renvoyée par un gestionnaire ipcMain.handle ?

L'IPC est le pilier central de la communication dans Electron. ipcMain.handle et ipcRenderer.invoke forment une paire requête-réponse fondée sur les promesses pour les opérations lancées par le moteur de rendu. Pour les messages envoyés par le processus principal, webContents.send et ipcRenderer.on fonctionnent ensemble. Tout l'IPC utilisé dans le moteur de rendu doit passer par le contextBridge du script de préchargement, et les écouteurs doivent toujours être supprimés afin d'éviter les fuites de mémoire.