פיתוח Options Page: היכן נשברת הלוגיקה של ההגדרות
פיתוח options page כמעט אף פעם לא נתקע בעיצוב — הוא נתקע במצב. המשתמש משנה הגדרה, הממשק מציג "נשמר", אבל הלוגיקה ברקע של התוסף ממשיכה לעבוד עם הערך הישן, כי הכתיבה הלכה לאחסון אחד, והקריאה מגיעה מאחר.
קלאסיקה: הערכים נמצאים גם באחסון מקומי וגם באחסון מסונכרן, כשהעדיפות ביניהם לא מוגדרת בשום מקום — ואחרי התקנה מחדש או כניסה במכשיר שני, עמוד ההגדרות של התוסף מציג מערכת אחת, בעוד שהתנהגות התוסף נקבעת על ידי אחרת.
הכשל הנפוץ השני — אובדן מצב בעת עדכון. Options page חי בהקשר נפרד, ואם הוא לא רשום לשינויים באחסון, הלשונית הפתוחה נשארת עם תמונת מצב מיושנת. המשתמש עורך שדה, שומר — ומוחק את מה שהספיק לשנות הקשר אחר.
סנכרון הגדרות התוסף מוסיף לכך מרוצים: שני מכשירים כותבים כמעט בו-זמנית, הכתיבה האחרונה מנצחת, והערך הביניים הולך לאיבוד בלי עקבות ובלי שגיאה ברורה בממשק.
הסוג השלישי של שגיאות ב-options page — הרשאות וגבולות. ההגדרה נשמרת, אבל לא מיושמת, כי לא הוענקה לה הרשאה או שהיא נשללה; או שהשדה מאומת רק בצד הלקוח, ולאחסון עובר ערך ששובר את הלוגיקה בהפעלה הבאה.
בנפרד צפות המיגרציות: סכימת ההגדרות משתנה בין גרסאות, מפתחות ישנים נשארים, חדשים נקראים כריקים, והתוסף עולה במצב ברירת מחדל — בשקט.
המחיר של כל זה אחד: השחרור נחסם לא בגלל באג בקוד, אלא מפני שהתנהגות ההגדרות בלתי צפויה ואינה משוחזרת אצל הבודק. מפרקים כיצד זה נסגר ברמת מודל האחסון, הרישומים והמיגרציות.
איך בנויה Options Page אמינה ומה היא נותנת
שכבות אחסון וריאקטיביות
הגדרות ההרחבה חיות בשני מישורים: אחסון מסונכרן (שורד התקנה מחדש ומועבר בין התקנים של המשתמש) ואחסון מקומי (נפחי יותר, אבל קשור למכונה). ערבוב שלהם במפתח אחד — סיבה טיפוסית לכך שחלק מהמשתמשים מאבדים את התצורה לאחר התקנה מחדש.
אנחנו מפרידים את השכבות באופן מפורש: לאחסון המסונכרן שמנו רק את מה שנכנס במגבלות ואינו מכיל נתונים רגישים, השאר — מקומית.
הריאקטיביות נבנית על מנוי לשינויים באחסון: דף ההגדרות וסקריפטים פעילים של ההרחבה קוראים ממקור אחד, ולכן עריכה בממשק מיושמת בלי הפעלה מחדש של הדפדפן. זה מסיר סוג של שגיאות "שמרתי, אבל לא הוחל" — המצב מתפצל רק בעת עריכה ישירה של האחסון בעקיפין ל-API.
ולידציה של קלט ומיגרציות
ולידציה — בגבול הכתיבה, ולא ברגע השימוש. הסכמה מתארת טיפוסים, טווחים וחובה של שדות; ערך לא תקין לא נכנס לאחסון, והטופס מציג סיבה ספציפית לסירוב. כך קונפיגורציה פגומה לא צפה אחרי שבוע בתרחיש עבודה, כשהמשתמש כבר שכח מה שינה.
מיגרציות — מגורסות: בעת ההפעלה ההרחבה משווה את גרסת הסכמה השמורה לנוכחית ומיישמת שרשרת טרנספורמציות. מפתחות ישנים משתנים בשמם, ערכים מותאמים לטיפוסים חדשים, שדות לא מוכרים נשמרים ולא נמחקים — חזרה לגרסה קודמת נשארת בטוחה.
השוואה של גישות למימוש
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| טופס עצמאי על DOM | סט קטן של שדות, מינימום תלויות | ולידציה וריאקטיביות ידניות, נפח הקוד גדל |
| שכבת קומפוננטות עם מודל ריאקטיבי | הרבה שדות קשורים, נראות מותנית | נדרשת משמעת במבנה המצב |
| גישה מונחית סכמה | הגדרות מתוארות באופן דקלרטיבי | דורש תכנון סכמה מראש |
| ספריות הגדרות מוכנות | התחלה מהירה, שדות טיפוסיים | קשה יותר להתאים אישית את לוגיקת המיגרציות |
לעמוד עם עשרות פרמטרים תלויים הדדית הגישה המונחית סכמה משתלמת: הוספת שדה — עריכת תיאור, ולא שלושה מקומות בקוד. אנחנו נשענים על Chrome Extensions API לאחסון ולמנויים — זה נותן התנהגות צפויה בענף הדפדפנים העדכני.
אפקט מדיד
- שיעור הסירובים "ההגדרות לא נשמרו" שואף לאפס: הכתיבה עוברת דרך שכבת ולידציה אחת.
- הזמן להוספת פרמטר חדש מתקצר פי כמה — משתנה תיאור הסכמה, ולא לוגיקת הטופס.
- המיגרציה עוברת בלי אובדן נתוני משתמש, חזרה לגרסה קודמת של ההרחבה לא שוברת את הקונפיגורציה.
- הריאקטיביות מסירה הפעלה מחדש של הדפדפן בעת שינוי הגדרות — תרחיש הבדיקה אורך שניות.
שלבי פיתוח Options Page כפתרון מלא
פיתוח options page אינו "לצייר טופס עם שדות", אלא לתכנן שכבת הגדרות שתשרוד החלפת גרסאות של התוסף, סנכרון בין מכשירים וחזרה לאחור. להלן התהליך שלפיו אנו מובילים פרויקט מה�audit של הלוגיקה הנוכחית ועד למסירת התיעוד.
- Audit של התוסף והלוגיקה הנוכחית של ההגדרות. בוחנים היכן נשמרים הפרמטרים כעת, כיצד הם נקראים בbackground script ובעמודים, ואילו ערכים מוזנים כברירת מחדל. מתעדים פערים בין ההתנהגות המוצהרת לזו בפועל.
- תכנון מודל ההגדרות. מפרידים את הפרמטרים לרמות: גלובליים, כאלה שמשויכים לפרופיל, וכאלה שמשויכים לאתר. מגדירים את סכמת האחסון, כללי המיזוג והעדיפויות — זה מסיר את מרבית הקונפליקטים העתידיים.
- אב טיפוס של ממשק עמוד ההגדרות. בונים את מבנה המדורים, ההתנהגות בעת קלט לא תקין, מצבי "נשמר / לא נשמר", ותרחישי איפוס לערכי ברירת מחדל.
- מימוש וחיבור לחלק הbackground. ההגדרות נכתבות לאחסון של התוסף ומיושמות ללא הפעלה מחדש — באמצעות הרשמה לשינויים, ולא באמצעות טעינה מלאה מחדש של העמודים.
- בדיקות של הגדרות התוסף. בודקים הגירה מגרסאות ישנות, התנהגות כאשר האחסון ריק או פגום, סנכרון בין חלונות, הרשאות גישה ותרחישי חזרה לאחור.
- מסירת תיעוד ותצורות. מוסרים תיאור של סכמת ההגדרות, ערכי ברירת מחדל, הוראות להוספת פרמטרים חדשים וסדר פרסום עדכונים.
כל שלב מסתיים בארטיפקט שניתן לבדוק: סכמת אחסון, אב טיפוס, מערך בדיקות אוטומטיות להגירה, והוראות לתמיכה. תארו את המשימה — נחזור עם הערכה ותוכנית עבור התוסף שלכם.
במה שונה Options Page מ-Popup ומלשונית ההגדרות?
Popup ו-Options Page פותרים משימות שונות, והבלבול ביניהם הוא סיבה נפוצה לעבודות מחדש בשלב התמיכה. Popup חי בדיוק כל עוד הוא פתוח: לחיצה על האייקון, פעולה קצרה, סגירה. ברגע שהחלון נסגר, המצב שלו וכל הפעולות שלא הושלמו נקטעים. לפעולות מהירות — להפעיל מצב, לראות סטטוס — זה מספיק. לטופס עם עשרה שדות, העלאת קובץ או אשף שלב-אחר-שלב — לא: המשתמש יאבד את מה שהזין.
Options Page הוא עמוד נפרד של התוסף, שחי בלשונית משלו ואינו תלוי אם ה-popup פתוח. כאן נכנסים טפסים ארוכים, קיבוץ הגדרות לפי מדורים, תצוגה מקדימה של שינויים ואימות שדות לפני שמירה.
ההבדל המרכזי בין עמודי התוסף הוא היכן נשמר המצב: popup נוצר מחדש בכל פתיחה, ואילו options page שומר את ההקשר כל עוד הלשונית פתוחה. לכן תרחישים עם ייבוא תצורה, בחירת תיקיות או הגדרת אינטגרציות כמעט תמיד עוברים לעמוד נפרד.
קיימת גם אפשרות שלישית — לשונית הגדרות המוטמעת בממשק של האתר או האפליקציה עצמה. היא נוחה כאשר ההגדרות חיות באופן הגיוני לצד המוצר הראשי ואינן דורשות הרשאות גישה של התוסף.
אבל אם פרמטר משפיע על התנהגות התוסף בלשוניות אחרות, לא נוח להחזיק אותו בתוך עמוד אחד: המשתמש לא יבין היכן לחפש את השליטה.
בפועל, הבחירה בין options page או popup קובעת לא רק נוחות, אלא גם את עלות התמיכה. לוגיקה שמפוזרת בין חלון קופץ לעמוד משוכפלת, ואת המצב יש לסנכרן ידנית. כאשר ההגדרות מרוכזות במקום אחד, הוספת פרמטר חדש היא עריכת טופס אחד וסכימת אחסון אחת, ולא חיפוש אחר שלושה קבצים.
בדיוק משום כך, כבר בהתחלה אנו מגדירים אילו תרחישים דורשים אינטראקציה ארוכה, ולפיהם מתכננים עמוד נפרד.
מקרה בוחן: כיצד תיקנו חוסר סנכרון בהגדרות בתוסף
הגיע אלינו תוסף לעבודה עם שירותי אינטרנט ארגוניים: כמה אלפי התקנות פעילות, ההגדרות נשמרו ב-chrome.storage.sync, ועמוד הפרמטרים כתב אותן ישירות מהטופס. המשתמשים התלוננו שהכללים שהוגדרו "מתאפסים" לאחר הפעלה מחדש של הדפדפן, וחלק מהפרופילים כלל לא הסתנכרנו בין מכשירים.
מה היה לפני
פניות לתמיכה בנושא הגדרות — כ-40 בחודש, מתוכן שליש בניסוח "הכול אופס". שמירת הטופס ארכה 3-5 שניות: כל שדה כתב לאחסון בקריאה נפרדת, ובמקרה של התנגשות גרסאות בין מכשירים ניצח זה שכתב אחרון.
סוג הכשל — אובדן שקט של נתוני משתמש: אין שגיאות בקונסולה, הממשק מציג "נשמר", אך המצב בפועל סוטה מהמצופה.
מה שינינו
בנינו מודל הגדרות אחיד: הטופס עובד עם מצב מקומי, והכתיבה מתבצעת בטרנזקציה אחת דרך תהליך הרקע של התוסף. הוספנו גרסאות לסכימה ומיגרציות בעת קריאת פרופילים ישנים, והתנגשויות סנכרון נפתרות לפי חותמת זמן של שינוי, ולא לפי סדר הכתיבה.
בנפרד סגרנו את תרחיש האיפוס: לפני דריסה, האחסון נבדק מול המצב הנוכחי, אי-ההתאמה מתועדת ביומן ומוצגת למשתמש.
מה קרה בסוף
פניות בנושא הגדרות ירדו ל-6-8 בחודש — בעיקר שאלות על הממשק, ולא על אובדן נתונים. השמירה התקצרה ל-200-400 מ"ש, מכיוון שבמקום עשרה כתיבות מפוזרות מתבצעת כתיבה אחת. סוג הכשל "אובדן שקט של הגדרות" נעלם לחלוטין: כל אי-התאמה נראית כעת ביומן ובממשק עצמו.
לצורך בקרת המצב חיברנו את Sentry — שגיאות סנכרון ומיגרציות מגיעות עם הקשר של גרסת הסכימה והמכשיר, ולכן רגרסיות נתפסות לפני פניות המשתמשים. בהמשך — תמיכה בתוסף: עדכוני סכימת ההגדרות, מיגרציות לפרופילים ישנים וניתוח אירועים לפי יומנים.
ספקות לפני ההתחלה: תאימות, חזרה לאחור, הרשאות גישה
לפני ההתחלה הלקוח בדרך כלל שואל שלוש שאלות: האם הדף החדש של ההגדרות ישבור את הגרסה שכבר שוחררה של התוסף, האם ניתן לחזור לאחור אם משהו ישתבש, ואיזו גישה נדרשת לצוות שלנו לתשתית שלו. אנו עונים לעניין.
תאימות דף ההגדרות. דף ההגדרות הוא הקשר מבודד: הוא מתקשר עם סקריפט הרקע ועם האחסון דרך החלפת הודעות תקנית, ולכן כתיבה מחדש של הממשק אינה משפיעה על לוגיקת הפעולה של התוסף עצמו.
אם כבר יש לכם משתמשים עם הגדרות שמורות, אנו מוסיפים מיגרציה של סכימת האחסון: מפתחות ישנים נקראים, מותאמים לפורמט החדש ונכתבים בחזרה. המשתמש אינו מבחין במעבר.
חזרה לאחור של הגדרות התוסף. כל מהדורה נבנית כארטיפקט נפרד, והגרסה הקודמת נשארת זמינה. חזרה לאחור היא פרסום של הבנייה הקודמת, ובמידת הצורך, מיגרציה הפוכה של האחסון.
אנו מתארים מראש אילו שינויים בסכימה הפיכים אוטומטית ואילו דורשים צעד ידני — כדי שההחלטה תתקבל לפני המהדורה, ולא ברגע התקלה.
הרשאות גישה לפיתוח. נדרשת גישה למאגר הקוד, לסביבת הבדיקות ולפאנל הפרסום בחנות התוספים. אנו עובדים דרך חשבונות נפרדים עם הרשאות מינימליות, ומפתחות הפרסום נשארים אצלכם. ההרשאות מבוטלות עם סיום העבודה.
מה אם כבר יש לנו דף הגדרות משלנו ואנחנו לא רוצים לאבד אותו?
אז אנחנו לא כותבים אותו מחדש מאפס, אלא מפרקים את המימוש הנוכחי: בוחנים כיצד בנויים האחסון והחלפת ההודעות, ומעבירים את הלוגיקה חלקים-חלקים. הדף הישן ממשיך לעבוד עד שהדף החדש יעבור בדיקה על בניית בדיקות — המעבר מתבצע במהדורה אחת.
מה אם יידרשו התאמות לאחר המסירה? אנו מעבירים קוד עם היסטוריית שינויים ותיאור של נקודות ההרחבה — ניתן להוסיף הגדרה חדשה בלי לסקור מחדש את כל הדף.
לאחר המסירה תקבלו לידיכם:
- קוד המקור של דף ההגדרות עם היסטוריית שינויים;
- סכימת האחסון וכללי המיגרציה של נתוני המשתמש;
- תיאור החלפת ההודעות בין הדף, הרקע והאחסון;
- הוראות בנייה ופרסום של גרסה חדשה;
- נוהל חזרה לאחור למהדורה הקודמת;
- תיעוד התוסף: מבנה, נקודות הרחבה, סדר העריכות;
- צ'קליסט בדיקה לפני הוצאה לחנות.
תארו את המשימה ואת מצב התוסף הנוכחי — נחזור עם הערכה ותוכנית עבודה.