Mohmed Thapet - محمد ثابت

12/10/2026

مش كل كود شغال محتاج يتغير.
لكن لما تلاقي نفسك بتكرر نفس الكود كل شوية... هنا محتاج توقف وتراجع.

12/10/2026

# 36. Traits في PHP وLaravel — Code Organization 🧩

اتكلمنا المقال اللى فات عن Stubs In Laravel
على لنكدان
https://www.linkedin.com/pulse/35-stubs-laravel-mohamed-thapet-er7ze/
على فيس بوك
https://www.facebook.com/EngMohmedThapet/posts/pfbid026RPnbVjq7WiwX88szfaZp36zpCEYAuYk47yE73gfWAjftDQZctWCzUkfNHKnzEdsl

ودلوقتى خلينا نتكلم عن Traits

تخيل إن عندك `User` و`Product` و`Order`، وكل Class فيهم محتاج يستخدم نفس مجموعة الـ Methods.

هل هتكتب نفس الكود في كل Class؟

ولا هتعمل Parent Class واحدة وتخليهم كلهم يرثوا منها؟

فيه حل تالت مهم في PHP اسمه **Traits**، وLaravel نفسه بيستخدمه في أماكن كتير.

لكن الأهم من إنك تعرف تكتب Trait، إنك تفهم إمتى تستخدمها، وإمتى تكون بتعقّد الكود بدل ما تنظّمه.

يلا نفهم الموضوع من البداية. 👇

# # 1. يعني إيه Trait في PHP؟

الـ Trait هي وسيلة لإعادة استخدام الكود بين Classes مختلفة، من غير ما تحتاج تخليهم يرثوا من نفس Parent Class.

خلينا نشوف مثال بسيط:

```php
trait HasCode
{
public function generateCode(): string
{
return strtoupper(uniqid('ITEM-'));
}
}
```

هنا أنشأنا Trait اسمها `HasCode`، وفيها Method لتوليد كود.

عشان تستخدمها داخل Class، بتكتب `use`:

```php
class Product
{
use HasCode;
}

class Order
{
use HasCode;
}
```

دلوقتي تقدر تستخدم الـ Method من كل Class:

```php
$product = new Product();

echo $product->generateCode();
```

وكمان:

```php
$order = new Order();

echo $order->generateCode();
```

الاتنين عندهم نفس الـ Method، من غير ما نكرر تعريفها داخل كل Class.

**خلي بالك:** الـ Trait مش Class مستقلة تقدر تعمل منها Object باستخدام `new`، لكنها بتضيف Methods وMembers إلى الـ Class اللي بتستخدمها.

والـ `use` هنا معناها استخدام Trait، مش نفس معنى `use` اللي بنستورد بيه Namespace في أول الملف.

---

# # 2. المشكلة اللي بتحلها Traits

خلينا نفترض إن عندك أكتر من Model محتاج يسجل تاريخ آخر تحديث بواسطة المستخدم الحالي.

من غير Trait، ممكن تكرر نفس الـ Method:

```php
class Product
{
public function updatedByCurrentUser(): ?int
{
return auth()->id();
}
}

class Order
{
public function updatedByCurrentUser(): ?int
{
return auth()->id();
}
}
```

التكرار هنا مش مجرد سطور زيادة؛ لو احتجت تغيّر طريقة جلب المستخدم الحالي، هتحتاج تراجع كل مكان كررت فيه الكود.

نقدر نعيد استخدام نفس السلوك:

```php
trait TracksCurrentUser
{
public function updatedByCurrentUser(): ?int
{
return auth()->id();
}
}
```

وبعدها:

```php
class Product
{
use TracksCurrentUser;
}

class Order
{
use TracksCurrentUser;
}
```

دلوقتي السلوك موجود في مكان واحد.

لكن لازم ننتبه: المثال ده للتوضيح فقط، ووجود الـ Method داخل Trait مش معناه إنها هتُنفذ تلقائيًا وقت تحديث السجل. لو هدفك تسجيل `updated_by` تلقائيًا، محتاج تربطها بآلية مناسبة في Laravel، زي Model Events أو Observers.

وده بيوصلنا لنقطة مهمة: **إعادة استخدام الكود شيء، وتشغيله تلقائيًا شيء تاني.**

---

# # 3. Traits vs Inheritance vs Interfaces

التلاتة ليهم استخدامات مختلفة، ومش بدائل متطابقة.

# # # أولًا: Inheritance

لو عندك علاقة حقيقية بين Classes، ممكن تستخدم الوراثة:

```php
class Animal
{
public function eat(): void
{
// Eating logic
}
}

class Cat extends Animal
{
}
```

هنا `Cat` نوع من `Animal`، وبالتالي الوراثة منطقية.

لكن PHP بتسمح للـ Class إنها ترث من Parent Class واحدة مباشرة، وده بيخلّي الوراثة مش دايمًا مناسبة لمشاركة سلوك بين Classes مستقلة.

# # # ثانيًا: Interface

