تحليل خطاف `use` في React: نظرة عميقة على الـ Promises، السياق، وإدارة الموارد

يشهد النظام البيئي لـ React تطورًا مستمرًا، حيث يعمل باستمرار على تحسين تجربة المطورين ودفع حدود ما هو ممكن على الويب. من الأصناف (classes) إلى الخطافات (Hooks)، كل تحول رئيسي غيّر بشكل أساسي طريقتنا في بناء واجهات المستخدم. اليوم، نقف على أعتاب تحول آخر، تبشر به دالة تبدو بسيطة بشكل خادع: خطاف `use`.

لسنوات، كافح المطورون مع تعقيدات العمليات غير المتزامنة وإدارة الحالة. كان جلب البيانات يعني غالبًا شبكة معقدة من `useEffect` و `useState` وحالات التحميل/الخطأ. أما استهلاك السياق (context)، فرغم قوته، كان يأتي مع مشكلة أداء كبيرة تتمثل في إعادة العرض (re-render) لكل مستهلك. يأتي خطاف `use` كإجابة أنيقة من React لهذه التحديات طويلة الأمد.

صُمم هذا الدليل الشامل لجمهور عالمي من مطوري React المحترفين. سنقوم برحلة عميقة داخل خطاف `use`، نحلل آلياته ونستكشف حالتَي استخدامه الأساسيتين الأوليتين: فك تغليف الـ Promises وقراءة السياق. والأهم من ذلك، سنحلل الآثار العميقة على استهلاك الموارد والأداء وهيكلة التطبيقات. استعد لإعادة التفكير في كيفية تعاملك مع المنطق غير المتزامن والحالة في تطبيقات React الخاصة بك.

تحول جوهري: ما الذي يجعل خطاف `use` مختلفًا؟

قبل أن نتعمق في الـ Promises والسياق، من الضروري فهم سبب ثورية `use`. لسنوات، عمل مطورو React تحت قواعد الخطافات (Rules of Hooks) الصارمة:

استدعِ الخطافات فقط في المستوى الأعلى لمكونك.
لا تستدعِ الخطافات داخل الحلقات، الشروط، أو الدوال المتداخلة.

توجد هذه القواعد لأن الخطافات التقليدية مثل `useState` و `useEffect` تعتمد على ترتيب استدعاء ثابت خلال كل عملية عرض للحفاظ على حالتها. يحطم خطاف `use` هذه السابقة. يمكنك استدعاء `use` داخل الشروط (`if`/`else`)، الحلقات (`for`/`map`)، وحتى في عبارات `return` المبكرة.

هذا ليس مجرد تعديل بسيط؛ إنه نقلة نوعية. فهو يسمح بطريقة أكثر مرونة وبداهة لاستهلاك الموارد، منتقلًا من نموذج الاشتراك الثابت على المستوى الأعلى إلى نموذج استهلاك ديناميكي عند الطلب. بينما يمكن أن يعمل نظريًا مع أنواع مختلفة من الموارد، يركز تنفيذه الأولي على اثنتين من أكثر نقاط الألم شيوعًا في تطوير React: الـ Promises والسياق.

المفهوم الأساسي: فك تغليف القيم

في جوهره، صُمم خطاف `use` "لفك تغليف" قيمة من مورد ما. فكر في الأمر بهذه الطريقة:

إذا مررت له Promise، فإنه يفك تغليف القيمة التي تم حلها. إذا كان الـ promise معلقًا، فإنه يشير إلى React لتعليق العرض. إذا تم رفضه، فإنه يلقي بالخطأ ليتم التقاطه بواسطة Error Boundary.
إذا مررت له React Context، فإنه يفك تغليف قيمة السياق الحالية، مثل `useContext` إلى حد كبير. ومع ذلك، فإن طبيعته الشرطية تغير كل شيء حول كيفية اشتراك المكونات في تحديثات السياق.

دعنا نستكشف هاتين الإمكانيتين القويتين بالتفصيل.

