Blade أو Livewire أو Inertia: قرّر مرة، كما ينبغي

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

والخيارات الثلاثة رهانات مختلفة فعلًا على مكان حالة التطبيق، وكلفة عدم الاختيار تطبيق يفعلها بثلاث طرق.

Blade: الحالة تعيش في الخادم، والصفحات تُعاد تحميلها

قوالب تُرسَم في الخادم، ونماذج ترسل، وإعادات توجيه. الجواب الأقدم وهو صحيح أكثر مما توحي سمعته.

تحصل على أبسط نموذج ذهني ممكن، وأقل JavaScript مُرسَل، وتطبيق يستطيع أي مطوّر Laravel العمل عليه فورًا. ورشّة من Alpine تعالج القائمة المنسدلة والنافذة المنبثقة دون تغيير النموذج.

ويكفّ عن المناسبة حين يحتاج تفاعل فعلًا ألا يعيد التحميل - نموذج متعدد الخطوات يجب أن يحفظ حالته، أو جدول يرشّح حيًّا، أو أي شيء يفقد فيه تحميل صفحة كامل موضعَ المستخدم.

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

Livewire: الحالة تعيش في الخادم، والصفحة تتحدّث

مكوّنات مكتوبة بـ PHP. التفاعلات ترسل طلبًا، فيعيد الخادم رسم المكوّن، ويُطبَّق الفرق على الـ DOM. ولا حالة في العميل يجب إبقاؤها متزامنة، لأن هناك نسخة واحدة منها.

والمكسب أن فريق PHP يبني واجهات تفاعلية بلا لغة ثانية ولا خط بناء ولا مكتبة حالة. التحقق هو تحققك القائم. والتخويل هو policies القائمة لديك.

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

اخترها لـ: اللوحات، ولوحات الإدارة، والمعالجات، وكل ما هو بشكل CRUD ويريد أن يبدو حيًّا. وتجنّبها لـ: واجهات بتفاعل محلي عالي التردد - الرسم، والسحب، والترشيح اللحظي لقوائم كبيرة.

Inertia: الحالة تعيش في العميل، والتوجيه يبقى في الخادم

متحكماتك تعيد props؛ ويرسمها مكوّن صفحة React أو Vue. لا طبقة واجهة برمجية، ولا موجّه في العميل، ولا منطق تخويل مكرر - لكن نموذج مكوّنات حقيقي في العميل حيث يهم ذلك.

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

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

السؤال الذي يقرره

ليس "أيها أحدث". اسأل أين يحدث التفاعل.

إن كان فعل المستخدم ينتهي طبيعيًا بحفظ، فالخادم يستطيع امتلاك الحالة، وBlade أو Livewire يكفي. وإن كان المستخدم يعالج شيئًا فترة قبل أن يلتزم - إعادة ترتيب، ورسم، وترشيح، وتركيب - فالحالة تريد أن تكون محلية، وذلك هو Inertia.

والسؤال الثاني الفريق. فريق خلفية يسلّم Livewire سيتفوق على الفريق نفسه وهو يسلّم React، والعكس بالعكس. ومقارنة الأطر أصغر من تلك الفجوة.

الترتيب الذي ينجح

خيار رئيسي واحد للتطبيق، مكتوب، بقاعدة استثناء معلنة.

والشكل الصحي المعتاد هو Blade لصفحات التسويق والمحتوى، وأسلوب تفاعلي واحد للتطبيق نفسه، وملاحظة موثَّقة عن متى يُسمح بالآخر. وذلك صفحة في المستودع وهو الفرق بين خليط متعمَّد وخليط بالصدفة.

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

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