خادوم دردشة محلية كتبته بـNode.js/Express/Socket.IO/React/Redux/Webpack

الرسائل حاليًّا تخزن في الذاكرة فقط، لكنني بدأت العمل على تخزينها ضمن IndexedDB باستخدام redux middleware أكتبه بنفسي (حاليًّا يتم تخزين الرسائل، ولكن لا يتم عرضها عند تحديث الصفحة)، المشكلة هي أن تخزين الرسائل يعني ربط كل رسالة بالخادوم الذي تولى نقلها، ليتم عرضها فقط عند الاتصال بنفس الخادوم مجدّدًا، وهذا يعني أن كل خادوم يجب أن يحتفظ بمعرفه الخاص، ويعني عمل authentication لكل client، وعندها سينتقل الموضوع إلى استخدام قاعدة بيانات، ويزداد تعقيدًا... لكنني أعمل على ذلك، ليس فقط من أجل هذا، بل أيضًا من أجل تخزين الرسائل لإيصالها إلى الأطراف غير المتصلة عند اتصالها مجدّدًا.

يمكنك بسهولة نقله إلى خادوم غير محلي، وهذا ما كنت أفكر بفعله، قم بحذف كل ما يتعلق بـBounjour.

شكرًا جزيلًا :)

الرسائل حاليًا تخزن في الذاكرة، وتكرر نسخة منها وتحفظ في IndexedDB باستخدام redux middleware، لكنها لا تعرض مجدّدًا عند تحديث الصفحة، انظر ردي على @assassinateur

أونلاين يعني أن socket متصلة فقط، عند انقطاعها يبث الخادم حدثًا لكل الأطراف المتصلة بأن الطرف الفلاني قد أصبح offline، لتنعكس هذه التغييرات في الواجهة.

socket وحيدة لكل عميل تتولى الدردشة مع كل الأطراف، وsocket أخرى تتولى البحث عن الخواديم المحلية باستخدام bonjour وإيصالها للمتصفح.

أنا أعمل على مشروع مشابه لهذا لكنه موجه ل "أدمن" المواقع. يمكن للزائر مراسلة "الادمن" عبر الشات، الاضافة في مشروعي أن "الادمن" يمكنه الرد و استقبال الرسائل عبر تطبيق الواتساب.

• أضنه يخزن الرسائل في ملفات متفرقة، لكل محادثة ملفها الخاص.

• مفهوم الاونلاين أضنه يقصد بها حالة صاحب المحادثة : هل مازال يستقبل الرسائل أم أنه ترك رسالة وغادر.

بالتوفيق

هذه تعتمد على localStorage API وهي واجهة blocking أي أنها تعيق أي عمل في صفحة الويب (حتى النقر على الأزرار)، ليست مناسبة، كون الرسائل ستصل بفواصل لحظات. ليست المشكلة بالتخزين ذاته، وإنما بما يتعلق به من تعقيدات، راجع ردودي أعلاه.

ابدأ أوّلا بتعلم JavaScript على Codecademy.

ثمّ ضع لنفسك مشروعًا تريد إنجازه بالكامل. افعل كل ما بوسعك لإنجاز هذا المشروع، ابحث عن كل مشكلة تواجهك، واقرأ مقالات وشاهد مقاطع فيديو، تابع تطوّرات أشهر مطوري الويب على Twitter.

React ليست إطار عمل، وهي فكرة يكررها كثيرًا أنصارها والعاملون على تطويرها، React مسؤولة فقط عن عرض العناصر في الصفحة. ما زلت تحتاج إلى طريقة لإدارة المعلومات في الصفحة، هناك أساليب مختلفة ذلك، لكن مطوّري React ينصحون باعتماد بنية Flux، أو انسياب البيانات باتجاه واحد. معنى ذلك أن المُكوّنات غير مرتبطة ببعضها، ولا تقوم بتعديل البيانات مباشرة، بل تستقي البيانات من مصدر أعلى منها، وإذا أرادت تعديل البيانات فهي تُرسل "حدثًا action" يصف التغيير المطلوب إلى "مستودع store" من مستودعات البيانات. يقوم المستودع بتعديل البيانات بالشكل المطلوب، ثمّ تُعيد React رسم كل المُكوّنات المُعتمدة على الجزء المتغيّر من البيانات. فائدة ذلك هو أنّ المُكوّنات لا تحتاج إلى أن تعلم إن كانت مكوّنات أخرى في الصّفحة تعتمد على البيانات الّتي تعدّلها، بل فقط تهتمّ بنفسها وتعبّر عن رغبتها بتعديل البيانات في المصدر الأعلى، وهذا يؤدّي إلى تدفّق "flow" البيانات من أعلى إلى أسفل فقط، وليس باتّجاهين (two-way data binding) أي بين المكوّنات نفسها كما في Angular.

Redux تذهب أبعد من ذلك، وقد أصبحت المعيار الذّهبي لبنية Flux، لأنّها تقوم بإنشاء مستودع وحيد يحتوي كلّ بيانات التطبيق، وتقوم المكوّنات بإرسال حدث التّغيير إلى هذا المستودع الّذي يقوم عندها استدعاء وظيفة تستقبل النسخة السابقة من المستودع، وتُعيد نسخة جديدة، وهكذا في كلّ تغيير. معنى ذلك أنّ وظيفة التّغيير (التي تُسمى reducer) هي وظيفة صافية (pure function) لا تعلم شيئًا عن برنامجك، بل فقط تأخذ الحالة السابقة والحدث الحالي، وتُعيد حالة جديدة.

بساطة هذه البنية هي نقطة القوة في Redux، وهي التي تسمح لتطبيقك بأن يكون قابلًا للاختبار بسهولة (unit tests)، كون المكوّنات تستقي البيانات من مصدر أعلى، وتعبّر فقط عن رغبتها بتعديلها، ولا تقوم بتعديلها مباشرة، وهذا يجعل كل مكوّن قابلًا للاختبار بصورة منفصلة، كما أنّه يسهل اختبار وظيفة reducer، لأنّها لا تعلم شيئًا عن التطبيق، بل تحتاج فقط الحدث والحالة الحالية، لتعطيك حالة جديدة.

هناك دورتان لـDan Abramov كاتب Redux، متوفّرتان مجانًا على Egghead.io، أنصح بهما بشدّة: