Prosessien välinen IPC-viestintä

ipcMain.handle rekisteröi pääprosessiin nimetyn kanavan, joka vastaa renderöintiprosessin pyyntöihin. Se vastaanottaa asynkronisen käsittelijäfunktion, ja sen palautusarvosta tulee renderöintiprosessin Promisen ratkaistu arvo. Tämä sopii erinomaisesti esimerkiksi tiedostojen lukemiseen tai tietokannan kyselyihin.

ipcRenderer.invoke lähettää viestin nimetyn kanavan kautta ja palauttaa Promisen, joka ratkaistaan pääprosessin käsittelijän palautusarvolla. Näin muodostuu selkeä asynkroninen pyyntö–vastausmalli, joka toimii luontevasti async/await-syntaksin kanssa sekä preload-skriptissä että React-komponenteissa.

Preload-skripti kääräisee ipcRenderer.invoke-kutsut ja tarjoaa ne contextBridgen kautta. Esimerkiksi: api.readFile = (filePath) => ipcRenderer.invoke('read-file', filePath). Renderöintiprosessi kutsuu window.api.readFile(path)-funktiota ja saa takaisin Promisen — ratkaisu on selkeä ja hiekkalaatikoitu.

Kun contextIsolation on käytössä, renderöintiprosessi ei voi suorittaa require('electron')-kutsua tai tuoda ipcRendereria suoraan import-lauseella, koska moduuli ei ole siellä käytettävissä. Kaiken IPC-viestinnän on kuljettava preload-skriptin contextBridge-julkaisun kautta. Tämä on tarkoituksellista: se estää XSS-hyökkäyksiä saamasta käyttöoikeutta IPC-viestintään.

ipcMain.on kuuntelee yksisuuntaisia viestejä, jotka lähetetään ipcRenderer.send-kutsulla, ei invoke-kutsulla. Automaattista vastauskanavaa ei ole. Tämä malli sopii ilmoituksiin tai komentoihin, joihin renderöintiprosessi ei tarvitse vastausta, kuten tapahtumien kirjaamiseen tai natiivin ilmoituksen käynnistämiseen.

Pääprosessi voi lähettää tietoja renderöintiprosessiin kutsulla webContents.send('channel-name', data). Tämä on ensisijainen tapa, jolla pääprosessi aloittaa viestinnän, esimerkiksi välittäessään tiedostojärjestelmän tarkkailutapahtumia tai natiivivalikon toimintoja React-käyttöliittymään.

Preload-skriptissä ipcRenderer.on('update', callback) rekisteröi kuuntelijan pääprosessista tuleville push-viesteille. Callback saa parametrikseen tapahtuman ja kaikki pääprosessin lähettämät tiedot, jotka välität sitten renderer-prosessille contextBridgen kautta käyttöön asetetulla funktiolla.

Push-tapahtumille sopiva selkeä malli on seuraava: api.onUpdate = (callback) => ipcRenderer.on('update', (_event, data) => callback(data)). React-komponentit tilavaat muutoksia kutsumalla window.api.onUpdate(setData), ja callback päivittää tilan, kun pääprosessi lähettää uusia tietoja.

Jokainen ipcRenderer.on-kuuntelija tulee poistaa, kun sitä ei enää tarvita, jotta muistivuodot ja päällekkäiset callback-kutsut vältetään. Preload-funktion tulee palauttaa puhdistusfunktio (esimerkiksi () => ipcRenderer.removeListener('update', callback)), jonka React kutsuu useEffectin puhdistusfunktion palautusarvon kautta.

Renderer-prosessista tulevia IPC-syötteitä tulee käsitellä epäluotettavina tietoina pääprosessin käsittelijässä. Validoikaa tiedostopolut aina (estääkää path traversal -hyökkäykset), puhdistakaa kyselyparametrit ja tarkistakaa, että lähettäjän origin on odotettu. Älkää koskaan julkaisko yleiskäyttöistä eval- tai exec-IPC-kanavaa.

Sovelluksen kasvaessa järjestäkää IPC-kanavat namespacing-käytännöillä, kuten 'fs:read-file', 'db:query' ja 'window:minimize'. Säilyttäkää kanavien nimet jaetussa vakiotiedostossa, jonka sekä main.js että preload-skripti tuovat käyttöön. Näin kirjoitusvirheet voidaan estää ja uudelleenkäsittely on turvallisempaa.

IPC on Electron-sovellusten välisen viestinnän selkäranka. ipcMain.handle ja ipcRenderer.invoke muodostavat Promise-pohjaisen pyyntö–vastausparin renderer-prosessin käynnistämille toiminnoille. Pääprosessin käynnistämissä push-viesteissä webContents.send ja ipcRenderer.on toimivat yhdessä. Kaikki renderer-prosessin IPC-liikenne tulee reitittää preload-skriptin contextBridgen kautta, ja kuuntelijat tulee aina poistaa muistivuotojen estämiseksi.