كيفية بناء في نهاية المطاف قابلة لإعادة الاستخدام مكون الدردشة على شبكة الإنترنت

ربما تكون قد قرأت بالفعل الكثير من الإرشادات وكيفية عدم إجراء محادثات الويب. أقصد ، نحن نتحدث دائمًا عن الأيام البعيدة (خارج ساعات العمل الرسمية ، بالطبع) ، لذلك فهو موضوع شائع جدًا. لكن إليكم سؤالي: كم مرة يمكنك تطبيق تطبيق الدردشة دون نسخ / لصق ، وبأي سرعة؟ وماذا لو كنت تستطيع إنشاء مجموعة كاملة من هذه التطبيقات مع المكون النهائي؟

استغرق هذا التنفيذ تسعة أشهر. والكثير من الحظ للحصول عليه بالضبط نفس الشيء! المصدر: funtube

إذن هذا هو الشيء: ماذا لو استطعت إنشاء مكون محادثة عبر الإنترنت يمكنك إعادة استخدامه عدة مرات كما تريد ، وهذا مستقل عن سيناريوهات معينة ، ويمكنك الاندماج في أي تطبيق مع بعض التكوينات المختلفة فقط؟ هل هذا حلم؟ لا ، ليس على الإطلاق. دعونا نرى كيفية تحقيق ذلك.

أسهل بكثير ، أليس كذلك؟ المصدر: tugimnasiacerebral

مرحلة البحث: متطلبات الجمع

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

لكن أول الأشياء أولا. ماذا نتوقع عندما نفتح نسخة الويب لتطبيق الدردشة؟

  • الشكل والمظهر المتكرران: يجب أن تبدو إصدارات الويب والهاتف المحمول (تقريبًا) كما هي. تريد الاتساق.
  • الحاجة إلى السرعة: فكر في التحميل السريع وإرسال الملفات بسرعة وردود الفعل السريعة على المدخلات الخاصة بك.
  • المتانة أمر لا بد منه: يجب أن يكون تطبيق الدردشة قويًا. هذا متوقع نظرًا لكونه إصدار ويب ، فإن الاتصال موجود دائمًا ، والأرجح أنه اتصال جيد أيضًا.

مع وضع هذه المتطلبات في الاعتبار ، يمكنك البدء في التفكير في التجربة. إليك ما برز فيما يتعلق بالسلوكيات.

محادثة جديدة

هذا سهل: للدردشة مع شخص ما ، تبدأ الكتابة.

السلوك الأكثر شيوعًا في محادثة جديدة هو إخفاء المرفق (أو الخيارات الأخرى المتاحة) وإظهار الزر إرسال. نظرًا لأنه تطبيق ويب ، فإن مفتاح Enter متاح دائمًا ويجب أن يرسل الرسالة دائمًا ، ولكن التلميح المرئي عن متى يمكنك إرسال الرسالة أصبح هو الافتراضي.

بدء محادثة.

الرسائل المستلمة

صحيح ، إذن ماذا يحدث عندما تتلقى أكثر من رسالة واحدة؟ تحتاج إلى تلميح للإشارة إلى تلك غير المقروءة. من بين الطرق المختلفة التي رأيتها ، الأكثر استخدامًا هو فاصل (عادة ما يكون خطًا ملونًا) بين الرسائل التي قرأتها بالفعل وتلك التي لم تقرأها. ولكن عند قراءة الرسائل ، تتلاشى بعض الفواصل بعد ثوانٍ قليلة من فتح المحادثة ، والبعض الآخر عندما تركز على المدخلات ، والبعض الآخر فقط عند الرد.

طرق مختلفة لإظهار الرسائل غير المقروءة الجديدة.

مرفقات

تتغير تجربة إرسال واستقبال الملفات من التطبيق إلى التطبيق. لكننا نتوقع جميعًا على الأقل معرفة ما يتم إرساله ، بغض النظر عن اسم الملف. نميل إلى التعرف على نوع الملف من خلال الرمز الخاص به وليس باسمه أو امتداده ، لذلك عند نقل الملفات أو التمثيل المرئي أو الرمز. يود معظمنا أيضًا معاينة هذه الملفات ، ولكن لا تدعم جميع التطبيقات ذلك. الملفات الأكثر شيوعًا التي يمكن معاينتها هي ملفات PDF وملفات مستندات Office والصور ومقاطع الفيديو. التنسيقات الأخرى تتطلب عادة تنزيل.

وعندما يتعلق الأمر بتحميل ملف ، لا تسمح بعض التطبيقات بالتحميلات إلا إذا كانت منفصلة عن الرسائل ، بينما يسمح البعض الآخر بالعناوين والتعليقات المرفقة بالملف الذي تم تحميله. بغض النظر عن امتلاك عنوان أم لا ، أثناء التحميل ، يكون تمثيل نوع الملف زائدًا.

التعامل مع المرفقات.

