Translate(best-practices/performance) #82
Conversation
✅ Deploy Preview for vuejs-docs-ar ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
|
|
||
| - Consult [Ways of Using Vue](/guide/extras/ways-of-using-vue.html) to see how you can leverage Vue in different ways. | ||
| - استشر [طرق استخدام Vue](/guide/extras/ways-of-using-vue.html) لترى كيف يمكنك الاستفادة من Vue بطرق مختلفة. |
There was a problem hiding this comment.
من الأفضل استخدم اطلع على بدل استشر، لأن الاستشارة تكون للعاقل
|
|
||
| - Jason Miller discusses the types of web applications and their respective ideal implementation / delivery in [Application Holotypes](https://jasonformat.com/application-holotypes/). | ||
| - Jason Miller يناقش أنواع تطبيقات الويب والتنفيذ / التسليم المثالي لكل منها في [Application Holotypes](https://jasonformat.com/application-holotypes/). |
There was a problem hiding this comment.
حسب البحث وجدت أن معنى Application holotypes هو تطبيقات النموذجية أو النمطية
|
|
||
| For profiling load performance of production deployments: | ||
| لتحليل أداء الحمل لعمليات نشر الإنتاج: |
There was a problem hiding this comment.
من المستحسن استعمال تحميل بدل حمل
|
|
||
| If your use case is sensitive to page load performance, avoid shipping it as a pure client-side SPA. You want your server to be directly sending HTML containing the content the users want to see. Pure client-side rendering suffers from slow time-to-content. This can be mitigated with [Server-Side Rendering (SSR)](/guide/extras/ways-of-using-vue.html#fullstack-ssr) or [Static Site Generation (SSG)](/guide/extras/ways-of-using-vue.html#jamstack-ssg). Check out the [SSR Guide](/guide/scaling-up/ssr.html) to learn about performing SSR with Vue. If your app doesn't have rich interactivity requirements, you can also use a traditional backend server to render the HTML and enhance it with Vue on the client. | ||
| إذا كانت حالة الاستخدام لديك حساسة لأداء تحميل الصفحة ، فتجنب شحنها على أنها تطبيق أحادي صفحة SPA خالص من جانب العميل. تريد أن يرسل الخادم الخاص بك مباشرةً HTML يحتوي على المحتوى الذي يريد المستخدمون رؤيته. يعاني العرض الخالص من جانب العميل من بطء الوقت في الوصول إلى المحتوى. يمكن تخفيف ذلك باستخدام [التصيير من الخادم (SSR)](/guide/extras/ways-of-using-vue.html#fullstack-ssr) أو [إنشاء موقع ثابت (SSG)](/guide/extras/ways-of-using-vue.html#jamstack-ssg). تحقق من [دليل توجيه التصيير من الخادم SSR](/guide/scaling-up/ssr.html) لمعرفة المزيد حول أداء التصيير من الخادم SSR باستخدام Vue. إذا لم يكن لتطبيقك متطلبات تفاعلية غنية ، فيمكنك أيضًا استخدام خادم تقليدي لتصيير HTML وتحسينه باستخدام Vue على العميل. |
There was a problem hiding this comment.
حسب عديد المقالات العربية وجدت أن كلمة SSG ترجمت بتوليد الموقع الساكن
من الأفضل استخدام المستخدم بدل العميل و الخادوم بدل الخادم
|
|
||
| ### Bundle Size and Tree-shaking {#bundle-size-and-tree-shaking} | ||
| ### حجم الحزمة و Tree-shaking {#bundle-size-and-tree-shaking} |
There was a problem hiding this comment.
حسب توثيق React فقد ترجم مصطلح tree shaking بـعدم وجود شيفرات ميتة
|
|
||
| Vue's reactivity system is deep by default. While this makes state management intuitive, it does create a certain level of overhead when the data size is large, because every property access triggers proxy traps that perform dependency tracking. This typically becomes noticeable when dealing with large arrays of deeply nested objects, where a single render needs to access 100,000+ properties, so it should only affect very specific use cases. | ||
| نظام تفاعل Vue عميق بشكل افتراضي. على الرغم من أن هذا يجعل إدارة الحالة بديهية ، إلا أنها تنشئ مستوى معينًا من الحمل الزائد عندما يكون حجم البيانات كبيرًا ، لأن كل وصول إلى الخاصيات يقوم بتشغيل اعتراضات الوسيط التي تقوم بتتبع الإعتمادات. يصبح هذا ملحوظًا عادةً عند التعامل مع مصفوفات كبيرة من الكائنات المتداخلة بعمق ، حيث يحتاج التصيير الفردي إلى الوصول إلى أكثر من 100000 خاصية ، لذلك يجب أن يؤثر فقط على استخدام محدد للغاية. |
There was a problem hiding this comment.
نظام التفاعلية لـVue عميق بشكل افتراضي. على الرغم من أن هذا يجعل إدارة الحالة بديهية، إلا أنه dنشئ مستوى معينًا من الحمل الزائد عندما يكون حجم البيانات كبيرًا، لأن كل وصول إلى الخاصيات يقوم بتشغيل اعتراضات الوسيط التي تقوم بتتبع الإعتماديات. يصبح هذا ملحوظًا عادةً عند التعامل مع مصفوفات كبيرة من الكائنات المتداخلة بعمق ، حيث يحتاج التصيير الفردي إلى الوصول إلى أكثر من 100000 خاصية ، لذلك يجب أن يؤثر فقط على استخدام محدد للغاية.
|
|
||
| Vue does provide an escape hatch to opt-out of deep reactivity by using [`shallowRef()`](/api/reactivity-advanced.html#shallowref) and [`shallowReactive()`](/api/reactivity-advanced.html#shallowreactive). Shallow APIs create state that is reactive only at the root level, and exposes all nested objects untouched. This keeps nested property access fast, with the trade-off being that we must now treat all nested objects as immutable, and updates can only be triggered by replacing the root state: | ||
| توفر Vue فتحة هروب لإلغاء التفاعلات العميقة باستخدام [`shallowRef()`](/api/reactivity-advanced.html#shallowref) و [`shallowReactive()`](/api/reactivity-advanced.html#shallowreactive). تُنشئ واجهات برمجة التطبيقات الضحلة حالة تكون تفاعلية فقط على مستوى الجذر ، وتكشف جميع الكائنات المتداخلة كما هي. هذا يحافظ على الوصول السريع إلى الخاصيات المتداخلة ، مع مفاضلة أنه يجب علينا الآن التعامل مع جميع الكائنات المتداخلة على أنها غير قابلة للتغيير ، ولا يمكن تشغيل التحديثات إلا عن طريق استبدال حالة الجذر: |
There was a problem hiding this comment.
توفر Vue طريقة للإفلات من التفاعلات العميقة باستخدام ()shallowRef و ()shallowReactive. تُنشئ الواجهات البرمجية السطحية حالة تفاعلية فقط على مستوى الجذر ، وتبقي جميع الكائنات المتداخلة كما هي. هذا يحافظ على الوصول السريع إلى الخاصيات المتداخلة ، مع التضحية بأنه يجب علينا الآن التعامل مع جميع الكائنات المتداخلة على أنها غير قابلة للتغيير ، ولا يمكن تشغيل التحديثات إلا عن طريق استبدال حالة الجذر:
| @@ -168,8 +167,8 @@ shallowArray.value = [ | |||
| ] | |||
| ``` | |||
|
|
|||
| ### Avoid Unnecessary Component Abstractions {#avoid-unnecessary-component-abstractions} | |||
| ### تجنب تجريد المكونات الغير الضرورية {#avoid-unnecessary-component-abstractions} | |||
There was a problem hiding this comment.
تجنب التجريدات غير الضرورية للمكون
|
|
||
| Sometimes we may create [renderless components](/guide/components/slots.html#renderless-components) or higher-order components (i.e. components that render other components with extra props) for better abstraction or code organization. While there is nothing wrong with this, do keep in mind that component instances are much more expensive than plain DOM nodes, and creating too many of them due to abstraction patterns will incur performance costs. | ||
| في بعض الأحيان ، قد ننشئ [مكونات بدون عرض](/guide/components/slots.html#renderless-components) أو مكونات أعلي مرتبة (أي مكونات تقدم مكونات أخرى مع خاصيات إضافية) من أجل تجريد أفضل أو تنظيم للشيفرة. على الرغم من عدم وجود خطأ في هذا الأمر ، ضع في اعتبارك أن نسخ المكون أغلى بكثير من عقد DOM العادية ، وأن إنشاء الكثير منها بسبب أنماط التجريد سيكبد تكاليف الأداء. |
There was a problem hiding this comment.
في بعض الأحيان ، قد ننشئ مكونات عديمة التصيير أو مكونات ذات ترتيب أعلى (أي مكونات تُصيّر مكونات أخرى مع خاصيات إضافية) من أجل تجريد أفضل أو تنظيم للشيفرة. على الرغم من عدم وجود خطأ في هذا الأمر ، ضع في اعتبارك أن نسخ المكون أكثر تكلفة بكثير من عناصر الـDOM العادية ، وأن إنشاء الكثير منها باتباع أنماط التجريد سينجر عنه تكاليف في الأداء.
|
|
||
| Note that reducing only a few instances won't have noticeable effect, so don't sweat it if the component is rendered only a few times in the app. The best scenario to consider this optimization is again in large lists. Imagine a list of 100 items where each item component contains many child components. Removing one unnecessary component abstraction here could result in a reduction of hundreds of component instances. | ||
| لاحظ أن تقليل عدد قليل فقط من النسخ لن يكون له تأثير ملحوظ ، لذلك لا تقلق إذا عرض المكون عدة مرات فقط في التطبيق. أفضل سيناريو للنظر في هذا التحسين هو مرة أخرى في القوائم الكبيرة. تخيل قائمة تضم 100 عنصر حيث يحتوي كل مكون عنصر على العديد من المكونات الفرعية. قد تؤدي إزالة أحد عناصر التجريد غير الضرورية هنا إلى تقليل مئات نسخ المكون. |
There was a problem hiding this comment.
تجدر الملاحظة أن حذف عدد قليل فقط من النسخ لن يكون له تأثير ملحوظ ، لذلك لا تقلق إذا صُيِّر المكون عدة مرات فقط في التطبيق. أفضل سيناريو للنظر في هذا التحسين هو مرة أخرى في القوائم الكبيرة. تخيل قائمة تضم 100 عنصر حيث يحتوي كل مكون عنصر على العديد من المكونات الأبناء. قد تؤدي إزالة أحد تجريدات المكون غير الضرورية هنا إلى تقليل المئات من نسخ المكون.
|
@boussadjra شكرا على المراجعه |
No description provided.