פיתוח רכיבי UI ב-Bitrix24 UI Kit (React)

פיתוח רכיבי UI ב-Bitrix24: היכן הממשק נשבר

ממשק הפורטל של Bitrix24 נשבר לא בשלב הבנייה (וורסטוק), אלא במפגש שבין הלוגיקות: אותו בלוק נתונים בדיוק מצויר על ידי שלושה רכיבים שונים, כל אחד עם עותק משלו של כללי התצוגה. מבצעים תיקון באחד — השניים האחרים ממשיכים להציג את המצב הישן, והמשתמש רואה אי-התאמה בכרטיס העסקה או בפיד. זהו חוסר סנכרון קלאסי שמצטבר במשך חודשים ומתבטא כ"פעם עובד, פעם לא".

כפילות הלוגיקה פוגעת בתחזוקה חזק יותר ממה שנדמה. כאשר סינון, עימוד והרשאות גישה משוכפלים ברכיבים מותאמים אישית, כל שינוי בכלל עסקי חייב להתבצע בכל מקום בנפרד. פספסתם אחד — קיבלתם התנהגות שונה למסכים דומים ותור של משימות ל"לתקן גם כאן".

קטגוריה נפרדת של בעיות היא תאימות לעדכוני הליבה. הפורטל מתעדכן, החוזים ומבנה הנתונים משתנים, ורכיבים מותאמים אישית שתלויים בפרטים פנימיים מפסיקים לקבל ערכים תקינים. מבחוץ זה נראה כ"הבנייה התפרקה", בפועל — ממשק Bitrix24 שבור ברמת חילופי הנתונים.

אנחנו מפרקים ממשקים כאלה לפי שכבות: היכן מקור הנתונים המשותף, היכן הרכיב הניתן לשימוש חוזר, והיכן המקום להרחבה ללא תיקון הליבה. בהמשך — כיצד זה נסגר בפועל.

מה נותנת ספריית רכיבים לשימוש חוזר

ספריית רכיבים לשימוש חוזר היא לא "תיקייה עם כפתורים", אלא חוזה קבוע בין העיצוב לפיתוח. כל רכיב מתאר פעם אחת את ההתנהגות: מצבי טעינה ושגיאה, פוקוס, ניווט מקלדת, נקודות שבירה אדפטיביות, טיפול בטקסטים ארוכים ובנתונים ריקים.

לאחר מכן הממשק נבנה מבלוקים מוכנים, וקטע חדש בפורטל או באזור האישי מופיע בתוך ימים ולא שבועות — מהירות הרכבת הממשק גדלה באופן משמעותי, כי המהנדס לא כותב מחדש טבלה, טופס וחלון מודאלי עבור כל משימה.

ערכת UI אחידה מסירה קטגוריה שלמה של שגיאות פריסה, ולא באגים בודדים. כאשר הסימון, הריווח וההתנהגות בעת הצפה מוגדרים במקום אחד, הפערים בין העמודים נעלמים מעצם הגדרתם: תיקון ברכיב מיושם מיד בכל מקומות השימוש.

זה גם מסיר פגמים טיפוסיים — "נשבר במסך צר", "הכפתור לא פעיל אבל מגיב ללחיצה", "הרמז מכסה את השדה" — פשוט אין להם היכן לחזור על עצמם.

אפקט נפרד הוא תמיכה צפויה מראש. שינוי בדרישות לממשק הופך לתיקון ממוקד ברכיב ולעדכון גרסה של הספרייה, ולא לרוויזיה של עשרות תבניות. אנחנו מנהלים גרסאות של הערכה, מנהלים יומן שינויים ושומרים על תאימות לאחור, לכן עדכון לא שובר קטעים שכבר עובדים, וחזרה לגרסה קודמת אורכת דקות.

עבור הלקוח זה מתבטא בשלושה דברים מדידים: קיצור הזמן להרכבת ממשק חדש, הפחתת שיעור התיקונים החוזרים מבדיקות וקבלה, והקטנת נפח הקוד שיש לתחזק. הספרייה מחזירה את ההשקעה כבר במשימה השנייה-שלישית, שבה הממשק נבנה מבלוקים שכבר נבדקו, ולא מאפס.

