מדוע ממשקים בהתאמה אישית נשברים בעת עדכון הפלטפורמה
פקדים בהתאמה אישית נבנים כמעט תמיד על מניפולציות ישירות ב-DOM: המפתח מאתר את הצומת הרצוי לפי מחלקה או מבנה, תולה מטפלים, ומחליף את הסימון. כל עוד הפלטפורמה אינה משתנה, זה עובד.
אך הליבה מתעדכנת — שמות המחלקות משתנים, סדר הקינון, נקודות ההרכבה — והסלקטור שאתמול איתר את שדה הסינון, היום מחזיר רשימה ריקה. הטופס מפסיק להישלח בשקט, הכרטיס אינו טוען את הישויות המקושרות, והסינון מאבד את הערכים הנבחרים.
המחיר של קונפליקט כזה בעת עדכון גבוה מכפי שנדמה. הבעיה מתגלה לא ברגע השדרוג, אלא כעבור שבוע בפרודקשן, כשהמשתמשים כבר עובדים עם טפסים: בקשות אינן נוצרות, חלק מהנתונים אינו נשמר, ובלוגים — דממה, כי המטפל פשוט לא נקשר.
האבחון אורך ימים, כי פורמלית "שום דבר לא נשבר": עדכנו את הפלטפורמה, אבל נשבר הקוד שלנו שנאחז במבנה הפנימי שלה.
השורש הוא בכך שממשקים בהתאמה אישית פונים אל הפלטפורמה כמו אל עמוד זר, ולא כמו אל סט של קומפוננטות ציבוריות. כל פנייה לסלקטורים פנימיים, הרכבה ידנית של סימון מעל הפריסה התקנית, חלונות מודאליים ורשימות נפתחות משלנו — כל אלה הם חוזה מרומז עם גרסת הליבה, שאיש אינו מחויב לכבד.
פיתוח קומפוננטות UI של Bitrix24 על סט הקומפוננטות התקני הופך את התלות הזו על פיה: הממשק נבנה מרכיבים ציבוריים עם תמיכה מובטחת, ולא מניחושים לגבי המבנה הפנימי.
עדכון הפלטפורמה נוגע אז רק במקומות שבהם החלטנו בעצמנו לסטות מהתקן — וסטייה זו גלויה ומתועדת, ולא מרוחה על פני עשרות סלקטורים. נפרק כיצד זה נסגר בפועל.
מה נותן המעבר למערכת רכיבים אחידה של ממשק
מערכת רכיבים אחידה מסירה את סעיף ההוצאה המרכזי בצד הלקוח — בנייה מחדש של אותו רכיב בדיוק עבור כל מסך חדש. כפתור, חלון מודאלי, טבלה עם מסננים, רשימה נפתחת — כל אלה מפסיקים להיכתב מחדש ומתחברים כרכיב לשימוש חוזר עם התנהגות שכבר מוגדרת.
בפועל, שיעור הקוד לשימוש חוזר בממשק טיפוסי עולה מ-20–30% ל-70–80%, ומסך חדש נבנה מבלוקים מוכנים, ולא מדף חלק.
מהירות בניית הממשקים משתנה פי כמה: במקום שנדרשו קודם כמה ימים לעיצוב ותיקון מצבים, נשאר יום אחד להרכבה ולחיבור נתונים. הרכיב כבר יודע את מה שבדרך כלל שוכחים ברכיבים שנכתבו ידנית — מצבי טעינה ושגיאה, חסימה בזמן שליחה, התנהגות בתגובה ריקה, נגישות מהמקלדת ומרווחים תקינים לפי הגריד. זה לא "יפה יותר", זה פחות קוד שצריך לתחזק.
יחד עם הרכיבים שנכתבו ידנית נעלם סוג שלם של כשלים. מרווחים שמתפזרים בין אזורים, כפתור שבמסך אחד נחסם בזמן שליחה ובאחר לא, שדה שמאבד את הערך שהוזן בעת מעבר בין לשוניות — כל אלה הם תוצאה של כך שכל רכיב נכתב בנפרד ובדרכו שלו.
מערכת אחידה מגדירה התנהגות אחת לכל המסכים, והפער מפסיק להיות "מאפיין" והופך לשגיאה שנראית מיד.
סגנון ממשק אחיד מפסיק להיות משימה שצריך להדביק כל הזמן. תיקונים בטוקנים — צבע, רדיוסים, טיפוגרפיה — מיושמים על כל הרכיבים בבת אחת, ולא מתפזרים על פני עשרות קבצים. מפתח חדש בצוות מתחבר לכללים מוכנים, ולא מנסה להבין למה בשתי טפסים דומים יש לוגיקת ולידציה שונה.
בנפרד כדאי לקחת בחשבון שהמערכת חיה יחד עם הפלטפורמה: עדכוני רכיבים מגיעים מהענף המשותף, והתמיכה בממשק לא הופכת לתחזוקה של ספרייה משלנו. נדון במשימה שלכם — נחזור עם הערכה ותוכנית למעבר הממשק למערכת אחידה.
דרכי אינטגרציה של קומפוננטות: השוואת גישות
הטמעת קומפוננטות UI לעיתים רחוקות נעשית "הכול בבת אחת": הממשק של הפורטל חי את חייו שלו, ואף אחד לא מוכן לשבור תרחישי עבודה קיימים לשם אחידות. בפועל בוחרים בין שלוש אפשרויות אינטגרציה — מהחלפה מקומית של אלמנטים בודדים ועד להעברה מלאה של הממשק למערכת אחידה. ההבדל ביניהן אינו ב"יופי", אלא בהיקף הרגרסיה שיהיה צורך לכסות בבדיקות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| החלפה נקודתית של בקרות | יש צורך להסיר במהירות פערים בטפסים, בכפתורים, בשדות קלט בעמודים מסוימים | אלמנטים ישנים וחדשים מתקיימים זה לצד זה — חיבורים ויזואליים, סגנונות כפולים, חלק מהתרחישים נשארים על הקומפוננטות הקודמות |
| שכבה היברידית | הגירה הדרגתית לפי מדורים: עמודים חדשים מיד על מערכת אחידה, ישנים מתחברים דרך עטיפות | דורשת תמיכה בשתי מערכות במקביל, הצימודיות גדלה, יש להסיר את העטיפות ככל שמתקדמת ההעברה |
| העברה מלאה של הממשק | המערכת האחידה הופכת לסטנדרט מחייב לכל הצוות ולמשימות חדשות | היקף עבודה חד-פעמי גדול, הרצה מלאה של רגרסיה, סנכרון עם עדכוני הפלטפורמה |
החלפה נקודתית מניבה אפקט בתוך ימים ספורים: הבקרות מובאות לצורה אחידה, פערים בהתנהגות נעלמים, אך הממשק נשאר הטרוגני. שכבה היברידית — פשרה עבור פורטלים שאי אפשר לעצור: ההעברה מתבצעת לפי מדורים, כל שלב נבדק בנפרד.
העברה מלאה פותרת את הבעיה כולה, אך דורשת שהצוות יסכים על כללים: מערכת אחת, תבניות אחידות, בלי חריגים מקומיים.
בחירת האפשרות קובעת לא רק את היקף העבודה, אלא גם כיצד יתקיים בסיס הקוד בהמשך. אם משאירים את ההיבריד לנצח, התמיכה מתייקרת: כל עדכון של הפלטפורמה צריך לבדוק בשתי מערכות. לכן אנחנו תמיד מקבעים בתוכנית נקודת יציאה — מתי מסירים את העטיפות והממשק נשאר על מערכת אחידה.
שלבי יישום: מביקורת ממשק ועד מסירה לצוות
את העבודה מתחילים בספירה: אוספים את כל הכפתורים, השדות, הטבלאות, חלונות המודאל וההתראות שכבר קיימים בממשק, ומתעדים פערים — היכן אותו רכיב בדיוק בנוי בשלוש דרכים שונות, והיכן מצבי ריחוף ושגיאה כלל לא מתוארים.
בתום השלב — מפת רכיבים עם עדיפויות: מה נמצא בשימוש חוזר הכי הרבה ויניב אפקט מיידי, ומה מופיע במקום אחד בלבד ואינו נכנס לספרייה.
בהמשך מתכננים את מבנה הספרייה: מפרקים את הרכיבים לרמות, מסכמים על שמות מאפיינים, טוקנים של עיצוב וכללי הרכבה. זה השלב שבו זול יותר לטעות על הנייר מאשר לשכתב אחר כך עשרות מסכים.
- ביקורת ממשק. ספירת רכיבים, איתור כפילויות ופערים, מפת שימוש חוזר ועדיפויות.
- תכנון הספרייה. רמות רכיבים, מאפיינים אחידים, טוקנים של עיצוב, כללי קינון.
- מימוש. הרכבת רכיבים עם סט מלא של מצבים: רגיל, ריחוף, פוקוס, טעינה, שגיאה, ערך ריק.
- בדיקה על תרחישים. הרצה על מסכים אמיתיים — טפסים, רשימות, מסננים, פעולות מרובות, הרשאות גישה.
- תיעוד. עבור כל רכיב — דוגמאות שימוש, שילובים מותרים, מגבלות.
- מסירה לצוות. פירוט עם המפתחים והמעצבים, כללי עדכון הספרייה, סדר הוספת רכיבים חדשים.
- תמיכה לאחר ההשקה. ניתוח משוב, ניהול גרסאות של שינויים, כדי שעריכות לא ישברו מסכים שכבר נבנו.
נקודת המפתח — בדיקה על תרחישים: רכיב שנראה יפה בבידוד לעיתים קרובות מתפרק בטופס חי עם ולידציה, הרשאות ורשימות ארוכות. לכן מריצים לא אלמנטים בודדים, אלא נתיבי משתמש שלמים, ורק לאחר מכן מקבעים גרסה של הספרייה.
מסירה לצוות — לא מצגת מסכמת, אלא תהליך עבודה: המפתחים מקבלים גישה לקבצי המקור ולתיעוד, המעצבים — כללי הרחבה. בהמשך הספרייה מתקיימת באופן עצמאי, ואנחנו מתחברים בשינויים שנויים במחלוקת.
מה נשאר בפרויקט לאחר סיום העבודה
פרויקט ב-Bitrix24 UI Kit חי יותר מאשר ספרינט: מפתח חדש מגיע לקוד של מישהו אחר, ובלי כללים מעוגנים רכיבים מתחילים להיות משוכפלים ולסטות בסגנונות. לכן אנחנו סוגרים עבודה לא בהדגמת ממשק, אלא במסירת ערכה שלפיה צוות הלקוח ממשיך לפתח רכיבי UI של Bitrix24 באופן עצמאי.
- ספריית רכיבים — רכיבי ממשק שנאספו וטופוסו עם מבנה אחיד של מאפיינים: כפתורים, שדות, טבלאות, חלונות מודאליים, התראות. כל רכיב מכוסה במצבי טעינה, שגיאה ונתונים ריקים, ולא רק בתרחיש ה"מוצלח".
- כללי שימוש — מתי ניקח רכיב מוכן, מתי נרחיב אותו דרך עטיפה ולמה עריכה ישירה של קוד המקור אסורה. זה מה שמחזיק את הספרייה מלהתפשט לעשרה עותקים מקומיים.
- תיעוד רכיבים — תיאור מאפיינים, אירועים ומגבלות לצד הקוד, עם דוגמאות קריאה. המפתח לא צריך לקרוא את המימוש כדי להבין איך לשלב את הרכיב בעמוד שלו.
- דוגמאות אינטגרציה — עמודי דוגמה עובדים שבהם הרכיבים מחוברים לנתונים, טפסים והרשאות גישה. לפיהם הכי מהר משחזרים תרחיש נדרש במדור חדש.
- תקנון תמיכה ועדכון — סדר הוספת רכיבים, כללי גרסאות, ענפים וקריטריונים שבהם שינוי נחשב לתואם לאחור.
- תרשים בנייה ופרסום — תצורה שלפיה הספרייה נבנית ומתחברת לפרויקט, כדי שעדכון לא ישבור מדורים שכבר עובדים.
- יומן החלטות — פשרות מעוגנות: למה נבחר הרכב מאפיינים כזה, אילו אפשרויות נדחו ומה לעשות בעת התנגשות עם עדכון הפלטפורמה.
ערכה כזו מסירה את הסיכון המרכזי — תלות הפרויקט במבצע מסוים. צוות הלקוח רואה לא רק את התוצאה, אלא גם את ההיגיון שלפיו היא נבנתה, ויכול לפתח את הממשק בלעדינו. אם צריך להעריך את היקף המסירה בפרויקט שלכם — תארו את המשימה, נחזור עם תוכנית והרכב ארטיפקטים.
מקרה בוחן: איך הממשק של הפורטל הפסיק להישבר אחרי עדכונים
מה היה לפני
הפורטל של הלקוח — מערכת פנימית עבור כמה אלפי עובדים: בקשות, אישורים, ספרי עזר, דוחות. הממשק נבנה על עריכות ישירות בתבניות וסקריפטים נקודתיים מעל הליבה. כל שדרוג של הפלטפורמה הפך להגרלה: אחרי העדכון נשברו מסננים ברשימות, נפלה הוולידציה בטפסים, חלונות מודאליים "זרמו".
לפי הסטטיסטיקה שלנו של פניות, אחרי עדכון נוסף נשברו 6-8 מסכים מתוך 40 — וזה רק אלה שהמשתמשים שמו לב אליהם. על בירור ותיקון הושקעו משלושה ימים, כאשר התיקונים בוצעו באותן תבניות שנשברו שוב בעדכון הבא.
מה שינו
העברנו את הממשק לשכבת רכיבי UI משלנו מעל Bitrix24 UI Kit — ספריית React שהספק תומך בה יחד עם הפלטפורמה. טפסים, טבלאות, מסננים וחלונות מודאליים הפכו לרכיבים לשימוש חוזר עם חוזה אחיד: התצוגה והלוגיקה חיים במקום אחד, והעמודים נבנים מבלוקים מוכנים. עדכון הליבה כבר לא פוגע ברכיבים שלנו — ה-API שלהם אינו תלוי בתבניות הפנימיות של הפורטל.
מה נהיה
שיעור המסכים השבורים בשדרוג ירד מ-6-8 לאפס: במשך כמה מחזורי עדכונים אף רכיב לא דרש תיקון. הזמן לשחזור אחרי עדכון הצטמצם משלושה ימים לכמה שעות — וגם זה לבדיקה, לא לתיקון.
הוצאת טופס חדש הואצה משבועיים לשניים-שלושה ימים: המפתח בונה אותו משדות מוכנים וולידציה, ולא כותב את התצוגה מחדש. המשתמשים הפסיקו לחכות "עד שיתקנו אחרי העדכון" — הממשק מתנהג באותו אופן לפני ואחרי השדרוג.
במה שונה פיתוח רכיבי UI של Bitrix24 מתיקון תבנית
תיקון תבנית משנה את מה שהמשתמש רואה בעמוד מסוים: את הסימון, סדר הבלוקים, הכיתובים, הסגנונות. רכיב קובע כיצד ממשק זה נבנה ומתנהג כאשר הנתונים משתנים — אילו מצבים הוא יודע להציג, כיצד הוא מגיב לשגיאת טעינה, מה קורה כאשר מתקבלת תשובה ריקה.
תבנית מתארת את התוצאה פעם אחת, רכיב מגדיר את הכללים שלפיהם התוצאה משוחזרת בכל העמודים שבהם הוא מחובר.
ההבדל מתגלה בתיקון השני או השלישי. כל עוד יש מעט תיקונים, התבנית זולה ומהירה יותר: תיקנו את הסימון — המשימה סגורה. אבל ברגע שאותו בלוק נדרש גם בחמישה עמודים נוספים, כל תיקון צריך לחזור על עצמו, והפערים בין העותקים מצטברים. רכיב במקום הזה מחזיר את ההשקעה: שינוי במקום אחד מתפשט לכל החיבורים, וההתנהגות נשארת אחידה.
פיתוח רכיבי UI של Bitrix24 עוסק במצב, ולא במראה החיצוני. רכיב מתאר מה להציג בזמן הטעינה, כיצד נראית תשובה שהגיעה חלקית, לאן מוצגת הודעת השגיאה וכיצד הבלוק מתנהג במסך צר.
תבנית אינה מבחינה בין תרחישים כאלה: היא מקבלת נתונים מוכנים מראש ומציירת אותם באותו אופן, ולכן כשל בטעינה נראה כאזור ריק ללא הסבר.
מתי תבנית מספיקה: עמוד חד-פעמי, סימון ייחודי, הנתונים מגיעים בשלמותם ואינם משתנים, שימוש חוזר אינו מתוכנן. כאן רכיב יוסיף שכבה מיותרת ללא תועלת. מתי נדרש רכיב: הבלוק חוזר על עצמו, יש לו כמה מצבים, הוא מקבל נתונים ממקור חיצוני או צריך לעבוד באופן זהה במדורים שונים. הסימן פשוט — אם בתיקון הבא אתם שוב פותחים את אותו קובץ תבנית, סימן שהגיע הזמן להוציא את הלוגיקה.
מסקנה מעשית: תבנית ורכיב אינם מתחרים, הם פותרים משימות ברמות שונות. תיקון תבנית סוגר את הסימפטום בעמוד אחד, רכיב מסיר את הסיבה — שכפול הלוגיקה ופערים בהתנהגות בין עמודים.
ספקות טכניים לפני תחילת העבודה
לפני תחילת העבודה עולה בדרך כלל אותו סט שאלות: כיצד יסתדרו הרכיבים החדשים עם הליבה הנוכחית, האם הם ישברו את הממשק בדפדפנים של העובדים והאם לא תיפגע响应יות הפורטל. להלן — תשובות ענייניות, בלי מילים כלליות.
האם הרכיבים יעבדו על הגרסה הנוכחית של המוצר שלנו?
כן, אם הליבה נמצאת בענף נתמך עדכני. אנו בודקים את הגרסה לפני תחילת העבודה ומקבעים אותה בתוכנית העבודה: ספריית הרכיבים מתפתחת יחד עם הפלטפורמה, ובליבה מיושנת חלק מהאלמנטים פשוט לא ייבנו.
אם הגרסה מפגרת, קודם מתכננים עדכון — זהו שלב נפרד עם בדיקת הרחבות והתאמות אישיות, כדי שהעדכון לא יגרור אחריו הפתעות.
מה עם דפדפנים ישנים אצל העובדים?
הרכיבים נבנים עבור דפדפנים מודרניים, ולכן עבור גרסאות מיושנות אנו מוסיפים פוליפילים ובודקים תרחישים מרכזיים ידנית. אם בחברה יש מלאי קבוע של מחשבים ישנים, אנו מריצים את הממשק עליהם מראש ומטפלים בחוסר התאימות, או מתאמים מעבר לדפדפן נתמך — אבל לא משאירים זאת ל"מזל".
האם הפורטל לא יהפוך לאיטי יותר?
הבנייה מתבצעת עם פיצול קוד לפי נתיבים: לדפדפן מגיע רק מה שנדרש במסך הנוכחי, ולא כל סט הרכיבים בבת אחת. בלוקים כבדים נטענים לפי דרישה, והמצב נשמר במטמון.
בפועל זה נותן עומס דומה או קטן יותר על העמוד מאשר בפתרונות שנכתבו באופן עצמאי — אבל אנחנו תמיד מודדים על הנתונים שלכם, ולא על דמו.
האם ניתן לחזור אחורה אם משהו ישתבש?
כן. העבודה מתבצעת בענפים נפרדים, השחרור — בשלבים, וכל שלב ניתן להסיר בלי לאבד את מה שכבר נעשה. לפני העלייה לאוויר אנו מקבעים נקודת חזרה, ולכן שחרור כושל מתגלגל חזרה למצב תקין, ולא הופך לשחזור חירום.
אם נותרו שאלות לגבי המערך שלכם — בנוגע להרשאות, הרחבות או אינטגרציות, — תארו את המשימה, ונחזור עם הערכה ותוכנית.
נדון במשימה שלכם ונחזור עם תוכנית עבודה
כדי לחזור עם תוכנית עבודה ולא עם מילים כלליות, אנחנו זקוקים לנתוני קלט לגבי המשימה שלכם. ככל שהקלט מדויק יותר, כך ההערכה של לוחות הזמנים והרכב העבודה תהיה מדויקת יותר — וכך יהיו פחות הבהרות כבר בשלב תחילת הפרויקט.
מה עוזר לנו להרכיב הצעה במהירות:
- רשימת מסכים ותרחישים שבהם נדרשים רכיבים: כרטיסים, טבלאות, טפסים, מסננים, חלונות מודאליים — עם ציון אילו מהם כבר קיימים במערך הסטנדרטי ואילו יהיה צורך להרכיב.
- קישור לממשק הנוכחי או לסקיצות עיצוב: אפילו שרטוטים ראשוניים מסירים מחצית מהשאלות בנוגע להרכב ולהתנהגות של האלמנטים.
- דרישות למצבים: טעינה, תוצאה ריקה, שגיאה, הרשאות גישה — הם קובעים את היקף העבודה לא פחות מהמסכים עצמם.
- נתונים ואינטגרציות: אילו ישויות אנחנו מושכים, מאיפה, והאם נדרשת עבודה עם REST ושירותים חיצוניים.
- מגבלות בלוחות זמנים וסדרי עדיפויות: מה קריטי להשקה ומה ניתן לדחות לשלב השני.
- גישות למאגר הקוד ולסביבת הבדיקות — אם הפרויקט כבר בעיצומו, זה מזרז את ההתחלה בכמה ימים.
בתגובה תקבלו פירוט לפי שלבים עם הערכת מאמץ העבודה, רשימת רכיבים עם סדרי עדיפויות, תרשים של השימוש החוזר בהם ותוכנית עבודה עם נקודות ביקורת. בנפרד נציין את הסיכונים: היכן יידרש תיאום עם הקוד הקיים והיכן עשויים להיות פערים בציפיות לגבי ההתנהגות.
תארו את המשימה בצורה הנוחה לכם — כרשימה, כקישור לסקיצות עיצוב או כהודעה קצרה. נלמד את נתוני הקלט ונחזור עם הערכה ותוכנית עבודה.