كما ترون ، هناك الكثير مما يجب مراعاته فيما يتعلق بتجربة المستخدم. يتعلق الأمر في النهاية بالتجربة التي ترغب في تقديمها للمستخدمين. هناك بعض التفاعلات الافتراضية ، لذلك ، فإن إبقاء المستخدمين سعداء بالوفاء بتوقعاتهم يعد دائمًا خيارًا آمنًا. ولكن ، إذا كنت تشعر بأنك مبتكر ، أو مصمم إعلانات ، أو رائد ... حسنًا ، عليك فقط تنفيذ الحل الذي تعتقد أنه الأفضل. ضع في اعتبارك أن بعض الخيارات قد يكون تنفيذها أسهل من غيرها ، لذلك ضع ذلك في الاعتبار أيضًا.

البحوث يسلم النتائج

ثم جمعت ملاحظاتي (لم يعد زملائي يشعرون برهبة الدردشات المزيفة لدينا) ، واتخذت بعض القرارات عن علم بشأن واجهة مستخدم الدردشة الخاصة بي:

  • يتم سرد المحادثات عموديا.
  • صورة المستخدم مستديرة ويفصل قليلاً عن الرسالة نفسها.
  • يتم عرض الرسائل داخل صندوق "بالون".
  • يتم محاذاة رسائل المستخدم إلى اليمين ، بينما يتم عرض الرسائل المستلمة على اليسار.
  • بالنسبة للرسائل الجديدة ، ذهبت مع الخط الفاصل.
  • الصور ومقاطع الفيديو ومقاطع الفيديو لها معاينة مضمنة.
  • أنواع الملفات الأخرى لها تمثيل مشترك (بدون التعرف على نوع الملف).

بدون مزيد من اللغط ، إليك النتيجة:

رسالة ترحيب قابلة للتخصيص على القمة. مجمعة حسب اليوم وفصل جذاب لتحديد الرسائل غير المقروءة.

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

تنفيذ إعادة الاستخدام

ما عليك سوى إنشاء مكون يمكن إعادة استخدامه مرة واحدة ، ولكن يمكنك استخدامه عدة مرات كما تريد. لذا ، فأنت تقوم ببناء كائن سيتم الرجوع إليه لاحقًا بواسطة أي عدد من التطبيقات ، ولكل منها حالات استخدام خاصة بها ومواصفاتها وإعداداتها. لجعل هذا ممكنًا ، تحتاج إلى وظائف API حتى تتمكن من ضبط التكوينات الصحيحة وتشغيل هذا الطفل. لكن قبل ذلك ، هناك بعض الأعمال الأخرى التي يجب القيام بها.

إنشاء نموذج البيانات

يتيح لنا تطبيق نموذج البيانات الحصول على معرّف فريد نستخدمه في كيان ملحق ، مما يتيح استخدام محادثة محددة لكل سجل.

أنا أوافق؟ المصدر: memegenerator

تخيل ، على سبيل المثال ، متجر على الإنترنت. في هذه الحالة ، يمكن ربط معرف فريد بمنتج معين ، أو يمكن أن يرتبط بالمستخدم الذي تم تسجيل دخوله حاليًا ، للحفاظ على تمكين الدردشة في جميع أنحاء الموقع بأكمله. لذلك ، على جانب التطبيق ، ما عليك سوى إنشاء معرف مرة واحدة لكل "عنصر" مرتبط.

دعنا نسمي هذا الكيان الموضوع. سنحتاج إلى توفير وظيفة في المكون الخاص بنا تسمح بإنشاء عنصر موضوع جديد وإرجاع معرفه ، والذي نسميه SubjectId. (المزيد حول هذا لاحقًا.)

الآن ، لدينا محادثة فريدة من نوعها. رائع ، أليس كذلك؟

المنتج (المعرف ، الوصف ، EAN ، ...) + الموضوع (المعرف ، الاسم ، ...) = Product_Subject (Product.Id ، Subject.Id)

حفظ المحادثات

لحفظ المحادثات ، سنقوم بإنشاء كيان نشر. يشمل هذا الكيان:

  • الرسالة نفسها: "رسالة" (نص)
  • معلومات المرسل: "النشر" (UserId)
  • عندما تم إرسال الرسالة: "تاريخ النشر" (DateTime)
  • الموضوع الذي ينتمي إليه: "SubjectId" (SubjectId)

للحصول على فاصل أنيق للعمل ، نحتاج إلى تتبع آخر رسالة قراءة. إليك ما سنفعله: LastSeenPost (SubjectId ، PostId ، UserId).

دعونا نلقي نظرة فاحصة على هذا. لإظهار المستخدم الرسالة التي كانت آخر قراءة ، يجب أن نعرف الموضوع الذي ينتمي إليه. ونعم ، لقد خمنت ذلك ، هذا هو الموضوع. نحن بحاجة إلى معرفة الرسالة التي هي ، وهذا يعني PostId. وأي مستخدم ينتمي إليه ، هذا هو UserId. مع كل هذه المعلومات ، تكون الحيلة هي تحديث هذا الإدخال عندما نرسل رسالة.

التعامل مع المرفقات

لتخزين الملفات ، نقوم بإنشاء كيان المرفق. الآن ، لأننا نريد أن تظهر المحادثة على نحو سلس قدر الإمكان ، لا نقوم بتخزين البيانات الثنائية للملفات في كيان المرفق هذا ، ولكن في ملف منفصل يسمى File.