גישות לבניית שכבת UI: השוואת אפשרויות

שכבת ה-UI ב-Битрикс24 נבנית מעל React, אך הבחירה בספריית קומפוננטות קובעת כמה זמן יוקדש לתחזוקה וכיצד יתנהג הממשק בעת עדכוני הפלטפורמה. להלן שלוש חלופות מעשיות, שביניהן באמת בוחרים בתחילת הפרויקט, עם המגבלות שלהן.

ערכת UI עצמאית

שליטה מלאה על המבנה, ההתנהגות והתמטיקה: הקומפוננטות נכתבות עבור תרחישים ספציפיים של הפורטל, ללא תלויות מיותרות. מתאים כאשר הממשק הוא יתרון תחרותי ויש צוות שמוכן לתחזק את הספרייה. המגבלה — עלות הבעלות: תיעוד, בדיקות רגרסיה, תמיכה בנגישות וברספונסיביות נופלות עליכם, ולא על הספק.

ערכת UI מוכנה

התחלה מהירה: טבלאות טיפוסיות, טפסים, חלונות מודאליים והתראות כבר בנויים ומכוסים במצבים. מתאים לפורטלים פנימיים ולמשימות שבהן חשובה מהירות ההפקה, ולא הצגה ייחודית.

המגבלה — גבולות מערכת העיצוב: תרחישים לא סטנדרטיים יצטרכו לעקוף, ועדכוני גרסה ראשיים של הספרייה לעיתים גוררים אחריהם תיקונים בקוד שלכם.

שכבה היברידית

אלמנטים בסיסיים נלקחים מערכה מוכנה, ובלוקים ייחודיים נכתבים בעצמכם — עם שכבת טוקנים ותמות משותפת. מתאים לרוב הפרויקטים: מהירות בהתחלה וחופש היכן שהוא מביא ערך. המגבלה — נדרשת משמעת: ללא כללים אחידים לטמה ולקומפוזיציה, ההיבריד הופך במהירות לגן חיות משני סגנונות בלתי תואמים.

בפועל הבחירה מצטמצמת למי אחראי על התחזוקה בעוד שנה וכמה הממשק שונה מהטיפוסי. תארו את תרחישי הפורטל — נחזור עם הערכה ותוכנית לשכבת ה-UI.

כיצד אנו מנהלים פיתוח רכיבי UI ב-Bitrix24

פיתוח רכיבי UI עבור Bitrix24 מתחיל לא בקוד, אלא במלאי של מה שכבר קיים בממשק. אנו בוחנים אילו בלוקים חוזרים על עצמם בעמודים שונים, היכן הלוגיקה מפוזרת בין תבניות, והיכן רכיב גורר אחריו תלויות מיותרות. התוצאה — מפת שימוש חוזר: אילו אלמנטים הופכים למשותפים ואילו נשארים מקומיים.

לאחר מכן אנו מקבעים את החוזה של כל רכיב לפני המימוש. זהו שלב מכריע: אם ה-API מתוכנן עבור העמוד הנוכחי, בעוד חודש יהיה צורך לשבור אותו.

1. ביקורת ממשק. אנו אוספים מרשם של בלוקים קיימים, מוצאים כפילויות ופערים בהתנהגות. מסמנים מה משמש לשימוש חוזר ומה ייחודי למדור.
2. תכנון API של רכיבים. מגדירים פרמטרים נכנסים, אירועים, סלוטים ומצבים (טעינה, תוצאה ריקה, שגיאה). את החוזה מתאמים עם אלה שיחברו את הרכיב.
3. מימוש. כותבים רכיבים באופן מבודד, עם סגנונות מקומיים וללא סלקטורים גלובליים, כדי שהטמעה בעמוד אחד לא תשבור עמודים שכנים.
4. בדיקת תאימות. מריצים את הרכיבים בתמות שונות וברזולוציות שונות, בודקים התנהגות עם נתונים אמיתיים של הפורטל ולא עם דמויים.
5. אינטגרציה בעמודים. מחליפים בלוקים ישנים אחד אחד, תוך שמירה על תפקוד המדור בכל שלב — ללא "החלפה גדולה".
6. מסירה ותיעוד. מוסרים תיאור פרמטרים, דוגמאות חיבור וכללי הרחבה, כדי שצוות הלקוח יוכל להוסיף וריאציות בלעדינו.