الـ Interface بتحدد العقد اللي الـ Class لازم يلتزم بيه، من غير ما توفر التنفيذ الفعلي للـ Methods العادية.

```php
interface Exportable
{
public function export(): string;
}
```

أي Class بتطبّق الـ Interface لازم تنفذ الـ Method المطلوبة:

```php
class ProductExporter implements Exportable
{
public function export(): string
{
return 'Exporting products';
}
}
```

# # # ثالثًا: Trait

الـ Trait بتسمح بإعادة استخدام تنفيذ جاهز:

```php
trait LogsActivity
{
public function logActivity(string $message): void
{
logger()->info($message);
}
}
```

وتقدر تستخدمها في Classes مختلفة:

```php
class ProductService
{
use LogsActivity;
}

class OrderService
{
use LogsActivity;
}
```

**القاعدة العملية:**

- محتاج تمثل علاقة وراثة؟ فكّر في `extends`.
- محتاج تفرض عقدًا على Classes مختلفة؟ فكّر في `implements`.
- محتاج تشارك تنفيذًا مشتركًا بين Classes؟ فكّر في `trait`.

وممكن تستخدم Interface وTrait مع بعض، لو محتاج تحدد العقد وتوفر تنفيذًا مشتركًا في الوقت نفسه.

---

# # 4. استخدام أكثر من Trait داخل Class واحدة

مش لازم الـ Class تستخدم Trait واحدة فقط.

```php
trait HasCode
{
public function generateCode(): string
{
return 'CODE-' . uniqid();
}
}

trait LogsActivity
{
public function logActivity(string $message): void
{
logger()->info($message);
}
}

class Product
{
use HasCode, LogsActivity;
}
```

دلوقتي `Product` عندها السلوكين:

```php
$product = new Product();

$code = $product->generateCode();

$product->logActivity("Product created: {$code}");
```

وده مفيد لما يكون عندك سلوكيات مستقلة نسبيًا، وكل Trait مسؤولة عن وظيفة واضحة.

لكن لو لقيت Class بتستخدم عددًا كبيرًا من Traits، وكل واحدة بتعتمد على التانية، فدي إشارة إنك محتاج تراجع التصميم.

مش الهدف إننا نقسم الكود لأكبر عدد ممكن من الملفات؛ الهدف إن كل جزء يكون له مسؤولية مفهومة.

---

# # 5. حل تعارض أسماء الـ Methods

تخيل إن عندك Trait لتسجيل نشاط المستخدم، وTrait تانية لتسجيل نشاط النظام، والاتنين فيهم Method اسمها `log()`.

```php
trait UserLogger
{
public function log(): string
{
return 'User log';
}
}

trait SystemLogger
{
public function log(): string
{
return 'System log';
}
}
```

لو استخدمت الاتنين مباشرة:

```php
class ActivityService
{
use UserLogger, SystemLogger;
}
```

هيحصل تعارض؛ لأن PHP مش هتعرف تختار أنهي `log()` تستخدم.

# # # الحل الأول: `insteadof`

تقدر تحدد أي Trait تفضّلها:

```php
class ActivityService
{
use UserLogger, SystemLogger {
UserLogger::log insteadof SystemLogger;
}
}
```

كده `log()` هتستخدم تنفيذ `UserLogger`.

# # # الحل الثاني: `as`

لو محتاج تحتفظ بالتنفيذين، تقدر تعمل Alias لإحدى الـ Methods:

```php
class ActivityService
{
use UserLogger, SystemLogger {
UserLogger::log insteadof SystemLogger;
SystemLogger::log as logSystem;
}
}
```

دلوقتي تقدر تستخدم:

```php
$service = new ActivityService();

$service->log();

$service->logSystem();
```

النقطة المهمة إن `as` هنا أضافت اسمًا بديلًا للـ Method؛ مش معناها إننا حذفنا الاسم الأصلي من الـ Trait.

وتقدر كمان تستخدم `as` لتغيير مستوى الوصول للـ Method، زي تحويلها إلى `protected` أو `private` داخل الـ Class.

---

# # 6. هل الـ Trait ممكن تحتوي على Properties؟

أيوه، الـ Trait ممكن تحتوي على Properties، مش Methods بس.

```php
trait HasStatus
{
public string $status = 'pending';
}
```

وتستخدمها داخل Class:

```php
class Order
{
use HasStatus;
}
```

وبعدها:

```php
$order = new Order();

echo $order->status;
```

لكن هنا لازم تكون حذر.

لو الـ Trait والـ Class عرّفوا Property بنفس الاسم، لازم التعريفين يكونوا متوافقين حسب قواعد PHP، وإلا ممكن يحصل Fatal Error.

عشان كده، إضافة Properties داخل Traits محتاجة تفكير، خصوصًا لو الـ Trait هتستخدم في Classes مختلفة.

**نصيحة عملية:** لو الـ Trait محتاجة عددًا كبيرًا من Properties أو بتعتمد على تفاصيل داخلية مش موجودة في كل Class، راجع هل تصميمها مناسب من الأساس.

