שיטות מומלצות

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

שיטות מומלצות כלליות

מומלץ להשתמש בשיטות המומלצות הבאות בכל התוספים שאתם מפתחים.

לפני שמתחילים, צריך לקבוע מי הבעלים של התוסף

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

הרחבה של Google Workspace, לא שכפול

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

הגדרת היקפים מצומצמים

כשמגדירים את היקפי ההרשאות באופן מפורש, תמיד בוחרים את קבוצת היקפי ההרשאות הכי מצומצמת שאפשר. לדוגמה, אל תגדירו לתוסף בקשת גישה מלאה ליומן של המשתמש עם היקף הגישה https://www.googleapis.com/auth/calendar אם הוא צריך רק גישת קריאה. כדי לקבל הרשאת קריאה בלבד, משתמשים בהיקף ההרשאות https://www.googleapis.com/auth/calendar.readonly.

לא להסתמך יותר מדי על ספריות

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

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