# عرض تجريبي صغير يعيد إظهار سبب سلاسة التحرير التعاوني على طريقة Figma

- Link: https://qiita.com/keishin_nishiura/items/b13d72afb085891e4fc9?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items
- Discussion: https://startupxo.com/ar/1251/
- Posted by startupxo at 2026-11-08T00:45:44.982Z
- 0 points, 1 comment, kind story, origin curated
- Written in ko, machine translated to ar

## Summary

- عندما يحرر عدة أشخاص الشاشة نفسها، تظهر إجراءاتك فوراً دون انتظار رد الخادم، ولا يعاد رسم الشاشة عند تأكيد التغييرات، لتجنب القفزات المرئية. أنشأ نيشيورا، المطور في شركة Soyi Co., Ltd.، هذا العرض بتبسيط تصميم من عام 2019 منشور على مدونة Figma الرسمية، وهو يختلف عن التنفيذ الداخلي الفعلي لـ Figma.
- عند إيقاف هذه المعالجة في العرض، تتأخر العقدة المسحوبة عن مؤشر الفأرة وتتحرك بصورة متقطعة. بلغ وسيط زمن الذهاب والإياب إلى الخادم الذي قاسه الكاتب نحو 5ms محلياً ونحو 150ms للعرض على Render، وكان الفرق أوضح كلما زاد التأخير.
- نظراً إلى وجود خادم واحد فقط، تُعالج التغييرات حسب ترتيب وصولها. وإذا عُدلت الخاصية نفسها في الوقت نفسه، تبقى القيمة التي عولجت لاحقاً. لا تُرفض إلا التغييرات التي تنشئ بنية دائرية يشير فيها العنصر الأب والابن إلى بعضهما، وتُعاد شاشة ذلك المستخدم إلى حالتها السابقة.
- خلص الكاتب إلى أن استخدام ترتيب الوصول وحده دون تسجيل الطوابع الزمنية لا يصح إلا بافتراض أن خادماً واحداً يحدد الترتيب. وإذا كان هناك خادمان أو أكثر، فلا بد من آلية أخرى لتحديد الترتيب.

## Sources

- Qiita: https://qiita.com/keishin_nishiura/items/b13d72afb085891e4fc9?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

## Comments (1)

- **startupxo** (editorial), 0 points, 2026-11-08T00:45:44.982Z, #c524
  O: إذا كنت تطور واجهات تعاونية، فقد يفيدك مقارنة استجابة السحب في العرض التجريبي على الويب مع تشغيل منع قفز الشاشة وإيقافه.
  X: لا يميز العرض التجريبي بين قيم الترتيب المتكررة عند إدراج عناصر في الوقت نفسه بين العنصرين نفسيهما، لذا يلزم إجراء منفصل لتحديد الترتيب عند التطبيق الفعلي.

JSON: https://startupxo.com/api/v1/item.json?id=1251&lang=ar