إتقان العمليات غير المتزامنة: `use` مع الـ Promises

يعد جلب البيانات شريان الحياة للتطبيقات الحديثة على الويب. كان النهج التقليدي في React عمليًا ولكنه غالبًا ما يكون مطولًا وعرضة للأخطاء الدقيقة.

الطريقة القديمة: رقصة `useEffect` و `useState`

لنأخذ مكونًا بسيطًا يجلب بيانات المستخدم. يبدو النمط القياسي شيئًا كهذا:


import React, { useState, useEffect } from 'react';

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let isMounted = true;
    const fetchUser = async () => {
      try {
        setIsLoading(true);
        const response = await fetch(`https://api.example.com/users/${userId}`);
        if (!response.ok) {
          throw new Error('Network response was not ok');
        }
        const data = await response.json();
        if (isMounted) {
          setUser(data);
        }
      } catch (err) {
        if (isMounted) {
          setError(err);
        }
      } finally {
        if (isMounted) {
          setIsLoading(false);
        }
      }
    };

    fetchUser();

    return () => {
      isMounted = false;
    };
  }, [userId]);

  if (isLoading) {
    return <p>Loading profile...</p>;
  }

  if (error) {
    return <p>Error: {error.message}</p>;
  }

  return (
    <div>
      <h1>{user.name}</h1>
      <p>Email: {user.email}</p>
    </div>
  );
}

هذا الكود مليء بالكود المكرر (boilerplate). نحتاج إلى إدارة ثلاث حالات منفصلة يدويًا (`user`، `isLoading`، `error`)، وعلينا أن نكون حذرين بشأن حالات التسابق (race conditions) والتنظيف باستخدام علامة `isMounted`. بينما يمكن للخطافات المخصصة (custom hooks) تجريد هذا الأمر، يظل التعقيد الأساسي قائمًا.

الطريقة الجديدة: التزامن الأنيق مع `use`

يبسط خطاف `use`، بالاقتران مع React Suspense، هذه العملية بأكملها بشكل كبير. يسمح لنا بكتابة كود غير متزامن يُقرأ كأنه كود متزامن.

إليك كيف يمكن كتابة نفس المكون باستخدام `use`:


// يجب عليك تغليف هذا المكون بـ <Suspense> و <ErrorBoundary>
import { use } from 'react';
import { fetchUser } from './api'; // افترض أن هذا يعيد promise مخبأ مؤقتًا (cached)

function UserProfile({ userId }) {
  // سيقوم `use` بتعليق المكون حتى يتم حل الـ promise
  const user = use(fetchUser(userId));

  // عندما يصل التنفيذ إلى هنا، يكون الـ promise قد تم حله و `user` لديه البيانات.
  // لا حاجة لحالات isLoading أو error في المكون نفسه.
  return (
    <div>
      <h1>{user.name}</h1>
      <p>Email: {user.email}</p>
    </div>
  );
}

الفرق مذهل. اختفت حالات التحميل والخطأ من منطق مكوننا. ماذا يحدث خلف الكواليس؟

عندما يتم عرض `UserProfile` لأول مرة، فإنه يستدعي `use(fetchUser(userId))`.
تبدأ دالة `fetchUser` طلب شبكة وتعيد Promise.
يستقبل خطاف `use` هذا الـ Promise المعلق ويتواصل مع عارض React لـتعليق عرض هذا المكون.
يصعد React في شجرة المكونات للعثور على أقرب حد `` ويعرض واجهة المستخدم الاحتياطية `fallback` (على سبيل المثال، مؤشر دوران).
بمجرد حل الـ Promise، يعيد React عرض `UserProfile`. هذه المرة، عند استدعاء `use` بنفس الـ Promise، يكون للـ Promise قيمة محلولة. يعيد `use` هذه القيمة.
يستمر عرض المكون، ويتم عرض ملف تعريف المستخدم.
إذا تم رفض الـ Promise، فإن `use` يلقي بالخطأ. يلتقط React هذا ويصعد في الشجرة إلى أقرب `` لعرض واجهة مستخدم احتياطية للخطأ.