---

# # 7. Abstract Methods داخل Traits

أحيانًا الـ Trait بتحتاج من الـ Class اللي بتستخدمها إنها توفر Method معينة.

تقدر تعبّر عن الاعتماد ده باستخدام Abstract Method.

```php
trait SendsNotifications
{
public function notifyUser(): void
{
$message = $this->notificationMessage();

logger()->info($message);
}

abstract protected function notificationMessage(): string;
}
```

هنا الـ Trait بتستخدم `notificationMessage()`، لكنها مش بتحدد تنفيذها.

الـ Class المسؤولة عن التنفيذ هي اللي بتوفرها:

```php
class OrderService
{
use SendsNotifications;

protected function notificationMessage(): string
{
return 'Order processed successfully';
}
}
```

كده الـ Trait بتعيد استخدام جزء من السلوك، وفي نفس الوقت بتوضح إن الـ Class لازم توفر الجزء الناقص.

لكن استخدام Abstract Methods مش معناه إن الـ Trait بقت Interface؛ هي ما زالت بتوفر تنفيذًا فعليًا لبعض الـ Methods.

وخلي بالك إن الـ Method المنفذة لازم تلتزم بقواعد توافق التوقيع (Method Signature Compatibility) في PHP.

---

# # 8. إزاي Laravel بيستخدم Traits؟

لو اشتغلت مع Laravel، فأنت غالبًا استخدمت Traits بالفعل حتى لو ما كنتش مركز في الموضوع.

# # # مثال 1: HasFactory

في الـ Models:

```php
use Illuminate\Database\Eloquent\Factories\HasFactory;

class Product extends Model
{
use HasFactory;
}
```

الـ Trait دي بتوفر إمكانيات مرتبطة باستخدام Model Factories، وده بيسهّل إنشاء بيانات للاختبارات والتطوير.

# # # مثال 2: SoftDeletes

```php
use Illuminate\Database\Eloquent\SoftDeletes;

class Product extends Model
{
use SoftDeletes;
}
```

بمجرد استخدام `SoftDeletes` مع الإعداد المناسب للجدول، Laravel بيوفر سلوك الحذف المنطقي بدل حذف السجل نهائيًا في الحالات المعتادة.

مثلًا:

```php
Product::find(10)?->delete();
```

السجل بيتحدد كمحذوف منطقيًا بدل ما يتم حذفه فعليًا من قاعدة البيانات.

ولأن `SoftDeletes` بتضيف سلوكًا خاصًا بـ Eloquent، فهي مش مجرد Method عامة نقدر نحطها في أي Class ونفترض إنها هتشتغل؛ استخدامها مرتبط بآلية الـ Models في Laravel.

# # # مثال 3: Notifiable

```php
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
use Notifiable;
}
```

الـ Trait دي بتوفر Methods للتعامل مع نظام Notifications في Laravel.

# # # إيه اللي نتعلمه من الأمثلة دي؟

Laravel بيستخدم Traits عشان يضيف سلوكيات قابلة لإعادة الاستخدام، لكن كل Trait ليها مسؤولية واضحة وسياق مناسب.

مش معنى إن Trait موجودة في Laravel إننا لازم نستخدم نفس الأسلوب في كل جزء من مشروعنا؛ لازم نفهم الأول السلوك اللي بتضيفه واعتماداته.

---

# # 9. إمتى أستخدم Trait وإمتى أستخدم Service؟

ودي نقطة مهمة جدًا، خصوصًا إن المقال القادم هيكون عن Services.

تخيل إن عندك عملية لحساب إجمالي طلب بعد تطبيق الخصومات والضرائب.

هل تحط كل الحسابات دي داخل Trait وتستخدمها في أي Class محتاجها؟

مش بالضرورة.

لو عندك **Business Logic مستقلة**، زي حساب إجمالي الطلب أو معالجة عملية دفع، فغالبًا Service هتكون اختيارًا أوضح.

أما لو عندك سلوك صغير ومشترك، مناسب لأكثر من Class، ومش محتاج مسؤوليات أو Dependencies معقدة، فقد تكون Trait مناسبة.

مثال توضيحي:

```php
trait FormatsPrice
{
public function formatPrice(float $price): string
{
return number_format($price, 2);
}
}
```

ده مثال بسيط لسلوك تنسيق ممكن إعادة استخدامه.

لكن لو عندك خدمة تسعير كاملة تعتمد على الضرائب والخصومات وقواعد العمل، فالأفضل غالبًا وضعها في Service مستقلة بدل تجميع كل التفاصيل داخل Trait.

والفرق الأهم:

- الـ Trait بتضيف سلوكًا إلى الـ Class التي تستخدمها.
- الـ Service بتكون Class مستقلة تمثل مسؤولية أو عملية محددة، ويمكن حقنها باستخدام Dependency Injection.

وده مش قانون مطلق، لكنه نقطة بداية جيدة لاتخاذ القرار الصحيح.

