تم إصدار Solana Web3.js كأحد مكتبات JavaScript الغنية بالميزات في نوفمبر من هذا العام بالإصدار 2.x. مقارنة بالإصدار 1.x السابق، تم إجراء تغييرات كبيرة في الإصدار الجديد. ستقوم هذه المقالة بتلخيص التغييرات الرئيسية.
على الرغم من أن الإصدار 2.x تم إصداره للتو وأن استخدامه لم ينتشر بعد، إلا أن العديد من المكتبات المستخدمة على نطاق واسع لم تقم بالتحويل، فإن فهم هذه التغييرات سيكون مفيدًا جدًا لعمليات الانتقال في المستقبل.
مقارنة النسخ
لا يمكن إنكار أن الإصدار القديم كان أكثر بساطة ووضوحًا في الاستخدام. يحتوي الإصدار 1.x فقط على حزمة واحدة @solana/web3.js، حيث يتم تركيز جميع الوظائف فيها. يعتمد على تصميم قائم على الفئات، ويغلف العديد من العمليات الشائعة الاستخدام. على سبيل المثال، توفر فئة Connection العشرات من الطرق، مما يغطي تقريبًا جميع الوظائف التي يحتاجها المطورون.
ومع ذلك، فإن هذا التصميم يسبب بعض المشكلات. على الرغم من أن الميزات التي يستخدمها المطورون فعليًا قد تمثل جزءًا صغيرًا فقط، إلا أن المكتبة الكاملة من التعليمات البرمجية يتم تنزيلها على جهاز المستخدم، وبسبب الحجم الكبير للشفرة، قد يستغرق ذلك بعض الوقت.
بالمقارنة، قامت النسخة 2.x بتقسيم مكتبة الشيفرة الأصلية إلى عدة وحدات صغيرة، مثل @solana/accounts، @solana/codecs، @solana/rpc، @solana/signers، @solana/transactions وغيرها. في الوقت نفسه، تخلت النسخة الجديدة عن التنفيذ القائم على الفئات، واعتمدت بشكل أكبر على أسلوب الوظائف الفردية، مما يساعد كثيرًا في تحسين بناء شيفرة JavaScript. سيتم حذف الشيفرة غير المستخدمة، ولن يتم تنزيلها على أجهزة المستخدمين. وفقًا للإحصاءات الرسمية، يمكن أن تحقق DApps التي تستخدم النسخة الجديدة تحسينًا في الحجم بنسبة تصل إلى 30%، وإذا تم استخدام عدد قليل من الوظائف فقط، قد تكون نسبة التحسين أعلى.
هذا يرفع من متطلبات جودة الوثائق لفريق Solana، وأصبح كيفية تمكين المطورين من العثور بسرعة على الوظائف المطلوبة موضوعًا مهمًا. يبدو أن أسماء الحزم تتمتع بدلالة جيدة، حيث يمكن فهم استخدامها بشكل عام من الاسم، مما يقلل إلى حد ما من صعوبة انتقال المطورين.
نظرًا لأنه تم إصداره مؤخرًا، فإن العديد من المشاريع لم تنتقل بعد. كما أن الأمثلة حول الإصدار 2.x على Solana Cookbook قليلة نسبيًا. علاوة على ذلك، تميل النسخة الجديدة إلى استخدام الميزات المدمجة في وقت التشغيل (مثل إنشاء أزواج المفاتيح)، ولكن الوثائق تفتقر إلى وصف لهذه الميزات، مما قد يؤدي إلى ارتباك بعض المطورين.
الخاصية المهمة الأخرى في إصدار 2.x هي عدم الاعتماد على أي شيء خارجي. قد لا تكون هذه النقطة مهمة للكثير من المستخدمين، ولكن من خلال الهجوم على سلسلة التوريد الذي حدث في بداية ديسمبر من هذا العام على إصدارات @solana/web3.js 1.95.5 و1.95.6، فإن المزيد من المدخلات والاعتمادات الخارجية ستزيد بشكل كبير من احتمالية حدوث أحداث أمنية. مع إصدار 2.x، قرر فريق تطوير Web3.js استخدام الوظائف الأصلية بشكل أكبر، وإلغاء الاعتماد الخارجي وإدخال Polyfills. قد تكون هناك تغييرات في المستقبل، ولكن على الأقل في الوقت الحالي، أزال إصدار 2.x جميع الاعتمادات الخارجية.
نقاط التغيير الهامة
الاتصال
في إصدار 1.x، توفر فئة Connection عددًا كبيرًا من الطرق. لكن الوظيفة الأساسية لها هي إنشاء مرسل طلبات من خلال تكوين عنوان طلب RPC، ثم استخدامه لإرسال طلبات متنوعة.
تم استخدام نسخة 2.x أسلوبًا أكثر وظيفية لتنفيذ هذه الميزة. على سبيل المثال، عند استدعاء sendAndConfirmTransaction لإرسال المعاملة، سيتم تلقائيًا بدء طلب HTTPS، وإنشاء اتصال WSS للاشتراك في حالة المعاملة، وعند تأكيد المعاملة سيتم إرجاع تجزئة المعاملة.
مفتاح زوج
لقد شهد الجزء المتعلق بالمفتاح العام والمفتاح الخاص تغييرات كبيرة أيضًا. لم تعد الفئتين Keypair و PublicKey اللتين كانتا شائعتين في الإصدار 1.x موجودتين، وتم استبدالهما ببعض الدوال.
على سبيل المثال، يمكنك الآن استخدام await generateKeyPair() لإنشاء زوج من المفاتيح، بدلاً من Keypair.generate() السابق. من الجدير بالذكر أن generateKeyPair الجديدة ترجع Promise، وذلك لأن التنفيذ الجديد يستفيد قدر الإمكان من Web Crypto API في JavaScript، باستخدام تنفيذ Ed25519 الأصلي. العديد من طرق Web Crypto API غير متزامنة. ومع ذلك، فإن هذه التغييرات ليست غير مقبولة، ففي نهاية عام 2024، أصبح مطورو JavaScript معتادين جداً على Promise.
إرسال المعاملة
لا توجد الفئتان Transaction و VersionedTransaction اللتان اعتاد عليهما مستخدمو الإصدار 1.x في الإصدار 2.x.
لم تعد الأساليب المتعلقة ببرنامج النظام المتاحة في الإصدار القديم موجودة، لذلك يجب استيراد الأساليب الثابتة في فئة SystemProgram من مكان آخر. على سبيل المثال، تحتاج تعليمات transfer إلى استدعاء الدالة getTransferSolInstruction من @solana-program/system.
نظرًا لعدم تقديم فئة بعد الآن، توفر Web3.js شكل pipe المستخدم بشكل شائع في البرمجة الوظيفية. يمكن للمطورين استخدام وظيفة pipe لتحقيق وظيفة التحويل الأصلية 1.x.
من الجدير بالذكر أن المعاملات لم تعد تُ Initiated عبر Connection، ولكن بدلاً من ذلك يتم إنشاء دالة فريدة من خلال مزود RPC المحدد، ثم يتم استدعاء هذه الدالة لبدء المعاملة. مقارنةً بالإصدار 1.x، زادت كمية الشيفرة، لكن أصبح مستوى التخصيص أعلى.
تبدأ الصفقة من خلال HTTPS RPC، ثم يتم تأكيد نتيجة المعاملة من خلال الاشتراك في WSS RPC. تعتمد الطريقة الجديدة بشكل كبير على WSS، وأعتقد أن تطبيق WSS سيصبح أكثر انتشارًا في المستقبل، مما يضع متطلبات أعلى على استقرار خدمات مزودي RPC.
رد فعل
جدير بالذكر أن مشروع @solana/web3.js يحتوي أيضًا على مكتبة تُسمى @solana/react، والتي توفر بعض React Hook وتأتي مع ميزات مدمجة مثل signIn.
ملخص
إن إصدار النسخة 2.x من @solana/web3.js يعكس التزام فريق Solana بالتطور والتحسين المستمر. إنه يوفر للمطورين وسيلة فعالة ومرنة وقابلة للتخصيص للتفاعل مع شبكة Solana، مما يساعد في تعزيز اعتماد هذه المنصة وتطورها.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 15
أعجبني
15
4
مشاركة
تعليق
0/400
MemeCoinSavant
· 07-15 21:50
وفقًا لنماذجي الإحصائية، فإن هذا التحول في النموذج يعتمد على ngl
إصدار النسخة 2.x من Solana Web3.js: إعادة بناء البرمجة الوظيفية تحقق تحسينات ملحوظة
Solana Web3.js 2.x版本:全新函数式编程体验
تم إصدار Solana Web3.js كأحد مكتبات JavaScript الغنية بالميزات في نوفمبر من هذا العام بالإصدار 2.x. مقارنة بالإصدار 1.x السابق، تم إجراء تغييرات كبيرة في الإصدار الجديد. ستقوم هذه المقالة بتلخيص التغييرات الرئيسية.
على الرغم من أن الإصدار 2.x تم إصداره للتو وأن استخدامه لم ينتشر بعد، إلا أن العديد من المكتبات المستخدمة على نطاق واسع لم تقم بالتحويل، فإن فهم هذه التغييرات سيكون مفيدًا جدًا لعمليات الانتقال في المستقبل.
مقارنة النسخ
لا يمكن إنكار أن الإصدار القديم كان أكثر بساطة ووضوحًا في الاستخدام. يحتوي الإصدار 1.x فقط على حزمة واحدة @solana/web3.js، حيث يتم تركيز جميع الوظائف فيها. يعتمد على تصميم قائم على الفئات، ويغلف العديد من العمليات الشائعة الاستخدام. على سبيل المثال، توفر فئة Connection العشرات من الطرق، مما يغطي تقريبًا جميع الوظائف التي يحتاجها المطورون.
ومع ذلك، فإن هذا التصميم يسبب بعض المشكلات. على الرغم من أن الميزات التي يستخدمها المطورون فعليًا قد تمثل جزءًا صغيرًا فقط، إلا أن المكتبة الكاملة من التعليمات البرمجية يتم تنزيلها على جهاز المستخدم، وبسبب الحجم الكبير للشفرة، قد يستغرق ذلك بعض الوقت.
بالمقارنة، قامت النسخة 2.x بتقسيم مكتبة الشيفرة الأصلية إلى عدة وحدات صغيرة، مثل @solana/accounts، @solana/codecs، @solana/rpc، @solana/signers، @solana/transactions وغيرها. في الوقت نفسه، تخلت النسخة الجديدة عن التنفيذ القائم على الفئات، واعتمدت بشكل أكبر على أسلوب الوظائف الفردية، مما يساعد كثيرًا في تحسين بناء شيفرة JavaScript. سيتم حذف الشيفرة غير المستخدمة، ولن يتم تنزيلها على أجهزة المستخدمين. وفقًا للإحصاءات الرسمية، يمكن أن تحقق DApps التي تستخدم النسخة الجديدة تحسينًا في الحجم بنسبة تصل إلى 30%، وإذا تم استخدام عدد قليل من الوظائف فقط، قد تكون نسبة التحسين أعلى.
هذا يرفع من متطلبات جودة الوثائق لفريق Solana، وأصبح كيفية تمكين المطورين من العثور بسرعة على الوظائف المطلوبة موضوعًا مهمًا. يبدو أن أسماء الحزم تتمتع بدلالة جيدة، حيث يمكن فهم استخدامها بشكل عام من الاسم، مما يقلل إلى حد ما من صعوبة انتقال المطورين.
نظرًا لأنه تم إصداره مؤخرًا، فإن العديد من المشاريع لم تنتقل بعد. كما أن الأمثلة حول الإصدار 2.x على Solana Cookbook قليلة نسبيًا. علاوة على ذلك، تميل النسخة الجديدة إلى استخدام الميزات المدمجة في وقت التشغيل (مثل إنشاء أزواج المفاتيح)، ولكن الوثائق تفتقر إلى وصف لهذه الميزات، مما قد يؤدي إلى ارتباك بعض المطورين.
الخاصية المهمة الأخرى في إصدار 2.x هي عدم الاعتماد على أي شيء خارجي. قد لا تكون هذه النقطة مهمة للكثير من المستخدمين، ولكن من خلال الهجوم على سلسلة التوريد الذي حدث في بداية ديسمبر من هذا العام على إصدارات @solana/web3.js 1.95.5 و1.95.6، فإن المزيد من المدخلات والاعتمادات الخارجية ستزيد بشكل كبير من احتمالية حدوث أحداث أمنية. مع إصدار 2.x، قرر فريق تطوير Web3.js استخدام الوظائف الأصلية بشكل أكبر، وإلغاء الاعتماد الخارجي وإدخال Polyfills. قد تكون هناك تغييرات في المستقبل، ولكن على الأقل في الوقت الحالي، أزال إصدار 2.x جميع الاعتمادات الخارجية.
نقاط التغيير الهامة
الاتصال
في إصدار 1.x، توفر فئة Connection عددًا كبيرًا من الطرق. لكن الوظيفة الأساسية لها هي إنشاء مرسل طلبات من خلال تكوين عنوان طلب RPC، ثم استخدامه لإرسال طلبات متنوعة.
تم استخدام نسخة 2.x أسلوبًا أكثر وظيفية لتنفيذ هذه الميزة. على سبيل المثال، عند استدعاء sendAndConfirmTransaction لإرسال المعاملة، سيتم تلقائيًا بدء طلب HTTPS، وإنشاء اتصال WSS للاشتراك في حالة المعاملة، وعند تأكيد المعاملة سيتم إرجاع تجزئة المعاملة.
مفتاح زوج
لقد شهد الجزء المتعلق بالمفتاح العام والمفتاح الخاص تغييرات كبيرة أيضًا. لم تعد الفئتين Keypair و PublicKey اللتين كانتا شائعتين في الإصدار 1.x موجودتين، وتم استبدالهما ببعض الدوال.
على سبيل المثال، يمكنك الآن استخدام await generateKeyPair() لإنشاء زوج من المفاتيح، بدلاً من Keypair.generate() السابق. من الجدير بالذكر أن generateKeyPair الجديدة ترجع Promise، وذلك لأن التنفيذ الجديد يستفيد قدر الإمكان من Web Crypto API في JavaScript، باستخدام تنفيذ Ed25519 الأصلي. العديد من طرق Web Crypto API غير متزامنة. ومع ذلك، فإن هذه التغييرات ليست غير مقبولة، ففي نهاية عام 2024، أصبح مطورو JavaScript معتادين جداً على Promise.
إرسال المعاملة
لا توجد الفئتان Transaction و VersionedTransaction اللتان اعتاد عليهما مستخدمو الإصدار 1.x في الإصدار 2.x.
لم تعد الأساليب المتعلقة ببرنامج النظام المتاحة في الإصدار القديم موجودة، لذلك يجب استيراد الأساليب الثابتة في فئة SystemProgram من مكان آخر. على سبيل المثال، تحتاج تعليمات transfer إلى استدعاء الدالة getTransferSolInstruction من @solana-program/system.
نظرًا لعدم تقديم فئة بعد الآن، توفر Web3.js شكل pipe المستخدم بشكل شائع في البرمجة الوظيفية. يمكن للمطورين استخدام وظيفة pipe لتحقيق وظيفة التحويل الأصلية 1.x.
من الجدير بالذكر أن المعاملات لم تعد تُ Initiated عبر Connection، ولكن بدلاً من ذلك يتم إنشاء دالة فريدة من خلال مزود RPC المحدد، ثم يتم استدعاء هذه الدالة لبدء المعاملة. مقارنةً بالإصدار 1.x، زادت كمية الشيفرة، لكن أصبح مستوى التخصيص أعلى.
تبدأ الصفقة من خلال HTTPS RPC، ثم يتم تأكيد نتيجة المعاملة من خلال الاشتراك في WSS RPC. تعتمد الطريقة الجديدة بشكل كبير على WSS، وأعتقد أن تطبيق WSS سيصبح أكثر انتشارًا في المستقبل، مما يضع متطلبات أعلى على استقرار خدمات مزودي RPC.
رد فعل
جدير بالذكر أن مشروع @solana/web3.js يحتوي أيضًا على مكتبة تُسمى @solana/react، والتي توفر بعض React Hook وتأتي مع ميزات مدمجة مثل signIn.
ملخص
إن إصدار النسخة 2.x من @solana/web3.js يعكس التزام فريق Solana بالتطور والتحسين المستمر. إنه يوفر للمطورين وسيلة فعالة ومرنة وقابلة للتخصيص للتفاعل مع شبكة Solana، مما يساعد في تعزيز اعتماد هذه المنصة وتطورها.