نظرة عميقة على استهلاك الموارد: حتمية التخزين المؤقت (Caching)

تخفي بساطة `use(fetchUser(userId))` تفصيلاً حاسمًا: يجب ألا تنشئ Promise جديدًا في كل عملية عرض. إذا كانت دالتنا `fetchUser` هي ببساطة `() => fetch(...)`، واستدعيناها مباشرة داخل المكون، فسننشئ طلب شبكة جديدًا في كل محاولة عرض، مما يؤدي إلى حلقة لا نهائية. سيتعلق المكون، ويتم حل الـ promise، ويعيد React العرض، ويتم إنشاء promise جديد، وسيتعلق مرة أخرى.

هذا هو أهم مفهوم في إدارة الموارد يجب فهمه عند استخدام `use` مع الـ promises. يجب أن يكون الـ Promise مستقرًا ومخبأً مؤقتًا عبر عمليات إعادة العرض.

توفر React دالة `cache` جديدة للمساعدة في ذلك. لننشئ أداة جلب بيانات قوية:


// api.js
import { cache } from 'react';

export const fetchUser = cache(async (userId) => {
  console.log(`Fetching data for user: ${userId}`);
  const response = await fetch(`https://api.example.com/users/${userId}`);
  if (!response.ok) {
    throw new Error('Failed to fetch user data.');
  }
  return response.json();
});

تقوم دالة `cache` من React بتخزين نتيجة الدالة غير المتزامنة (memoization). عند استدعاء `fetchUser(1)`، تبدأ عملية الجلب وتخزن الـ Promise الناتج. إذا قام مكون آخر (أو نفس المكون في عرض لاحق) باستدعاء `fetchUser(1)` مرة أخرى ضمن نفس تمريرة العرض، فإن `cache` ستعيد نفس كائن الـ Promise بالضبط، مما يمنع طلبات الشبكة الزائدة. هذا يجعل جلب البيانات متماثلًا (idempotent) وآمنًا للاستخدام مع خطاف `use`.

هذا تحول جوهري في إدارة الموارد. بدلاً من إدارة حالة الجلب داخل المكون، ندير المورد (promise البيانات) خارجه، والمكون يستهلكه ببساطة.

إحداث ثورة في إدارة الحالة: `use` مع السياق (Context)

يعد React Context أداة قوية لتجنب "تمرير الخصائص" (prop drilling) — تمرير الخصائص عبر طبقات عديدة من المكونات. ومع ذلك، فإن تنفيذه التقليدي له عيب كبير في الأداء.

معضلة `useContext`

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

لنأخذ `SessionContext` الذي يحتوي على معلومات المستخدم والسمة الحالية:


// SessionContext.js
const SessionContext = createContext({
  user: null,
  theme: 'light',
  updateTheme: () => {},
});

// مكون يهتم فقط بالمستخدم
function WelcomeMessage() {
  const { user } = useContext(SessionContext);
  console.log('Rendering WelcomeMessage');
  return <p>Welcome, {user?.name}!</p>;
}

// مكون يهتم فقط بالسمة
function ThemeToggleButton() {
  const { theme, updateTheme } = useContext(SessionContext);
  console.log('Rendering ThemeToggleButton');
  return <button onClick={updateTheme}>Switch to {theme === 'light' ? 'dark' : 'light'} theme</button>;
}

في هذا السيناريو، عندما ينقر المستخدم على `ThemeToggleButton` ويتم استدعاء `updateTheme`، يتم استبدال كائن قيمة `SessionContext` بأكمله. هذا يتسبب في إعادة عرض كل من `ThemeToggleButton` و `WelcomeMessage`، على الرغم من أن كائن `user` لم يتغير. في تطبيق كبير به مئات من مستهلكي السياق، يمكن أن يؤدي هذا إلى مشاكل خطيرة في الأداء.