הסדר חשוב: ביקורת ותכנון API גוזלים יותר זמן ממה שנדמה, אך דווקא הם מונעים עיבודים מחדש בשלב האינטגרציה. כאשר החוזה מקובע, המימוש ובדיקת התאימות מתנהלים בצורה צפויה, והמסירה מצטמצמת לתיעוד של החלטות שכבר התקבלו.

מה מעבירים ללקוח: ארטיפקטים ותיעוד

אנחנו מעבירים לא "תיקייה עם קבצים", אלא ערכה שלמה שלפיה צוות הלקוח יוכל לעבוד בלעדינו. כל ארטיפקט סוגר סוג משלו של משימות: חלקם נחוצים לפיתוח, אחרים — לעיצוב ולתמיכה.

• קוד המקור של הקומפוננטות — מאגר עם היסטוריית שינויים, ולא ארכיון. כל קומפוננטה מבודדת, נבנית בנפרד ומתחברת לפרויקט בלי עריכות במודולים שכנים.
• טוקנים של עיצוב — צבעים, מרווחים, טיפוגרפיה, רדיוסים ומצבים מוציאים לשכבה נפרדת. שינוי ערך בטוקן משנה את המראה של כל הקומפוננטות בבת אחת, בלי מעבר על קבצים.
• תיעוד של ערכת ה-UI — תיאור של מאפיינים, וריאציות ומגבלות של כל קומפוננטה. המפתח רואה אילו מצבים נתמכים, ולא ממציא מעקפים.
• קטלוג חי של קומפוננטות — סטנד שבו כל אלמנט מוצג בכל המצבים: רגיל, ריחוף, פוקוס, לא זמין. משמש גם כחלון ראווה וגם כבדיקת רגרסיה בעת עדכונים.
• נוהל עדכון — סדר הפעולות ביציאת גרסה חדשה של הספרייה: מה בודקים, איך מתעדים אי-תאימויות, איך חוזרים לערכה הקודמת.
• הוראות חיבור — איך להרים את הבנייה מאפס, אילו תלויות נחוצות, איך מוסיפים קומפוננטה חדשה לערכה המשותפת.
• סכמת אחריות — אילו קומפוננטות אנחנו מתחזקים, אילו עוברות לצוות הלקוח, והיכן גבול העריכות.

בנפרד מתעדים כללי שמות ומבנה תיקיות — זה מה שקובע אם הערכה תמשיך לחיות אחרינו או תהפוך למזבלה תוך חצי שנה. התיעוד והנהלים מתעדכנים יחד עם הקוד, ולא בנגיעה נפרדת "מתישהו".

תארו את המשימה — נחזור עם הערכה ותוכנית להרכב הארטיפקטים עבור הפרויקט שלכם.

מקרה בוחן: איחוד ממשק הפורטל ביותר מ-40 עמודים

הפורטל הארגוני ב-Битрикс24 צמח באופן ספונטני: כל מחלקה הזמינה עמודים משלה, ועד לשלב הביקורת ביותר מ-40 מדורים התקיימו ארבעה סטים שונים של כפתורים, שלוש פלטות וסגנונות טפסים נפרדים. היה צורך לבצע תיקונים בכל תבנית בנפרד, וכל שינוי בזהות המותגית הפך לסבב רב-יומי בכל העמודים.

מה היה לפני

הרכבת ממשק ארכה 3-4 ימים לעמוד טיפוסי: מפתח הפרונט הרכיב את הטופס, המעצב בדק את המרווחים, והמפתח חיבר את הלוגיקה. שגיאות בקוד הפרונט צצו כבר בפרודקשן — אי-התאמות ברשת ובמצבי כפתורים נמצאו ב-6-8 עמודים מתוך 10. השקת פונקציונליות חדשה נמשכה זמן רב: בזמן שהמראה החיצוני אושר, הדרישות כבר השתנו.

מה שינו