---

# # 10. أخطاء شائعة عند استخدام Traits

**1. إنشاء Trait لكل Method**

مش كل Method مشتركة تستحق Trait مستقلة. لو التقسيم زاد عن الحد، هتضطر تتنقل بين ملفات كثيرة عشان تفهم سلوكًا بسيطًا.

**2. الاعتماد على Properties غير واضحة**

لو Trait بتستخدم `$this->user` أو `$this->repository` من غير ما توضح المتطلبات، ممكن تخلي فهم الـ Class أصعب.

استخدم Dependencies واضحة، أو صمّم السلوك بطريقة تقلل الاعتماد على تفاصيل داخلية غير معلنة.

**3. وضع Business Logic كبيرة داخل Trait**

لو الـ Trait مسؤولة عن الدفع، وإرسال الإشعارات، وتحديث الطلبات، وتسجيل التقارير، فهي غالبًا بتجمع مسؤوليات غير مترابطة.

**4. نسيان تعارض الأسماء**

استخدام Traits متعددة ممكن ينتج عنه تعارض في أسماء الـ Methods. استخدم `insteadof` و`as` عند الحاجة، لكن اسأل نفسك أيضًا هل تركيب الـ Traits نفسه منطقي.

**5. اعتبار Trait بديلًا عن Inheritance أو Interface**

كل واحدة ليها دور مختلف. اختيار الأداة المناسبة بيبدأ من فهم المشكلة، مش من محاولة استخدام كل ميزات PHP.

---

# # الخلاصة

الـ Traits في PHP وسيلة قوية لإعادة استخدام السلوك بين Classes مختلفة، وLaravel بيستخدمها بالفعل في أجزاء مهمة زي `HasFactory` و`SoftDeletes` و`Notifiable`.

اتعلمنا:
- إنشاء Trait واستخدامها داخل Classes.
- الفرق بين Traits وInheritance وInterfaces.
- استخدام أكثر من Trait.
- حل تعارض الـ Methods باستخدام `insteadof` و`as`.
- التعامل مع Properties وAbstract Methods.
- التمييز بين Trait وService.
- الأخطاء اللي ممكن تخلي الكود أصعب بدل ما يكون أنظم.

# # نصيحة للـJunior

قبل ما تعمل Trait، اسأل نفسك سؤالين:

**هل عندي سلوك مشترك فعلًا؟ وهل إعادة استخدامه بهذه الطريقة هتخلي الكود أوضح؟**

لو الإجابة آه، استخدمها.

لكن متحوّلش كل كود متكرر إلى Trait تلقائيًا، ومتستخدمهاش لمجرد إنك عايز تقلل عدد السطور.

الهدف مش أقل كود ممكن؛ الهدف كود مسؤولياته واضحة، وسهل تتبعه وتعديله واختباره.

**إعادة استخدام الكود مهارة، واختيار المكان الصحيح للكود مهارة أهم.** 🚀

---

📌 **المقال القادم: Services في Laravel**

هنشرح يعني إيه Service، وإمتى نحتاجها، وإزاي ننقل الـ Business Logic خارج الـ Controllers، وإزاي نستفيد من Dependency Injection عشان نخلي الكود منظمًا وقابلًا للاختبار.

=======

12/10/2026

=> React.js

12/10/2026

#فيو


**29- Vue-CLI (Slots)**

في الدرس اللي فات اتكلمنا عن **Component Lifecycle Hooks**، وعرفنا المراحل اللي بيمر بيها الـComponent أثناء حياته.
على لنكدان
https://lnkd.in/p/exRRSwsG
على فيس بوك
https://www.facebook.com/EngMohmedThapet/posts/pfbid031HaQDbgG1sjbc2D5RfAjdbwW6vzHrhq2P7Wm6xQff6zU9sDZMnaZPLzwhujYmkF3l

النهارده هنتعرف على طريقة بتخلّي الـComponents أكثر مرونة:

# 🧩 Slots

# # 🤔 يعني إيه Slot؟

تخيل إن عندك Component بيعرض Card، وعايز تستخدم نفس التصميم في أكتر من مكان، لكن كل مرة بمحتوى مختلف.

بدل ما نغيّر محتوى الـComponent نفسه، نقدر نستخدم **Slots** علشان الـParent يحدد المحتوى اللي يتحط جواه.

---

# # 📦 1- إنشاء Component فيه Slot

هننشئ ملف `BaseCard.vue`:

```vue





```

الـ`` هنا بمثابة مكان مخصص للمحتوى اللي هيتم تمريره من الـParent.

---

# # 🚀 2- استخدام الـComponent

داخل `App.vue`:

```vue


Welcome!
This is my first card.



About Vue
Vue makes UI development easier.




import BaseCard from './components/BaseCard.vue';

export default {
components: {
BaseCard
}
}

```

لاحظ إننا استخدمنا نفس `BaseCard` مرتين، لكن بمحتوى مختلف في كل مرة.