إليك `use(Context)`: الاستهلاك الشرطي

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

دعنا نعيد هيكلة مكون لتوضيح هذه القوة:


function UserSettings({ userId }) {
  const { user, theme } = useContext(SessionContext); // الطريقة التقليدية: يشترك دائمًا

  // لنتخيل أننا نعرض إعدادات السمة فقط للمستخدم الذي سجل الدخول حاليًا
  if (user?.id !== userId) {
    return <p>You can only view your own settings.</p>;
  }

  // هذا الجزء يعمل فقط إذا تطابق معرف المستخدم
  return <div>Current theme: {theme}</div>;
}

مع `useContext`، سيعاد عرض مكون `UserSettings` هذا في كل مرة تتغير فيها السمة، حتى لو كان `user.id !== userId` ولم يتم عرض معلومات السمة أبدًا. يتم إنشاء الاشتراك بشكل غير شرطي في المستوى الأعلى.

الآن، دعنا نرى إصدار `use`:


import { use } from 'react';

function UserSettings({ userId }) {
  // اقرأ المستخدم أولاً. لنفترض أن هذا الجزء رخيص أو ضروري.
  const user = use(SessionContext).user;

  // إذا لم يتم استيفاء الشرط، فإننا نعود مبكرًا.
  // الأهم من ذلك، لم نقرأ السمة بعد.
  if (user?.id !== userId) {
    return <p>You can only view your own settings.</p>;
  }

  // فقط إذا تم استيفاء الشرط، نقرأ السمة من السياق.
  // يتم إنشاء الاشتراك في تغييرات السياق هنا، بشكل شرطي.
  const theme = use(SessionContext).theme;

  return <div>Current theme: {theme}</div>;
}

هذا يغير قواعد اللعبة. في هذا الإصدار، إذا لم يتطابق `user.id` مع `userId`، فإن المكون يعود مبكرًا. السطر `const theme = use(SessionContext).theme;` لا يتم تنفيذه أبدًا. لذلك، فإن مثيل المكون هذا لا يشترك في `SessionContext`. إذا تم تغيير السمة في مكان آخر في التطبيق، فلن يعاد عرض هذا المكون دون داعٍ. لقد قام بشكل فعال بتحسين استهلاكه للموارد عن طريق القراءة الشرطية من السياق.

تحليل استهلاك الموارد: نماذج الاشتراك

يتغير النموذج الذهني لاستهلاك السياق بشكل كبير:

`useContext`: اشتراك فوري على المستوى الأعلى. يعلن المكون عن اعتماده مقدمًا ويعاد عرضه عند أي تغيير في السياق.
`use(Context)`: قراءة كسولة عند الطلب. يشترك المكون في السياق فقط في اللحظة التي يقرأ فيها منه. إذا كانت تلك القراءة شرطية، فإن الاشتراك يكون شرطيًا أيضًا.

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

التقاطع: `use` مع الـ Promises في السياق

تتضح القوة الحقيقية لـ `use` عندما نجمع بين هذين المفهومين. ماذا لو لم يوفر مزود السياق البيانات مباشرة، ولكن promise لتلك البيانات؟ هذا النمط مفيد بشكل لا يصدق لإدارة مصادر البيانات على مستوى التطبيق.


// DataContext.js
import { createContext } from 'react';
import { fetchSomeGlobalData } from './api'; // يعيد promise مخبأ مؤقتًا

// يوفر السياق promise، وليس البيانات نفسها.
export const GlobalDataContext = createContext(fetchSomeGlobalData());

// App.js
function App() {
  return (
    <GlobalDataContext.Provider value={fetchSomeGlobalData()}>
      <Suspense fallback={<h1>Loading application...</h1>}>
        <Dashboard />
      </Suspense>
    </GlobalDataContext.Provider>
  );
}

