← Back to Electron and Vue foundation team

Skill · Version 1.0.0

Electron application engineering

Builds Electron features across isolated processes with narrow, validated communication and predictable native behavior.

electron-development

Team members using this skill

See how it helps

When is it useful?

Use when a desktop feature needs filesystem access or background work from the interface.

What does it help you do?

  • Separates main, renderer and utility-process responsibilities.
  • Exposes typed preload operations rather than unrestricted Node access.
  • Validates incoming messages and handles windows and native dialogs consistently.

Try asking this

Add a file-import dialog through a narrow preload API, validating the request in the main process. Send an unexpected path and an invalid request shape from the renderer. The main process should reject both while allowing the normal native import flow.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Electron Development

Structure Electron applications around a strict separation of responsibilities: Main Process (OS integration, window lifecycle, IPC gatekeeper), Preload Script (minimal contextBridge surface), Renderer (sandboxed web UI), and utilityProcess (CPU-heavy or embedded Node.js server/worker workloads).

Multi-Process Architecture & utilityProcess

Never block the Electron Main process event loop with synchronous filesystem scans, SQLite queries, or embedded HTTP server request handling—blocking Main freezes window dragging, menus, and IPC across the entire app:

// Spawn an embedded Node.js backend or heavy worker via utilityProcess (uses Chromium Services API)
import { utilityProcess, MessageChannelMain } from 'electron';
import path from 'node:path';

const { port1, port2 } = new MessageChannelMain();
const serverProc = utilityProcess.fork(path.join(__dirname, 'server-entry.js'), [], {
  env: { ...process.env, APP_USER_DATA: app.getPath('userData') },
  stdio: 'pipe',
  serviceName: 'local-backend',
});
serverProc.postMessage({ type: 'init' }, [port1]);

Typed contextBridge & Validated ipcMain.handle

  1. Preload (preload.ts):
    • Pass only serializable data and narrow functions across contextBridge.exposeInMainWorld('desktopApi', { ... }).
    • Never pass raw ipcRenderer.on callbacks that leak the IpcRendererEvent object; wrap listeners and return an explicit unsubscribe() function so React/Vue/Angular components can clean up on unmount.
  2. Main Process (ipcMain.handle):
    • Always check event.senderFrame?.origin against the expected app origin before executing privileged operations.
    • Return structured result objects ({ ok: true, data } | { ok: false, code, message }) rather than relying on unhandled Error serialization, which strips custom properties across IPC.

Window State, Native Dialogs & OS Polish

  • Prevent visual flash on launch: Create BrowserWindow with show: false and a matching backgroundColor, then show it inside win.once('ready-to-show', () => win.show()).
  • Persist and validate window bounds: Save { x, y, width, height, isMaximized } on resize/move (debounced), and on startup verify via screen.getDisplayMatching(bounds) that the saved coordinates still intersect an attached monitor (handling unplugged external displays gracefully).
  • Parent-attached native dialogs: Always pass the active BrowserWindow reference as the first argument to dialog.showOpenDialog(win, ...) / dialog.showMessageBox(win, ...) so sheets attach properly on macOS and modal z-order is respected on Windows.
  • Custom protocol & deep links (app.setAsDefaultProtocolClient):
    • On macOS, handle incoming myapp:// URLs via app.on('open-url', (event, url) => ...).
    • On Windows/Linux, extract the URL from process.argv on initial launch and inside app.on('second-instance', (event, commandLine) => ...), validating the URL structure strictly before routing.

Included files 1

  • SKILL.md