[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-04-10。"],[[["\u003cp\u003eEnhance user experience by adhering to add-on design guidelines, focusing on ownership, functionality, and scope management.\u003c/p\u003e\n"],["\u003cp\u003eOptimize add-on performance by minimizing reliance on libraries and using efficient coding practices with the Card service.\u003c/p\u003e\n"],["\u003cp\u003eEnsure add-on quality by implementing thorough testing procedures and including error handling mechanisms.\u003c/p\u003e\n"],["\u003cp\u003eFor Calendar conferencing add-ons, prioritize lightweight \u003ccode\u003eonCreateFunction\u003c/code\u003e logic, proper \u003ccode\u003eConferenceData\u003c/code\u003e usage, and avoid redundant event description modifications.\u003c/p\u003e\n"]]],["Add-on development best practices include determining ownership and collaborators, prioritizing new capabilities over replicating existing ones, and using the narrowest scopes possible. Minimize the use of Apps Script libraries to avoid performance issues. For Google Workspace add-ons, utilize a few, simple cards, employ widget creation functions, and use error cards. Thoroughly test add-ons, including action callback functions and host application specific data. When creating calendar conferencing solutions, keep `onCreateFunction` efficient and use proper `ConferenceData` fields. Avoid adding redundant conference details to Google Calendar events.\n"],null,["# Best practices\n\nImprove your users' overall experience by following these guides for\nadd-on design.\n\nGeneral best practices\n----------------------\n\nYou are encouraged to use the following best practices for all\nadd-ons you develop.\n\n### Determine add-on ownership before starting\n\nAdd-ons are defined by Apps Script projects, which\nmust be owned by a specific account or else placed in a [shared\ndrive](/workspace/drive/v3/web/about-shareddrives). Before coding an\nadd-on, determine what account should own the project,\nand what account acts as its publisher. Also determine what accounts are to act\nas collaborators, and make sure those accounts have access to the script project\nand its associated\n[Google Cloud project](/apps-script/guides/cloud-platform-projects).\n| **Note:** It's important to plan add-on ownership. If the add-on owner leaves your organization, you must make sure ownership is transferred or else you could lose the ability to update and manage your add-on. For this reason, it may be best to create an organization account specifically to own and publish your organization's add-ons. You can also use a shared drive to act as the script project owner, but a specific account must act as the add-on publisher.\n\n### Extend Google Workspace, don't replicate it\n\nAdd-ons are meant to provide new capabilities to the\nGoogle Workspace applications they extend, or else automate complex tasks.\nAdd-ons that merely replicate functionality already within the\napplication or ones that don't make significant improvements to a workflow\naren't likely to pass [add-on review](/workspace/marketplace/about-app-review) for publication.\n\n### Keep the scopes narrow\n\nWhen [defining your scopes\nexplicitly](/apps-script/concepts/scopes#set-explicit), always choose the\nleast-permissive set of scopes possible. For example, don't have your\nadd-on request full access to the user's\nCalendar with the `https://www.googleapis.com/auth/calendar`\nscope if it only needs read access. For read-only access, use the\n`https://www.googleapis.com/auth/calendar.readonly` scope.\n\n### Avoid relying too much on libraries\n\nUsing Apps Script [libraries](/apps-script/guides/libraries) can\ncause your add-on to [run more\nslowly](/apps-script/guides/support/best-practices#avoid_libraries_in_ui-heavy_scripts)\nthan it would if all the Apps Script code were contained within a\nsingle script project. Although Apps Script libraries work in\nadd-ons, you might run into performance reductions if you use\nthem. Avoid including unnecessary libraries in your project, and consider ways\nto reduce your add-on's reliance on them.\n\nThe latency described above only applies to Apps Script projects\nbeing used as server-side libraries. You can use client-side JavaScript\nlibraries like jQuery freely without encountering this latency.\n\nGoogle Workspace add-on best practices\n--------------------------------------\n\nThe following best practices only apply to Google Workspace add-ons and the use of the\n[Card service](/apps-script/reference/card-service/card-service).\n\n### Use just a few cards\n\nIf the add-on uses too many cards the navigation\nconfiguration becomes complex and difficult to manage.\n\nAvoid the impulse to create more cards than necessary.\n\n### Use widget creation functions\n\nWhen writing code that creates a\n[`Card`](/apps-script/reference/card-service/card) or other complex UI objects,\nconsider putting that code in its own function. This creation function should\njust build the object and return it. This lets you quickly regenerate that\nobject whenever the UI must be refreshed. Remember to call `build()` after using\nthe builder classes in the [Card service](/apps-script/reference/card-service/card-service).\n\n### Keep cards simple\n\nIf a given card has too many widgets, it can fill too much of the screen and\nbecome less useful. While large card sections render as collapsible UI elements,\nthis hides information from the user. Aim to streamline your\nadd-on and provide exactly what the user needs and no\nmore.\n\n### Use error cards\n\nCreate cards for error conditions. If your add-on\nproduces an error, it should display a card with the error information and\ninstructions on how to correct it, if possible. For example, if your\nadd-on couldn't connect to a non-Google service because\nthe authorization failed, display a card stating this and ask the user to verify\nthe account information being used.\n\n### Write tests and test messages\n\nYou should thoroughly test all the add-ons you create. Build test\nfunctions that create cards and widgets using test data, and then verify that\nthe objects are created as expected.\n\nWhen using [action callback\nfunctions](/workspace/add-ons/concepts/actions#callback_functions), you usually\nmust construct a response object. You can use statements like the following to\nverify that the responses are being constructed correctly: \n\n Logger.log(response.printJson());\n\nRun test functions you create directly from the Apps Script\neditor using the **Run** menu. When you have a viable\nadd-on working, be sure to [install the unpublished\nversion](/workspace/add-ons/how-tos/testing-workspace-addons#install_an_unpublished) so you can test it.\n\nUse test data appropriate for each host application the\nadd-on extends. For example, if the\nadd-on extends Gmail you're likely to need a\nfew test emails and their message IDs so that you can ensure that the\nadd-on functions as expected when given different\nmessage content. You can get the message ID for a given message by listing\nmessages using the [Gmail API\n`users.messages.list`](/workspace/gmail/api/v1/reference/users/messages/list)\nmethod, or by making use of Apps Script's [Gmail\nservice](/apps-script/reference/gmail).\n\nCalendar conferencing best practices\n------------------------------------\n\nIf your add-on integrates [third-party calendar\nconferencing](/workspace/add-ons/calendar/conferencing/overview) options into\nGoogle Calendar, follow these additional best practices:\n\n### Keep your `onCreateFunction` light\n\nEach\n[`onCreateFunction`](/apps-script/manifest/calendar-addons#ConferenceSolution.FIELDS.onCreateFunction)\nyou define in your manifest is called synchronously when a user attempts to\ncreate a conference solution of that type. Make sure these functions only do the\nminimum necessary work to create the conference. Doing too much in these\nfunctions can cause a slow user experience for your\nadd-on.\n\n### Use appropriate `ConferenceData` fields for conference data\n\nWhen you build\n[`ConferenceData`](/apps-script/reference/conference-data/conference-data)\nobjects, you can populate them with details about the conference (access codes,\nphone numbers, pins, URIs, etc.). Be sure to use the corresponding\n[`EntryPoint`](/apps-script/reference/conference-data/entry-point) field for\nthis information. Don't place these details in the `ConferenceData` notes field.\n\n### Don't append conferencing details to the Calendar event\n\nYour add-on doesn't need to add information about\ncreated third-party conferences to the Calendar event\ndescription. Calendar does this automatically when necessary."]]