// Dashboard.js
import { use } from 'react';
import { GlobalDataContext } from './DataContext';

function Dashboard() {
  // `use` الأول يقرأ الـ promise من السياق.
  const dataPromise = use(GlobalDataContext);

  // `use` الثاني يفك تغليف الـ promise، معلقًا إذا لزم الأمر.
  const globalData = use(dataPromise);

  // طريقة أكثر إيجازًا لكتابة السطرين أعلاه:
  // const globalData = use(use(GlobalDataContext));

  return <h1>Welcome, {globalData.userName}!</h1>;
}

دعنا نحلل `const globalData = use(use(GlobalDataContext));`:

`use(GlobalDataContext)`: يتم تنفيذ الاستدعاء الداخلي أولاً. يقرأ القيمة من `GlobalDataContext`. في إعدادنا، هذه القيمة هي promise تم إعادته بواسطة `fetchSomeGlobalData()`.
`use(dataPromise)`: يتلقى الاستدعاء الخارجي بعد ذلك هذا الـ promise. يتصرف تمامًا كما رأينا في القسم الأول: يعلق مكون `Dashboard` إذا كان الـ promise معلقًا، يلقي بالخطأ إذا تم رفضه، أو يعيد البيانات المحلولة.

هذا النمط قوي بشكل استثنائي. يفصل منطق جلب البيانات عن المكونات التي تستهلك البيانات، بينما يستفيد من آلية Suspense المدمجة في React لتجربة تحميل سلسة. لا تحتاج المكونات إلى معرفة *كيف* أو *متى* يتم جلب البيانات؛ هي ببساطة تطلبها، و React ينسق الباقي.

الأداء، المخاطر، وأفضل الممارسات

مثل أي أداة قوية، يتطلب خطاف `use` فهمًا وانضباطًا لاستخدامه بفعالية. إليك بعض الاعتبارات الرئيسية للتطبيقات الإنتاجية.

ملخص الأداء

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

المخاطر الشائعة التي يجب تجنبها

Promises غير المخبأة مؤقتًا: الخطأ رقم واحد. استدعاء `use(fetch(...))` مباشرة في مكون سيسبب حلقة لا نهائية. دائمًا استخدم آلية تخزين مؤقت مثل `cache` من React أو مكتبات مثل SWR/React Query.
الحدود المفقودة: استخدام `use(Promise)` بدون حد `` أبوي سيؤدي إلى تعطل تطبيقك. وبالمثل، فإن promise مرفوض بدون حد `` أبوي سيؤدي أيضًا إلى تعطل التطبيق. يجب عليك تصميم شجرة مكوناتك مع وضع هذه الحدود في الاعتبار.
التحسين المبكر: بينما `use(Context)` رائع للأداء، فإنه ليس ضروريًا دائمًا. للسياقات البسيطة، التي تتغير بشكل غير متكرر، أو حيث يكون إعادة عرض المستهلكين رخيصًا، فإن `useContext` التقليدي جيد تمامًا وأكثر وضوحًا قليلاً. لا تعقد الكود الخاص بك دون سبب واضح للأداء.
سوء فهم `cache`: تقوم دالة `cache` من React بتخزين النتائج بناءً على وسائطها، ولكن هذا التخزين المؤقت يتم مسحه عادةً بين طلبات الخادم أو عند إعادة تحميل الصفحة بالكامل على العميل. إنه مصمم للتخزين المؤقت على مستوى الطلب، وليس لحالة طويلة الأمد من جانب العميل. للتخزين المؤقت المعقد من جانب العميل، والإبطال، والتعديل، لا تزال مكتبة جلب بيانات مخصصة خيارًا قويًا جدًا.

قائمة أفضل الممارسات

