الاتصال بين العمليات باستخدام IPC

تسجّل ipcMain.handle قناة مسماة في العملية الرئيسية تستجيب للطلبات الواردة من عملية العرض. وتقبل دالة معالج غير متزامنة، وتصبح قيمة إرجاعها القيمة التي تُحل إليها Promise في عملية العرض، مما يجعلها مناسبة لعمليات مثل قراءة الملفات أو الاستعلام من قاعدة بيانات.

ترسل ipcRenderer.invoke رسالة عبر قناة مسماة وتعيد Promise تُحل بقيمة الإرجاع من معالج العملية الرئيسية. وينشئ ذلك نمط طلب واستجابة غير متزامن وواضحًا، ويعمل بصورة طبيعية مع async/await في كل من سكريبت preload ومكوّنات React.

يغلّف سكريبت preload استدعاءات ipcRenderer.invoke ويتيحها من خلال contextBridge. مثلًا: api.readFile = (filePath) => ipcRenderer.invoke('read-file', filePath). تستدعي عملية العرض window.api.readFile(path) وتحصل على Promise في المقابل؛ وهي واجهة واضحة ومعزولة.

عند تفعيل contextIsolation، لا تستطيع عملية العرض استخدام require('electron') أو استيراد ipcRenderer مباشرةً؛ فالوحدة غير متاحة لها ببساطة. ويجب أن تمر جميع اتصالات IPC عبر إتاحة contextBridge في سكريبت preload. وهذا مقصود لمنع هجمات XSS من الحصول على وصول إلى IPC.

تستمع ipcMain.on إلى الرسائل أحادية الاتجاه المُرسلة باستخدام ipcRenderer.send (وليس invoke). ولا توجد قناة استجابة تلقائية؛ ويناسب هذا النمط الإشعارات أو الأوامر التي لا تحتاج فيها عملية العرض إلى رد، مثل تسجيل الأحداث أو تشغيل إشعار أصلي.

يمكن للعملية الرئيسية دفع البيانات إلى عملية العرض باستخدام webContents.send('channel-name', data). وهذه هي الطريقة الأساسية التي تبدأ بها العملية الرئيسية الاتصال؛ فمثلًا يمكنها تمرير أحداث مراقبة نظام الملفات أو إجراءات القوائم الأصلية إلى واجهة React.

في البرنامج النصي للتهيئة المسبقة، تسجّل ipcRenderer.on('update', callback) مستمعًا لرسائل push الواردة من العملية الرئيسية. ويتلقى callback الحدث وأي بيانات أرسلتها العملية الرئيسية، ثم تمررها إلى renderer عبر الدالة التي يتيحها contextBridge.

من الأنماط النظيفة للتعامل مع أحداث push أن تكتب: api.onUpdate = (callback) => ipcRenderer.on('update', (_event, data) => callback(data)). وتشترك مكونات React باستدعاء window.api.onUpdate(setData)، ثم يحدّث callback الحالة عند دفع العملية الرئيسية لبيانات جديدة.

يجب إزالة كل مستمع يسجله ipcRenderer.on عند عدم الحاجة إليه، منعًا لتسرّبات الذاكرة واستدعاءات callback المكررة. ويجب أن تعيد دالة التهيئة المسبقة دالة تنظيف، مثل () => ipcRenderer.removeListener('update', callback)، تستدعيها React من دالة التنظيف التي تُعاد من useEffect.

يجب التعامل مع مدخلات IPC القادمة من renderer على أنها بيانات غير موثوقة داخل معالج العملية الرئيسية. تحقّق دائمًا من مسارات الملفات لمنع هجمات اجتياز المسار، ونقِّ معلمات الاستعلام، وتحقّق من أن أصل المرسل متوقَّع. لا تتيح مطلقًا قناة IPC عامة لـ eval أو exec.

مع نمو تطبيقك، نظّم قنوات IPC باستخدام اصطلاحات لتسمية النطاقات، مثل: 'fs:read-file' و'db:query' و'window:minimize'. احتفظ بأسماء القنوات في ملف ثوابت مشترك يستورده كل من main.js والبرنامج النصي للتهيئة المسبقة، لتجنّب الأخطاء المطبعية وجعل إعادة الهيكلة أكثر أمانًا.

ماذا يحدث للقيمة التي يعيدها معالج ipcMain.handle؟

يُعد IPC العمود الفقري للتواصل في Electron. يشكّل كل من ipcMain.handle وipcRenderer.invoke زوجًا قائمًا على Promise لتنفيذ عمليات بدأها renderer وإرجاع استجابات لها. أما عمليات الدفع التي تبدأها العملية الرئيسية، فيتعاون فيها webContents.send مع ipcRenderer.on. ويجب تمرير كل اتصالات IPC في renderer عبر contextBridge في البرنامج النصي للتهيئة المسبقة، كما ينبغي تنظيف المستمعين دائمًا لمنع تسرّبات الذاكرة.