أثناء تحميل الرسائل ، نقوم باسترداد معلومات الموضوع وصولاً إلى مستوى المرفقات ، لكننا نجلب الملف نفسه في وقت مختلف. وإلا ، فإن استجابة طلبنا ستُرجع كل محتوى البيانات الثنائية لكل ملف ، وقد يستغرق ذلك وقتًا طويلاً لتحميل مستخدمي الدردشة وإحباطهم.

لذلك ، كيان المرفق هو:

PostId (PostId) ، اسم ملف (نص) ، Filetype (نص) ، UploadedOn (DateTime).

وكيان الملف هو:

AttachmentId (AttachmentId) ، ملف (BinaryData).

والنتيجة هي نموذج البيانات هذا:

نموذج البيانات لدينا.

وقت الترميز

الآن وبعد أن أصبح لدينا نموذج البيانات الخاص بنا ، فقد حان وقت الترميز! دعنا نربط بعض النقاط.

إرسال رسالة أمر أساسي للغاية. عندما ينقر المستخدم فوق الزر إرسال أو مفتاح Enter ، كل ما نحتاج إليه هو حفظ كيان النشر في قاعدة البيانات. إرسال الملفات هو نفسه ، لكن كيان المرفقات يحتاج إلى PostId ، لذلك نحن بحاجة إلى إنشاء إدخال نشر فارغ أولاً.

هنا ، اسمحوا لي أن أريك ما يبدو.

(إخلاء المسئولية: الكود الذي أنت على وشك الاستمتاع به هو رمز زائف. ينصح القراء بعدم استخدام هذا الرمز.)

يسمى هذا الإجراء عندما نقر على زر إرسال تحدثنا عنه من قبل.

وبالمثل ، فإن إرسال ملف يكون مثل هذا:

أتذكر عندما قلت أننا سوف نقوم بتحديث هذا الكيان LastSeenPost؟ حسنًا ، لقد أرسلنا للتو رسالة أو ملفًا ، لذا ، فقد حان الوقت الآن.

إليك الكود:

يمكننا الآن إرسال الرسائل والملفات أثناء تحديث آخر رسالة قراءة.

زر الإرسال يعمل! مدهش!

كل هذا جميل حقًا ، لكن هل هو في الوقت الفعلي؟ إنه على وشك أن يكون!

تمكين الاتصال في الوقت الحقيقي

أثناء قيامنا ببناء مكون للدردشة ، قام شخص آخر ببناء مكون يتيح الاتصال في الوقت الفعلي (شكرًا ، شخص عشوائي). لذلك ، ذهبت مع Firebase ، لأن إعداده سريع والتكامل سهل. يأتي Firebase مع "المخطر" و "المستمع". عند إرسال رسائل جديدة ، فإننا نطلق المخطر ، وسيقول المستمع "للمكون ما يجب فعله ؛ على سبيل المثال ، قم بتحديث قائمة الرسائل.

الاتصال بأي تطبيق

لذلك ، دعونا نلخص. تحدثنا عن نموذج البيانات والإجراءات والوقت الحقيقي. لا يوجد سوى شيء واحد مفقود: كيفية الحصول على هذا المعرف الفريد الذي من المفترض أن نحفظه على جانب التطبيق. أنت تعرف ، هذا الموضوع.

تذكر عندما قلت أنه يجب عليك تمديد كيان لربط هذا الموضوع بـ "العنصر الخاص بك"؟ وهل تتذكر أن المنشور يحتاج إلى معرفة الموضوع الذي ينتمي إليه؟

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

لجعل هذا المعرف متاحًا ، إليك ما يتعين علينا القيام به:

وهذه هي الطريقة التي تعمل بها: إذا كنت تريد إجراء دردشة لكل مستخدم ، على التطبيق الخاص بك ، عندما يقوم المستخدم بتسجيل الدخول ، يمكنك التحقق مما إذا كان لدى المستخدم موضوع مرتبط. إذا لم يكن الأمر كذلك ، فمن ستدعوه؟ لا ، ليس Ghostbusters ، ولكن وظيفة CreateSubjectId ، وحفظ SubjectId المتوفر مع UserId. بعد ذلك ، عند استخدام المكون ، كل ما عليك فعله هو توفير ذلك الموضوع إلى المكون القابل لإعادة الاستخدام المدهش حديثًا ، بحيث يعرف تمامًا المنشورات (الرسائل) التي يجب عرضها أو حفظها لهذا المستخدم.

امزج الأفضل ، وفر الأفضل

لذلك ، لدينا الآن المنطق الأساسي لبناء مكون الدردشة.

بخصوص واجهة المستخدم ، الخيار لك. إت فويلا! لديك تطبيق دردشة يعمل!

هل تريد رؤية النتيجة وتجربتها؟ توجه إلى موقع Silk UI للحصول على تجربة قيادة. هناك أيضًا إمكانية لمعرفة المزيد حول الهيكل وكيفية عمله ، وبالطبع ، يمكنك تجربة النظام الأساسي الذي صممت به.