उत्पाद का विवरण हर आगंतुक के लिए समान हो सकता है, लेकिन साइन इन किए व्यक्ति का डिलीवरी पता अलग हो सकता है। पता खोजने में देरी के कारण क्या विवरण को भी रोकना चाहिए? काल्पनिक पुस्तक बिक्री पेज से हम साझा मुख्य पाठ और उपयोगकर्ता-विशिष्ट क्षेत्र अलग करने का निर्णय समझेंगे। यहाँ Astro के सर्वर आइलैंड की बात है; इनकी भूमिका ब्राउज़र में बटन चलाने वाले क्लाइंट आइलैंड से अलग है।
1. शुरुआती दस्तावेज और बाद में आने वाला क्षेत्र अलग करें
Astro के आधिकारिक सर्वर आइलैंड दस्तावेज बताते हैं कि किसी कंपोनेंट का सर्वर रेंडर टालकर परिणाम अलग अनुरोध में कैसे मिलता है। शुरुआती HTML में मुख्य पाठ और प्रतीक्षा के समय का प्रदर्शन होता है; अलग उत्तर आने पर वह क्षेत्र बदलता है। इसके लिए सर्वर पर अनुरोध संभालने वाला अडैप्टर चाहिए।
पुस्तक पेज में शीर्षक, लेखक और परिचय साझा दस्तावेज में रखें और केवल पते के सारांश को बाद में लाने का उम्मीदवार मानें। पता आने तक आगंतुक पुस्तक के बारे में पढ़ सकता है। लेकिन भुगतान बटन समझने के लिए कुल राशि जानना जरूरी हो, तो कीमत और भुगतान क्रिया का संबंध भी डिजाइन करें। दिखने वाले तत्वों को छोटे डिब्बों में बाँटने से कार्यों का विभाजन पूरा नहीं होता।
सफलता इस पर निर्भर है कि पहले क्या दिखता है। मुख्य पाठ लगभग खाली छोड़कर अधिकांश चीजें टालने पर आगंतुक कई लोडिंग संकेतकों की प्रतीक्षा करता है। पहले उन सवालों और सूचनाओं की अलग सूची बनाएँ जिनका उत्तर शुरुआती स्क्रीन दे और जो बाद में आ सकती हैं। सर्वर आइलैंड प्रतीक्षा की जगह बदलते हैं; डेटाबेस क्वेरी अपने आप तेज नहीं करते।
2. fallback को भी तैयार स्क्रीन का हिस्सा बनाएँ
यह छोटा उदाहरण उपयोग का रूप दिखाता है। मान लिया गया है कि UserDelivery कंपोनेंट और अडैप्टर अलग से लागू हैं।
---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
<p slot="fallback">डिलीवरी पते की जानकारी जाँची जा रही है।</p>
</UserDelivery>fallback क्षण भर दिखकर गायब होने वाली सजावट नहीं, वह शुरुआती सामग्री है जिसे आगंतुक सचमुच पढ़ता है। अंतिम पता कार्ड जितनी जगह रखें और बताएँ किसकी प्रतीक्षा है। जानकारी मिलने से पहले “डिलीवरी उपलब्ध” दिखाने पर वास्तविक उत्तर से टकराव हो सकता है। अनजान स्थिति और पुष्टि किए परिणाम को दृश्य रूप से भी अलग करें।
उदाहरण के लिए साइन इन न किए आगंतुक को “सहेजा डिलीवरी पता देखने के लिए साइन इन करें” कहना पड़ सकता है। धीमा नेटवर्क और साइन इन न होना अलग स्थितियाँ हैं। हर स्थिति के शब्द और आगे जाने का रास्ता अलग तय करने से विकास के दौरान रखे अस्थायी वाक्य लाइव स्क्रीन में रह जाने की आशंका घटती है।
3. डेटा की सीमाएँ छोटी रखें
कंपोनेंट बुलाते समय केवल दिखाने और खोजने के लिए जरूरी मान भेजें। एक नाम दिखाने के लिए पूरा ऑर्डर इतिहास भेजा जा रहा हो तो पहले डेटा-निर्भरता घटाने की गुंजाइश है। कुछ मान सार्वजनिक पाठ में हो सकते हैं, दूसरे केवल उपयोगकर्ता प्रमाणीकरण के बाद मिलने चाहिए। मान जाने का रास्ता और स्क्रीन पर दिखने की सीमा एक ही सूची में जाँचें।
सर्वर आइलैंड अनुरोध अलग निष्पादन संदर्भ में चलता है। लॉजिक को मौजूदा पेज का पता चाहिए तो मूल पेज से जरूरी पाथ स्पष्ट रूप से देने पर विचार करें। आइलैंड के भीतर अनुरोध URL को मूल उत्पाद पेज URL मानने से पेज-विशिष्ट सुझाव या लौटने के लिंक गलत बन सकते हैं। लागू करते समय डेवलपर टूल में वास्तविक अनुरोध पते जाँचना बेहतर है।
पुस्तक संख्या और उपयोगकर्ता की पहचान बताने वाली सूचना का काल्पनिक मामला लें। पुस्तक संख्या साझा सुझाव खोजने में लगे, जबकि उपयोगकर्ता की सूचना सर्वर पर प्रमाणीकरण स्थिति के अनुसार संभाली जाए। एन्क्रिप्टेड हस्तांतरण भी सर्वर की अधिकार जाँच का विकल्प नहीं है। इनपुट लेने की जगह और अंतिम पहुँच तय करने की जगह अलग दस्तावेजित करें।
4. कैश नीति स्क्रीन के दर्शक के अनुसार चुनें
साझा पुस्तक परिचय और निजी डिलीवरी पते पर एक जैसी कैश नीति लगाना कठिन है। MDN की HTTP कैश मार्गदर्शिका साझा और निजी कैश का अंतर समझाती है। पहले तय करें उत्तर किसे दिख सकता है, केवल यह नहीं कि डेटा समान है या नहीं।
दो परीक्षण खातों से समान पेज खोलकर जाँचें कि पहले का पता दूसरे को न दिखे। साइन आउट के बाद पीछे जाने या रीफ्रेश करने पर भी देखें। यह कैश सर्वर, ब्राउज़र और एप्लिकेशन के प्रमाणीकरण की संयुक्त कार्यप्रणाली के परिणाम की जाँच है। केवल कंपोनेंट फाइल पढ़कर सुरक्षा तय नहीं की जा सकती।
साझा पुस्तक सुझाव जैसे हिस्सों को भी सामग्री बदलने पर अपडेट का रास्ता चाहिए। तय करें पुराने सुझाव कुछ समय स्वीकारेंगे या प्रशासक के संशोधन के तुरंत बाद बदलेंगे। “कैश चालू करें” के बजाय विषय, रखने की जगह, स्वीकार्य पुरानापन और अमान्य करने की शर्तें लिखें ताकि दूसरे डेवलपर भी डिजाइन परख सकें।
5. धीमे कनेक्शन और विफलता पहले आजमाएँ
सामान्य कनेक्शन पर एक बार खोलकर पेज का मूल्यांकन न करें। पते का अनुरोध धीमा करें, विफल करें, साइन इन स्थिति बदलें और हर स्क्रीन देखें। क्या मुख्य पाठ पढ़ा जा सकता है, क्या लोडिंग क्षेत्र अगला बटन लगातार नीचे धकेलता है, और क्या विफल सूचना पर निर्भर क्रिया की जा सकती है?
| परीक्षण स्थिति | आगंतुक को कौन-सी स्थिति समझनी चाहिए |
|---|---|
| पता खोज धीमी | किसकी प्रतीक्षा है और क्या दूसरा पाठ पढ़ सकते हैं |
| प्रमाणीकरण नहीं | क्या साइन इन निर्देश और साझा विवरण दिखते हैं |
| खोज विफल | क्या खाली स्क्रीन के बजाय उबरने का रास्ता मिलता है |
| खाता बदलना | क्या पिछले उपयोगकर्ता की सूचना नहीं बची है |
कई आइलैंड एक-दूसरे के परिणाम की प्रतीक्षा करें तो विभाजन फिर जाँचें। पते के बाद शुल्क खोजकर फिर भुगतान निर्देश बनाने से क्रमिक प्रतीक्षा अनुरोध बन सकते हैं। संबंधित सूचना एक सर्वर कार्य में जोड़ना या उपयोगकर्ता के माँगने पर खोजना बेहतर हो सकता है। ज्यादा हिस्से होना अपने आप अच्छी संरचना नहीं है।
6. पहले और बाद के लाभ समान परिस्थितियों में तुलना करें
रिकॉर्ड में पहला पाठ दिखने, पता पूरी तरह दिखने, क्रिया संभव होने का समय और त्रुटि की स्थितियाँ अलग लिखें। शुरुआती दस्तावेज जल्दी दिखे, लेकिन पता कार्ड बहुत खिसके या भुगतान शुरू करना देर से हो, तो अनुभव दूसरी दिशा में बदल सकता है। केवल औसत न लिखें; धीमे मामलों में किसका इंतजार था, वह भी दर्ज करें।
आइलैंड चुनने का प्रश्न जितना स्पष्ट हो उतना अच्छा। “क्या यह स्थिर साइट है?” से अधिक उपयोगी है “यह सूचना देर से आए तब भी पुस्तक परिचय पहले पढ़ सकते हैं?” Astro की ऑन-डिमांड रेंडरिंग मार्गदर्शिका के साथ परिनियोजन वातावरण जाँचें और एक छोटे उपयोगकर्ता-विशिष्ट क्षेत्र से शुरू कर वास्तविक विफल स्थितियों तक जाँचें।