الـSlot هيعرض المحتوى اللي كتبناه بين تاجي الـComponent.

---

# # 🔄 3- Slot بمحتوى افتراضي

ممكن كمان نحدد محتوى افتراضي يظهر لو الـParent مبعتش أي محتوى:

```vue


Click Me


```

لو استخدمنا:

```vue

```

هيظهر الزرار بالنص `Click Me`.

لكن لو استخدمنا:

```vue

Save Changes

```

هيظهر النص `Save Changes` بدل المحتوى الافتراضي.

---

# # 🧠 إمتى نستخدم Slots؟

مفيدة جدًا لما نعمل Components عامة وقابلة لإعادة الاستخدام، زي:

- Cards
- Buttons
- Modals
- Layouts
- Alert Messages

بدل ما نربط الـComponent بمحتوى ثابت، بنخليه يوفر التصميم ويستقبل المحتوى من المكان اللي بيستخدمه.

---

# # ✅ الخلاصة

افتكر الفرق ده:

**Props:** بنستخدمها لتمرير البيانات للـComponent.

**Slots:** بنستخدمها لتمرير محتوى أو واجهة من الـParent إلى مكان محدد داخل الـComponent.

وده بيساعدنا نبني Components مرنة نقدر نستخدمها في مواقف مختلفة من غير ما نكرر الكود.

🔥 **الدرس الجاي: Vue-CLI (Toggle Components & Keep Data)**

هنتعلم إزاي نبدّل بين Components، وإزاي نحافظ على بيانات الـComponent لما ننتقل منه لغيره باستخدام `KeepAlive`.

========

12/10/2026

=> Laravel

11/10/2026

متستناش لما المشروع يكبر عشان تبدأ تستخدم Git.

11/10/2026

# 35. Understanding & Customizing Stubs في Laravel ⚙️

اتكلمنا المقال اللى فات عن Commands In Laravel
على لنكدان
https://www.linkedin.com/pulse/34commands-laravel-mohamed-thapet-g0wve/
على فيس بوك
https://www.facebook.com/EngMohmedThapet/posts/pfbid037ikGPeKxaNH8NcfZnCwQeqZ3ZssjsPdE4MZBUhC3ev7vq9wTFFg8HKgzbJtpGTsxl

وخلينا نكمل Understanding & Customizing Stubs في Laravel ⚙️
عمرك استخدمت:

```bash
php artisan make:controller ProductController
```

ولاحظت إن Laravel بيُنشئ Controller جاهز فيه `namespace` و`class` وتركيب أساسي للكود؟

طيب، فكرت قبل كده Laravel بيعرف منين يكتب الكود ده؟ وهل تقدر تتحكم في الشكل اللي الملفات الجديدة بتتولد بيه؟

الإجابة: **Stubs**.

والميزة هنا إنك مش محتاج تعدّل كل ملف بعد إنشائه يدويًا؛ تقدر تعدّل القالب نفسه، وLaravel يستخدمه في إنشاء الملفات الجديدة.

خلينا نفهم الموضوع عمليًا. 👇

# # 1. يعني إيه Stubs؟

الـ **Stub** هو ملف قالب (Template) بيستخدمه Laravel لإنشاء ملفات الكود تلقائيًا.

مثلًا، لما تنفذ:

```bash
php artisan make:model Product
```

Laravel بيُنشئ Model جديد بناءً على Stub مناسب، ويستبدل بعض القيم داخل القالب بالمعلومات الخاصة بالملف اللي طلبت إنشاءه.

نفس الفكرة موجودة في أوامر إنشاء ملفات أخرى، زي:

- Controllers
- Models
- Commands
- Jobs
- Tests
- Migrations

وده بيساعد Laravel على إنشاء ملفات بتتبع تركيبًا متوقعًا بدل ما تبدأ كل مرة من ملف فارغ.

**خلي بالك:** الـ Stub مش هو الملف النهائي، لكنه القالب اللي Laravel بيستخدمه لإنتاج الملف النهائي.

# # 2. ليه نحتاج نخصص Stubs؟

تخيل إنك شغال على مشروع كبير، وعندك طريقة معينة بتحب تبدأ بيها كل Controller جديد.

مثلًا، عايز تضيف تعليقًا ثابتًا في بداية كل Class، أو توحّد طريقة كتابة بعض الأجزاء الأساسية في الملفات الجديدة.

بدل ما تضيف نفس الكود يدويًا في كل مرة، تقدر تعدّل الـ Stub المسؤول عن إنشاء الملف.

وده مفيد في حالات زي:

- توحيد شكل الملفات بين أعضاء الفريق.
- تطبيق Coding Conventions خاصة بالمشروع.
- إضافة تعليقات أو توثيق افتراضي.
- تعديل التركيب الابتدائي للملفات.
- تقليل التعديلات اليدوية المتكررة بعد استخدام أوامر `make`.

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

# # 3. إزاي تنشر Stubs داخل مشروعك؟