✅ احتضن الحدود: هيكل تطبيقك بمكونات `` و `` موضوعة جيدًا. فكر فيها كشبكات تعريفية للتعامل مع حالات التحميل والخطأ لأشجار فرعية بأكملها.
✅ مركّز جلب البيانات: أنشئ وحدة `api.js` مخصصة أو ما شابهها حيث تحدد دوال جلب البيانات المخبأة مؤقتًا. هذا يحافظ على نظافة مكوناتك واتساق منطق التخزين المؤقت الخاص بك.
✅ استخدم `use(Context)` بشكل استراتيجي: حدد المكونات الحساسة لتحديثات السياق المتكررة ولكنها تحتاج إلى البيانات بشكل شرطي فقط. هذه هي المرشحة الرئيسية لإعادة الهيكلة من `useContext` إلى `use`.
✅ فكر بالموارد: حوّل نموذجك الذهني من إدارة الحالة (`isLoading`، `data`، `error`) إلى استهلاك الموارد (Promises، Context). دع React وخطاف `use` يتعاملان مع انتقالات الحالة.
✅ تذكر القواعد (للخطافات الأخرى): خطاف `use` هو الاستثناء. لا تزال قواعد الخطافات الأصلية تنطبق على `useState`، `useEffect`، `useMemo`، إلخ. لا تبدأ بوضعها داخل عبارات `if`.

المستقبل هو `use`: مكونات الخادم وما بعدها

خطاف `use` ليس مجرد راحة من جانب العميل؛ إنه ركيزة أساسية لمكونات خادم React (RSCs). في بيئة RSC، يمكن تنفيذ المكون على الخادم. عندما يستدعي `use(fetch(...))`، يمكن للخادم حرفيًا إيقاف عرض هذا المكون مؤقتًا، والانتظار حتى يكتمل استعلام قاعدة البيانات أو استدعاء API، ثم استئناف العرض بالبيانات، وبث HTML النهائي إلى العميل.

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

واجهة برمجة تطبيقات `use` قابلة للتوسيع أيضًا. في المستقبل، يمكن استخدامها لفك تغليف القيم من مصادر غير متزامنة أخرى مثل Observables (على سبيل المثال، من RxJS) أو كائنات "thenable" مخصصة أخرى، مما يوحد بشكل أكبر كيفية تفاعل مكونات React مع البيانات والأحداث الخارجية.

الخلاصة: عصر جديد من تطوير React

خطاف `use` هو أكثر من مجرد واجهة برمجة تطبيقات جديدة؛ إنه دعوة لكتابة تطبيقات React أنظف وأكثر تعريفية وأفضل أداءً. من خلال دمج العمليات غير المتزامنة واستهلاك السياق مباشرة في تدفق العرض، فإنه يحل بأناقة المشاكل التي تطلبت أنماطًا معقدة وكودًا مكررًا لسنوات.

النقاط الرئيسية لكل مطور عالمي هي:

بالنسبة للـ Promises: يبسط `use` جلب البيانات بشكل كبير، لكنه يفرض استراتيجية تخزين مؤقت قوية واستخدامًا مناسبًا لـ Suspense و Error Boundaries.
بالنسبة للسياق: يوفر `use` تحسينًا قويًا للأداء من خلال تمكين الاشتراكات الشرطية، مما يمنع عمليات إعادة العرض غير الضرورية التي تعاني منها التطبيقات الكبيرة التي تستخدم `useContext`.
بالنسبة للهيكلة: يشجع على التحول نحو التفكير في المكونات كمستهلكين للموارد، مما يتيح لـ React إدارة انتقالات الحالة المعقدة المتضمنة في التحميل ومعالجة الأخطاء.

مع انتقالنا إلى عصر React 19 وما بعده، سيكون إتقان خطاف `use` ضروريًا. إنه يفتح طريقة أكثر بداهة وقوة لبناء واجهات مستخدم ديناميكية، ويسد الفجوة بين العميل والخادم ويمهد الطريق للجيل القادم من تطبيقات الويب.

ما هي أفكارك حول خطاف `use`؟ هل بدأت في تجربته؟ شارك تجاربك وأسئلتك ورؤيتك في التعليقات أدناه!