המהנדסים שלנו בנו ספריית רכיבי UI פנימית על Bitrix24 UI Kit: כפתורים, שדות, חלונות מודאליים, טבלאות והתראות קיבלו מצבים אחידים וטוקנים של ערכת נושא. הרכיבים חוברו כבלוקים לשימוש חוזר — העמוד מורכב מאלמנטים מוכנים ולא נבנה מאפס.

מה התוצאה

הרכבת עמוד טיפוסי הצטמצמה לכמה שעות — הרכיבים כבר מתוארים ונבדקו. שיעור העמודים עם אי-התאמות בקוד הפרונט ירד מ-60-70% למקרים בודדים, מכיוון שהמראה החיצוני מוגדר ממקור אחד. פונקציונליות חדשה מושקת פי 3-4 מהר יותר: המפתח לוקח בלוק מוכן ולא משכפל את הסימון. שינוי בזהות המותגית מתוקן כעת במקום אחד ומתפשט אוטומטית לכל 40+ המדורים.

במה שונה קומפוננטה מותאמת אישית מקומפוננטה סטנדרטית ב-Bitrix24?

קומפוננטה סטנדרטית היא מה שכבר נמצא באספקה ומתעדכן יחד עם הליבה. תחום האחריות שלה מסתיים בתרחישים סטנדרטיים: כרטיס יישות, רשימה עם סינון, טופס עריכה, קנבן.

כל עוד המשימה נכנסת למסגרת הזו, אין צורך בפתרון מותאם אישית: אתם מקבלים התנהגות מוכנה, ועדכוני הפלטפורמה מגיעים אליכם בלי השתתפותכם.

ברגע שמופיעה לוגיקה לא סטנדרטית — סדר שדות משלכם, הרשאות מורכבות, סטטוסים מחושבים, קשרים מקוננים בין יישויות — הקומפוננטה הסטנדרטית מתחילה להתנגד, ו"התאמתה" דרך התבנית הופכת למבנה שברירי.

קומפוננטה מותאמת אישית היא הקוד שלכם, שפותר בדיוק את המשימה שלכם ואינו תלוי במבנה הפנימי של הסטנדרטית. ההבדל המרכזי אינו בהיקף הקוד, אלא בשאלה מי אחראי להתנהגותו בעת עדכון הליבה. הסטנדרטית מתעדכנת על ידי הספק, אך נשברת מהעריכות שלכם בתבנית.

המותאמת אישית אינה נשברת מעדכונים, כי אינה יורשת את הפנימיות של הליבה — אך אתם אלה שצריכים לעדכן ולבדוק אותה.

מכאן גם עלות התמיכה השונה. קומפוננטה סטנדרטית זולה יותר בהתחלה וכמעט בחינם בתפעול, כל עוד אינכם נוגעים בתבנית שלה. מותאמת אישית יקרה יותר בכניסה, אך צפויה: התנהגותה אינה תלויה במה שהשתנה בתוך הפלטפורמה.

סעיף ההוצאות המרכזי בשני המקרים — אינו הכתיבה, אלא ההתאמות הבאות, ולכן הדבר החשוב ביותר הוא עד כמה הקומפוננטה מופרדת היטב מהליבה.

תאימות עם הליבה נפתרת ברמת הארכיטקטורה. קומפוננטה מותאמת אישית ראוי לבנות על ממשקים ציבוריים של הפלטפורמה, ולא על פניות ישירות לטבלאות פנימיות ולמתודות שירות. אז עדכון הליבה אינו הופך לרוויזיה של כל הממשק: משתנים רק המקומות שבהם השתמשתם במודע בממשק לא יציב. אנחנו מתעדים נקודות כאלה בנפרד — זו בדיוק תמיכת הממשק, ולא כתיבה מחדש מאפס.

קריטריון בחירה מעשי הוא פשוט: אם המשימה מתוארת בתרחיש סטנדרטי — לוקחים סטנדרטית ולא ממציאים. אם הלוגיקה ייחודית ותתפתח — עושים מותאמת אישית, אך עם גבול אחריות ברור ותוכנית לליווי שלה.

אפשרות משולבת, שבה קומפוננטה סטנדרטית עמוסה בעריכות בתבנית, היא היקרה ביותר בתמיכה, ואנחנו לא מציעים אותה.

ספקות טכניים לפני תחילת העבודה

