לא מזמן כתבתי כאן על נתיבי SPA שצריכים להחזיר תגובת HTTP תקינה. השבוע חזרתי לאותה נקודת מפגש בין הדפדפן לשרת, וגיליתי שיש לה עוד שכבה: גם כשקישור מחזיר `200` והכותרת שלו נכונה, התגובה הראשונית יכולה להכיל רק תקציר של המאמר.
בפורטפוליו שלי, React ידע להציג את הכתבה המלאה אחרי טעינת האפליקציה. מסמכי ה־HTML שנוצרו בזמן ה־build כבר כללו כותרת, תיאור, קישורים ו־metadata. אבל גוף הכתבה עצמו נשאר תלוי בהרצת JavaScript. התיקון האחרון הכניס את תוכן המאמרים למסמכים הסטטיים, בעברית ובאנגלית.
תגובה מוצלחת אינה בהכרח תשובה מלאה
אפשר לבדוק כתבה בדפדפן ולקבל תחושה שהכול תקין: הכותרת מופיעה, הפסקאות נטענות והקוד מוצג. אלא שהדפדפן כבר עשה עבודה נוספת אחרי קבלת ה־HTML. הוא הוריד את האפליקציה והריץ אותה.
לקוח שקורא רק את תגובת השרת מקבל תמונה אחרת. הוא עשוי לראות את שם המאמר ואת התקציר, אבל לא את ההסבר, הדוגמאות או המסקנה. גם משתמש ש־JavaScript אינו זמין אצלו נשאר עם אותה שכבה מצומצמת.
לכן הפרדתי בין שלוש שאלות: האם הכתובת קיימת, האם ה־metadata מתאים לה, והאם התוכן העיקרי נמצא בתגובה עצמה. תשובה חיובית לשתי הראשונות אינה מוכיחה את השלישית.
להשתמש במקור התוכן שכבר קיים
לא רציתי לתחזק עותק ידני נוסף של כל כתבה. מקור התוכן נשאר זוג קובצי MDX, אחד לכל שפה.
סקריפט יצירת הנתיבים קורא עכשיו את הקבצים האלה בזמן הבנייה ומרכיב מהם גוף HTML. התוצאה נשמרת במיפוי לפי שילוב של slug ושפה. כשנוצר מסמך של מאמר באנגלית, נבחר הגוף האנגלי; בנתיב העברי נבחר הגוף העברי.
זה פרט קטן עם משמעות מעשית. מסמך בעל כותרת עברית וגוף אנגלי יכול לעבור בדיקת כותרת ולפספס את החוזה עם הקורא. בחירת השפה צריכה לחול על הכתבה עצמה, לא רק על התיאור שלה.
פתרון ממוקד עם גבול ברור
הממיר שנוסף מטפל בפסקאות, כותרות, רשימות, ציטוטים ובלוקי קוד, ומבצע escaping לטקסט לפני הכנסתו ל־HTML. כך סימנים כמו סוגריים זוויתיים בדוגמת קוד אינם הופכים בטעות לתגיות.
אבל הוא אינו מנוע MDX מלא. רכיבים אינטראקטיביים אינם מרונדרים בשכבה הסטטית, וגם עיצוב inline כמו קישורים והדגשות אינו מקבל את מלוא הפרשנות של Markdown. זה גבול שחשוב להכיר, במיוחד אם בהמשך הכתיבה תשתמש בתחביר עשיר יותר.
ההפרדה הזאת מחדדת כלל עריכתי: ההסבר צריך לעמוד בפני עצמו. הדגמה אינטראקטיבית יכולה לעזור לקורא להבין, אבל פסקאות המאמר צריכות לשאת את הלקח גם כשההדגמה אינה פועלת.
לבדוק את המסמך שנוצר
ל־build נוספה בדיקה שסופרת מילים בשכבת התוכן הסטטית. למסמך מאמר נדרש סף של 350 מילים. המטרה היא לתפוס מצב שבו נוצר שוב עמוד שמכיל רק כותרת וכמה משפטים.
זו בדיקת שלמות בסיסית, לא מדד איכות. טקסט ארוך יכול להיות כפול, בשפה הלא נכונה או חסר דוגמה חשובה. גם הספירה כוללת את מעטפת התצוגה הסטטית, ולכן היא אינה מוכיחה שכל מילה במקור נשמרה.
לבדיקה הזאת צריך לצרף קריאה של הפלט: כותרת, פסקה מהגוף, דוגמת קוד כשיש, וסיום המאמר. בדיקת HTML ובדיקת דפדפן בוחנות שלבים שונים במסירה.
שתי שכבות שצריכות להישאר עקביות
האפליקציה עדיין מסירה את התצוגה הסטטית בעת הפעלתה ומרנדרת את ממשק React. זה אינו hydration של אותו עץ HTML. קיימות שתי דרכי תצוגה שניזונות מאותו מקור תוכן, אבל משתמשות במנגנוני רינדור שונים.
היתרון הוא שהתגובה הראשונית נעשית שימושית יותר. העלות היא צורך לשמור על התאמה בין השכבות ולבדוק את רגע המעבר ביניהן. עצם הוספת התוכן אינה מוכיחה שיפור בדירוג חיפוש או במדדי ביצועים; טענות כאלה דורשות מדידה נפרדת.
מה אני לוקח מהתיקון
תוכן ציבורי מתחיל בתגובה שהשרת שולח. כותרת נכונה וקוד סטטוס תקין הם חלק מהמסירה, אבל גם הטקסט שהקורא הגיע בשבילו צריך להיות שם.
הבדיקה שאוסיף מעכשיו היא פשוטה: לקרוא את ה־HTML לפני שהאפליקציה מקבלת הזדמנות להשלים אותו. כך אפשר לראות איזה מידע באמת נמסר, ולהגדיר במדויק מה JavaScript מוסיף לחוויה.