M365Con 2027 – כנס אונליין חינמי · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

מתי לבנות רכיב PCF מותאם אישית לעומת שימוש ברכיבי Canvas ב-Power Apps

By ·

למדו מתי כדאי לבנות רכיבי קוד PCF מותאמים אישית, ומתי להסתפק ברכיבי Canvas דלי-קוד ב-Power Apps. השוו בין הכישורים הנדרשים, הביצועים והארכיטקטורה.

Automatically translated with AI from the original post. Read the English original

Cover: Power Apps Component Framework - Simply Explained

הבחירה בין רכיבי ממשק קוד מבוססי Power Apps Component Framework (PCF) לבין רכיבי Canvas דלי-קוד קובעת אם הפרויקט שלכם יצליח או ייתקע. מדריך זה מפרט את ההבדלים הארכיטקטוניים המרכזיים, דרישות הכישורים, השפעות הביצועים וקריטריוני ההחלטה, כדי לעזור למפתחים וליוצרים לבחור בכלי הנכון לאתגרי ממשק מורכבים.

עיקרי הדברים

הפער הארכיטקטוני: יוצרים מול מפתחים

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

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

רכיבי Canvas למהירות, PCF לעוצמה

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

עם זאת, רכיבי קנבס מוגבלים מיסודם על ידי שפת הביטויים ומנוע הפריסה של סביבת הקנבס. הם אינם יכולים לחרוג מסביבת הביצוע המבודדת של הפלטפורמה כדי להשתמש בספריות JavaScript מתקדמות של צד שלישי, להציג הדמיות SVG מורכבות מותאמות אישית, או להפוך באופן מקורי את התנהגות הרשת לטבלאות נתונים צפופות וניתנות לעריכה. כאן נכנס לתמונה Power Apps Component Framework. באמצעות Microsoft Power Platform CLI, מפתחים כותבים רכיבי ווב אמיתיים בעזרת TypeScript ותקני ווב מודרניים. רכיבי הקוד האלה מצהירים על קלטים ופלטים מפורשים באמצעות קובץ manifest, כך שהאפליקציה המארחת יכולה לחבר נתונים לרכיב בצורה חלקה, בלי לנחש את מצבו הפנימי.

אופטימיזציה של ביצועים עם React ו-Fluent UI

בעבר, בניית רכיב מותאם אישית מאפס משמעה לעיתים קרובות לארוז כל תלות חיצונית, מה שהגדיל את גודל הקבצים והאט את זמני הטעינה. פיתוח PCF מודרני מבטל את התקורה הזו באמצעות ספריות פלטפורמה. מפתחים יכולים לבנות רכיבים באמצעות React ו-Fluent UI, מערכת העיצוב המקורית של Microsoft, על ידי שימוש בספריות שכבר נטענו מראש על ידי הסביבה המארחת.

כאשר אפליקציה טוענת מספר רכיבים מותאמים אישית שחולקים את ספריות הפלטפורמה הללו, הדפדפן נמנע מהורדה כפולה של קוד מסגרת. כך ממשק המשתמש נשאר זריז, מגיב ועקבי מבחינה חזותית עם שאר מערכת Microsoft 365. מאחורי הקלעים, מתודות מחזור החיים של הרכיב (init, updateView, getOutputs ו-destroy) מנהלות את עבודות התחזוקה של הציור, העדכון כאשר הנתונים משתנים, וניקוי הזיכרון כאשר הרכיב מוסר. הקפדה על מחזור החיים הזה מונעת דליפות זיכרון ועיבוד איטי, שהם הבעיות הנפוצות בהזרקות קוד חובבניות.

ממשל ותחזוקה לטווח ארוך

אימוץ רכיבי קוד מותאמים אישית מביא עמו פרופיל תחזוקה שפתרונות low-code בדרך כלל נמנעים ממנו. מאחר ש-רכיבי PCF דורשים שלב בנייה, מאגר קוד מקור ופריסה דרך פתרונות Dataverse, יש צורך בבעלים מוגדר. אם המפתח המקורי עוזב בלי תיעוד נאות, רכיב מותאם אישית עלול במהרה להפוך לקופסה שחורה שאי אפשר לתחזק.

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

סיכום

ההחלטה בין רכיבי קנבס לבין Power Apps Component Framework מסתכמת בהתאמת המשאבים הטכניים שלכם לבעיית הממשק המסוימת שלפניכם. השתמשו ברכיבי קנבס להכלת ממשק משתמש מהירה וללא קוד באפליקציות קנבס, ושמרו את רכיבי הקוד של PCF לדרישות מתקדמות וביצועים גבוהים שנוגעות לפתרונות המבוססים על Dataverse. כדי להעמיק בנושא ולשמוע תובנות מומחים על פיתוח ענן מודרני של Microsoft, האזינו לפרק המלא של פודקאסט M365 FM.

שאלות נפוצות

האם ניתן להשתמש ברכיבי קנבס באפליקציות מונחות מודל?

לא, רכיבי קנבס מיועדים אך ורק לאפליקציות קנבס. אם אתם צריכים רכיבי ממשק משתמש מותאמים אישית באפליקציות מונחות מודל או ב-Power Pages, עליכם להשתמש ברכיבי קוד של Power Apps Component Framework (PCF).

אילו שפות תכנות נדרשות לבניית בקרים של PCF?

בניית רכיבי קוד מותאמים אישית דורשת ידע מעשי ב-TypeScript (או JavaScript), HTML ו-CSS, יחד עם היכרות עם Microsoft Power Platform CLI לצורך יצירת שלד הפרויקט ואריזתו.

האם משתמשי קצה צריכים לדעת לתכנת כדי להשתמש בבקר PCF?

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

מהי מטרת קובץ ה-manifest של הרכיב?

ה-manifest הוא קובץ XML שמצהיר על המטא-נתונים של הרכיב, על מאפייני הקלט הצפויים ועל אירועי הפלט שלו. הוא משמש כתרשים חיווט, כך ש-Power Apps תוכל לקשור נתונים לרכיב הקוד בצורה נכונה.

Power Apps Power Platform Canvas app Dataverse Microsoft Excel Model-driven app Power Pages

Related articles

RSS