Laravel بيوفر أمر جاهز لنشر مجموعة من الـ Stubs القابلة للتخصيص.

نفّذ:

```bash
php artisan stub:publish
```

بعدها هتلاقي مجلدًا باسم:

```text
stubs/
```

في جذر المشروع، وداخله ملفات القوالب اللي Laravel نشرها للتخصيص.

شكل المجلد ومحتوياته بيعتمد على القوالب اللي الإصدار الحالي من Laravel بيوفرها.

**نقطة مهمة:** مش مطلوب منك تنسخ كل ملفات Laravel الداخلية أو تعدّل داخل `vendor`. الأمر ده هو الطريق المخصص لنشر القوالب اللي Laravel بيسمح بتخصيصها.

# # 4. إزاي تعدّل Stub؟

خلينا ناخد مثالًا على Controller.

بعد نشر الـ Stubs، ابحث عن ملف القالب المسؤول عن إنشاء الـ Controllers، وغالبًا هتلاقي اسمه:

```text
stubs/controller.stub
```

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

ممكن تختلف التفاصيل حسب نوع الـ Controller والقالب المستخدم.

مثلًا، لو هدفك إن كل Controller جديد يحتوي على تعليق توثيقي ثابت، تقدر تضيف التعليق المناسب داخل القالب في المكان اللي يناسبك.

بعدها نفّذ:

```bash
php artisan make:controller OrderController
```

Laravel هيستخدم القالب المعدّل لإنشاء الـ Controller الجديد، بشرط إن الأمر بيستخدم الـ Stub اللي عدّلته.

وهنا تظهر الفكرة الأساسية: **أنت بتعدّل طريقة توليد الملفات، مش بتعدّل Laravel نفسه.**

# # 5. هل التعديلات بتتطبق على الملفات القديمة؟

لأ.

لو عندك بالفعل:

```text
app/Http/Controllers/ProductController.php
```

وبعدها عدّلت Stub الخاص بالـ Controllers، الملف الموجود مش هيتغير تلقائيًا.

التعديل هيظهر في الملفات الجديدة اللي هتتولد باستخدام القالب المعدّل.

وده سلوك منطقي؛ لأن تعديل القالب مش معناه إن Laravel يعيد كتابة ملفات مشروعك، وده بيحميك من تغييرات غير مقصودة في كود موجود بالفعل.

ولو عايز تطبق نفس التغيير على الملفات القديمة، لازم تراجعها وتعدّلها بنفسك، أو تستخدم Refactoring مناسب حسب طبيعة التغيير.

# # 6. هل كل أمر `make` بيستخدم نفس الـ Stub؟

لأ.

كل نوع من الملفات ليه قالب مناسب له، وممكن يكون فيه أكتر من قالب لنفس النوع حسب الخيارات المستخدمة.

مثلًا، إنشاء Controller عادي مش بالضرورة ينتج نفس تركيب Controller من نوع Resource أو Invokable.

عشان كده، لو عدّلت Stub وما لاحظتش التغيير في الملف الجديد، راجع:

- هل عدّلت القالب الصحيح؟
- هل الأمر بيستخدم قالبًا مختلفًا بسبب أحد الخيارات؟
- هل القالب موجود ضمن القوالب المنشورة والقابلة للتخصيص؟
- هل الملف الجديد اتولد فعلًا بعد التعديل؟

الفهم هنا أهم من مجرد تنفيذ الأمر؛ لأنك محتاج تعرف العلاقة بين أمر `make` والقالب اللي بيستخدمه.

# # 7. نصائح مهمة قبل تخصيص Stubs

**أولًا: احتفظ بالتعديلات على Git**

ملفات `stubs` جزء من إعدادات مشروعك، ومن الأفضل تتبعها داخل Version Control عشان أعضاء الفريق يستخدموا نفس القوالب.

**ثانيًا: اختبر التغيير**

بعد تعديل أي Stub، أنشئ ملفًا جديدًا وتأكد إن الكود الناتج صحيح، وإنه بيشتغل مع إصدار Laravel المستخدم في المشروع.

**ثالثًا: متعدّليش لمجرد التعديل**

لو القالب الافتراضي مناسب لاحتياجاتك، مش لازم تغيّره. التخصيص مفيد لما يحل مشكلة متكررة أو يحقق معيارًا واضحًا في المشروع.

**رابعًا: راجع التعديلات عند تحديث Laravel**

ممكن القوالب الافتراضية تتغير مع إصدارات Laravel الجديدة. لو عندك Stubs مخصصة، راجع الفرق بينها وبين القوالب الجديدة قبل ترقية المشروع، عشان ما تفوّتش تحسينات أو تغييرات مهمة.

# # الخلاصة

الـ Stubs بتديك وسيلة لتخصيص الملفات اللي Laravel بيولّدها تلقائيًا، بدل ما تكرر نفس التعديلات اليدوية بعد كل أمر `make`.

افتكر الفرق:

- **Artisan Command:** بيطلب إنشاء ملف أو تنفيذ عملية.
- **Stub:** القالب اللي ممكن يُستخدم لإنشاء الملف.
- **Generated File:** الملف الفعلي اللي هتشتغل عليه داخل مشروعك.

مش كل مشروع محتاج تخصيص Stubs، لكن لما يكون عندك معيار ثابت لتوليد الملفات، ممكن توفر وقتًا وتحافظ على اتساق الكود.

# # نصيحة للـJunior

متفكرش بس إزاي تكتب الكود، فكّر كمان إزاي تقلل الشغل المتكرر اللي بتعمله كل يوم.

لو لقيت نفسك بتضيف نفس الجزء في كل Controller أو Command جديد، اسأل نفسك: هل ده مجرد تكرار بسيط، ولا فيه فرصة لتحسين طريقة إنشاء الملفات من الأساس؟

لكن افتكر إن الهدف مش إنك تخصص كل حاجة في Laravel؛ الهدف إنك تعرف إمتى التخصيص يستحق تكلفته.

**الـ Developer الشاطر مش بس بيكتب الكود بكفاءة، لكنه كمان بيحسّن الطريقة اللي بيبدأ بيها كتابة الكود.** 🚀

---

📌 **المقال القادم: مرحلة جديدة — Code Organization**

هنبدأ نتكلم عن **Traits في PHP وLaravel**: إيه هي، وليه بنستخدمها، وإزاي نشارك سلوكًا مشتركًا بين أكثر من Class من غير ما نكرر الكود، وإمتى استخدامها يكون مناسبًا وإمتى يتحول إلى تعقيد إضافي.

=======

11/10/2026

#منقول
إزاي تستلم API وإنت فرونت إند؟ خطوة بخطوة من الباك إند

الموضوع مش مجرد «اللينك أهو، وربنا يسهّل».

لا، فيه فلو لازم تمشي عليه علشان تتأكد إن كل حاجة واضحة وشغالة من أول يوم.

⸻

1. اتأكد إن معاك Docs واضحة

قبل ما تكتب سطر كود، اطلب Documentation رسمية:

* ممكن تكون Swagger UI أو Postman Collection أو حتى ملف Notion مرتب.
* شوف كل Endpoint بيعمل إيه.
* إيه الـ Methods (GET - POST - PUT - DELETE).
* هل فيه Auth؟ هل فيه Rate Limits؟
* هل فيه Pagination أو Filtering؟

2. افهم شكل الـ Response كويس

مهم جدًا تشوف الشكل المتوقع للـ Response:

* الـ Structure بتاع الـ JSON.
* أنواع البيانات (String, Number, Boolean, Array, Object).
* الـ Status Codes (200 - 400 - 401 - 500…).
* هل فيه Error Messages مفيدة؟ ولا “Something went wrong” وخلاص؟

ولو شغال بـ TypeScript، تبدأ تبني الـ Types/Interfaces على طول من الـ Response ده.

ويُفضل تستخدم أدوات زي quicktype.io لو عايز تحوّل JSON لـ TypeScript بسرعة.

⸻

3. اعمل Planning قبل الكود

متبدأش على طول تربط في الكود.

اعمل خطة واضحة:

* إيه الـ APIs اللي هستخدمها في كل صفحة؟
* هل فيه حاجة محتاجة Caching؟
* إيه البيانات المشتركة اللي ممكن أعملها Global State؟
* هل هحتاج Revalidation ولا الداتا Static؟

كل ده بيسهل عليك تبني Structure نظيف وسهل يتصان بعد كده.

⸻

4. جرّب كل Endpoint بإيدك

سواء على Postman أو Swagger:

* ابعت Requests بإيدك.
* شوف الردود.
* جرّب حالات النجاح والخطأ.
* غيّر الـ Inputs وشوف تأثيرها.

ده بيوفر عليك Debugging كبير جدًا بعدين، وبيخليك فاهم الـ API صح، مش حافظه بس.

⸻

5. اربط الفرونت بالـ API تدريجيًا

ابدأ تربط الـ Components واحدة واحدة:

* اعمل Call للـ API.
* خزن الداتا في State.
* اعرضها في UI.
* اعمل Handling للحالات المختلفة (Loading, Error, Empty, Success).

⸻

6. اختبر كل السيناريوهات

قبل ما تقول «الصفحة خلصت»:

* جرّب API بداتا ناقصة.
* جرّب يكون فيه Delay في الرد.
* افصل النت وشوف الـ UI بيتصرف إزاي.
* جرّب يدخل المستخدم داتا غلط.
* شوف الأخطاء اللي بترجع وتعامل معاها بطريقة واضحة للمستخدم.

⸻

7. اتكلم مع الباك إند باستمرار

أي حاجة مش واضحة؟ اسأل.

فيه داتا ناقصة؟ نبههم.

الدزاين فيه حاجة مش متغطّية في الـ API؟ اتكلم.

Communication مهمة جدًا علشان المشروع يطلع مضبوط، ومفيش إعادة شغل كل شوية.

⸻

