Связь между процессами через IPC

ipcMain.handle регистрирует именованный канал в главном процессе, который отвечает на запросы процесса визуализации. Он принимает асинхронную функцию-обработчик, а её возвращаемое значение становится значением разрешившегося обещания в процессе визуализации, поэтому этот механизм хорошо подходит для таких операций, как чтение файлов или запросы к базе данных.

ipcRenderer.invoke отправляет сообщение по именованному каналу и возвращает обещание, которое разрешается возвращаемым значением обработчика главного процесса. Так создаётся простой асинхронный шаблон запроса и ответа, естественно работающий с async/await как в скрипте предварительной загрузки, так и в компонентах React.

Скрипт предварительной загрузки оборачивает вызовы ipcRenderer.invoke и предоставляет их через contextBridge. Например: api.readFile = (filePath) => ipcRenderer.invoke('read-file', filePath). Процесс визуализации вызывает window.api.readFile(path) и получает обещание — всё просто и безопасно в песочнице.

При включённом contextIsolation процесс визуализации не может выполнить require('electron') или напрямую импортировать ipcRenderer — этот модуль просто недоступен. Весь обмен через IPC должен проходить через предоставленный скриптом предварительной загрузки интерфейс contextBridge. Это сделано намеренно: такой подход не позволяет XSS-атакам получить доступ к IPC.

ipcMain.on прослушивает односторонние сообщения, отправленные с помощью ipcRenderer.send (а не invoke). Автоматического канала ответа нет, поэтому этот подход подходит для уведомлений или команд, на которые процессу визуализации не нужен ответ, например для регистрации событий или запуска нативного уведомления.

Главный процесс может передавать данные процессу визуализации с помощью webContents.send('channel-name', data). Это основной способ, с помощью которого главный процесс инициирует взаимодействие, например пересылает события наблюдения за файловой системой или действия нативного меню интерфейсу React.

В скрипте предварительной загрузки ipcRenderer.on('update', callback) регистрирует слушатель сообщений, отправляемых главным процессом. Обратный вызов получает событие и все данные, отправленные главным процессом, после чего Вы передаёте их визуализатору через функцию, предоставленную contextBridge.

Удобный шаблон для событий, отправляемых главным процессом: api.onUpdate = (callback) => ipcRenderer.on('update', (_event, data) => callback(data)). Компоненты React подписываются вызовом window.api.onUpdate(setData), а обратный вызов обновляет состояние, когда главный процесс отправляет новые данные.

Каждый слушатель, зарегистрированный через ipcRenderer.on, необходимо удалить, когда он больше не нужен, чтобы предотвратить утечки памяти и повторные вызовы. Функция предварительной загрузки должна возвращать функцию очистки, например () => ipcRenderer.removeListener('update', callback), которую React вызывает из функции очистки useEffect.

Входные данные IPC от визуализатора следует считать недоверенными данными в обработчике главного процесса. Всегда проверяйте пути к файлам, предотвращая атаки обхода путей, очищайте параметры запросов и проверяйте, что источник отправителя является ожидаемым. Никогда не предоставляйте универсальный IPC-канал для eval или exec.

По мере роста приложения организуйте каналы IPC с помощью соглашений об именовании: 'fs:read-file', 'db:query', 'window:minimize'. Храните имена каналов в общем файле констант, который импортируют и main.js, и скрипт предварительной загрузки, чтобы предотвращать опечатки и сделать реорганизацию кода безопаснее.

IPC — основа обмена данными в Electron. ipcMain.handle и ipcRenderer.invoke образуют пару запрос–ответ на основе Promise для операций, инициированных визуализатором. Для отправки данных главным процессом webContents.send и ipcRenderer.on работают вместе. Все операции IPC в визуализаторе должны проходить через contextBridge скрипта предварительной загрузки, а слушатели следует всегда удалять, чтобы предотвратить утечки памяти.