לפני תחילת העבודה כמעט כל צוות שואל את אותן שאלות: האם לא נשבור את הפורטל הקיים, כיצד להעביר דפים שכבר פעילים ומה יקרה לזמינות תחת עומס. להלן תשובות הנדסיות ללא שיווק, כדי שתוכלו להשוות אותן לתשתית שלכם.

כיצד להעביר דפים קיימים ללא עצירת העבודה?

מעבירים דף-דף: התבנית הישנה והרכיב החדש מתקיימים במקביל, והתעבורה מופנית באמצעות ניתוב. תחילה מעבירים דפים בסיכון נמוך, בודקים את התנהגות הטפסים והרשאות הגישה, ואחר כך — את המדורים הקריטיים. חזרה לאחור — החזרת הניתוב לתבנית הקודמת, ללא שחזור נתונים.

האם הפורטל יעמוד בעומס לאחר המעבר לרכיבי React?

רינדור בצד הלקוח משנה את פרופיל העומס: חלק מהעבודה עובר לדפדפן, והשרת מספק נתונים במקום סימון מוכן. אנחנו מודדים את הזמן עד לאינטראקטיביות ואת נפח הנתונים המועברים בתרחישים אמיתיים, שומרים במטמון ספרי עזר ומפצלים את החבילה לפי נתיבים. במדורים עם עומס שיא אנחנו בודקים את ההתנהגות בסשנים מקבילים, כדי שהדרדרות תהיה צפויה ולא פתאומית.

כיצד בודקים את ממשק המשתמש אם קשה לכסות את החלק החזותי בבדיקות אוטומטיות?

את הלוגיקה של הרכיבים מכסים בבדיקות יחידה, ואת המצבים וההרשאות — בבדיקות אינטגרציה על פורטל הבדיקה. רגרסיות חזותיות נתפסות באמצעות צילומי מסך של מסכים מרכזיים, ונגישות נבדקת לפי ניגודיות וניווט במקלדת. כל רכיב נכנס לפורטל רק לאחר שעבר את מערך הבדיקות.

נדון במשימה שלכם בשכבת ה-UI של הפורטל

כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים מינימום נתוני פתיחה על הפורטל שלכם. אנחנו אוספים אותם בשיחה אחת — משם המהנדסים מחשבים את ההיקף והסיכונים, ואתם מקבלים תוכנית עבודה עם שלבים ונקודות קבלה.

• גישה לפורטל ולקוד המקור: מאגר, ענף, סביבת פיתוח, הרשאות קריאה להגדרות מודולים ותבניות.
• רשימת המסכים והתרחישים שצריך לסגור: כרטיסים, רשימות, טפסים, ווידג'טים, הטמעות במדורים קיימים.
• היכן ה-UI נמצא כיום: תבניות מובנות, פתרונות צד שלישי, רכיבים בכתיבה עצמית — מה עושים בו שימוש חוזר, מה כותבים מחדש.
• דרישות להתנהגות: תפקידים והרשאות, שדות חובה, מצבי טעינה ושגיאות, התנהגות במובייל.
• חומרי עיצוב: מסכים, ערכת UI, טוקנים של ערכת נושא, כללי אדפטיביות — או שנסכם שחלק נצייר בעצמנו.
• מגבלות הסביבה: גרסת הליבה, מודולים מותקנים, תקנון עדכונים, דרישות עומס והרשאות גישה.
• קריטריוני קבלה: אילו בדיקות נחשבות לעוברות ובאיזו סביבה מציגים את התוצאה.

לפי נתוני הפתיחה האלה אנחנו מפרקים את העבודה לשלבים: ביקורת שכבת ה-UI הנוכחית, תכנון רכיבים והקשרים ביניהם, מימוש, אינטגרציה בפורטל, בדיקת תרחישים ומסירה. בכל שלב אנחנו מתעדים תוצאה שאפשר לראות בסביבה — כך התוכנית נשארת ניתנת לניהול, ולא הופכת ל"נעשה ונראה בסוף".

תארו את המשימה בצורה חופשית: מהו הפורטל, אילו מסכים כואבים ואיזו תוצאה נדרשת. נחזור עם הערכת לוחות זמנים, הרכב העבודות ותוכנית לפי שלבים.