الهدف:

لما تيجي تشتغل، تكون جاهز مش بتخبط.

وتسليمك للـ Feature يبقى من الآخر: شغال، متستف، وعامل تيست محترم عليه.

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

11/10/2026

#فيو


**28- Vue-CLI (Component Lifecycle Hooks)**

في الدرس اللي فات اتكلمنا عن **Emit Events**، وإزاي الـChild Component يقدر يبعت Event للـParent.
على لنكدان
https://lnkd.in/p/eUEpsKKh
على فيس بوك
https://www.facebook.com/EngMohmedThapet/posts/pfbid0zY7RtvZ27n7vSDBtAQUpmXMzQAdB3FJfJwANeCnTEDfmacf5SNfRJmGsxDviaWmpl
النهارده هنتعرف على مفهوم مهم جدًا في Vue:

# 🔄 Component Lifecycle Hooks

# # 🤔 يعني إيه Lifecycle؟

أي Component في Vue بيمر بمراحل مختلفة خلال حياته:

- بيتجهز قبل ما يظهر.
- بيظهر في الصفحة.
- ممكن بياناته تتغير ويتحدث.
- وفي النهاية ممكن يتشال من الصفحة.

Vue بتوفر لنا **Lifecycle Hooks** علشان ننفذ كود في مراحل محددة من دورة حياة الـComponent.

---

# # 🚀 1- created()

الـHook دي بتتنفذ بعد ما Vue تجهز الـComponent وتهيئ الـReactivity، لكن قبل ما يتم إنشاء الـDOM الخاص بيه.

```js
export default {
data() {
return {
message: 'Hello Vue!'
}
},

created() {
console.log(this.message);
}
}
```

هنا نقدر نوصل للـData، لكن لسه عناصر الـDOM مش جاهزة للاستخدام.

**مناسبة لأعمال التهيئة اللي مش محتاجة الوصول للـDOM.**

---

# # 🖥️ 2- mounted()

بتتنفذ بعد ما الـComponent يتم تركيبه في الـDOM.

```js
export default {
mounted() {
console.log('Component mounted!');
}
}
```

بنستخدمها لما نحتاج نتعامل مع عنصر موجود في الصفحة أو نهيئ مكتبة خارجية بتعتمد على الـDOM.

---

# # 🔄 3- updated()

بتتنفذ بعد ما Vue تحدث الـDOM نتيجة تغيير في البيانات التفاعلية.

```js
export default {
data() {
return {
count: 0
}
},

updated() {
console.log('Component updated!');
}
}
```

لما قيمة `count` تتغير ويترتب عليها تحديث للواجهة، ممكن الـHook دي تتنفذ.

⚠️ خلي بالك: تجنب تعديل نفس البيانات التفاعلية بشكل متكرر داخل `updated()`، لأن ده ممكن يؤدي إلى حلقة تحديثات مستمرة.

---

# # 🗑️ 4- unmounted()

بتتنفذ بعد إزالة الـComponent من الـDOM.

```js
export default {
unmounted() {
console.log('Component removed!');
}
}
```

ممكن نستخدمها لتنظيف الموارد، زي إلغاء بعض الـListeners أو إيقاف Timers أنشأناها أثناء حياة الـComponent.

---

# # 🧠 نفهم ترتيب المراحل

في Vue 3، الترتيب الأساسي اللي يهمنا:

```text
Component Created
↓
mounted
↓
updated
↓
unmounted
```

الـ`updated` ممكن تتكرر أكثر من مرة حسب التغييرات، ومش شرط تحصل لو مفيش تحديثات.

وفي Vue 3 كمان فيه Hooks زي `beforeMount` و`beforeUpdate` و`beforeUnmount`، بتسمح لنا ننفذ كود قبل كل مرحلة.

---

# # ⚠️ ملحوظة مهمة

الأمثلة هنا بتستخدم **Options API**، بنفس أسلوب `data()` و`methods` اللي اتعاملنا معاه في الدروس السابقة.

وفي Vue 3، أسماء الـHooks مختلفة لو استخدمنا Composition API، زي `onMounted()` بدل `mounted()`.

---

# # ✅ الخلاصة

الـLifecycle Hooks بتدينا فرصة ننفذ كود في الوقت المناسب من حياة الـComponent:

- `created()` — بعد تهيئة الـComponent وقبل إنشاء الـDOM.
- `mounted()` — بعد تركيب الـComponent في الـDOM.
- `updated()` — بعد تحديث الـDOM.
- `unmounted()` — بعد إزالة الـComponent.

فبدل ما ننفذ كل العمليات في أي مكان، بنختار الـHook المناسبة حسب احتياجنا.

🔥 **الدرس الجاي: Vue-CLI (Slots)**

هنتعرف على الـ**Slots**، وإزاي نخلي الـComponent يستقبل محتوى من الـParent بدل ما يكون محتواه ثابتًا، وده هيساعدنا نبني Components أكثر مرونة وإعادة استخدام.

========

11/10/2026