A widget does not have instance options defined when initially added to a page. A widget in this empty state can appear blank and cause confusion. In situations where a widget requires some initial configuration, ensure that your widget has a default state that communicates to the admin what configuration is necessary.

Widgets can also be created with demo data. Demo data can also be used to:

Learn more: Tutorial: Build a custom widget.

Embedding an existing widget into your custom widget takes advantage of pre-existing functionality without cloning or duplicating code. You can still pass parameters into the embedded widget to control its behavior.

Learn more: Embed an existing widget

If your server-side script uses GlideRecord queries, the setLimit function can restrict the number of records returned, and improve response time on queries. For added flexibility, you can tie this limit to an instance option rather than assigning a hard-coded value (for example: gr.setLimit(options.limit || 100)).

Learn more: GlideRecord setLimit Function

When an embedded widget is called from the server, all the scripts associated with that widget are returned. If you only need a subsection of a widget, embedding the entire widget creates unnecessary overhead. Instead, use directives to share lightweight code between widgets. Directives are useful, for example, when building UI components. Complex components with server-side and client-side functionality are best left as widgets. Use a directive instead of an embedded widget to:

Learn more: Reuse components with Angular Providers.

Data services and factories maintain and persist state in a widget without requiring multiple calls to the server, enabling you to:

Learn more: Reuse components with Angular Providers.

Avoid using $broadcast in the DOM. $broadcast dispatches the event name to all child scopes notifying registered listeners, which can be an expensive call that requires the use of the $rootScope global object.

Instead, use a publish/subscribe service to handle events. When using a publish/subscribe service, a clear relationship forms between your widgets through callback handlers. In this model, you can better control the state of your events.

When you call server.update(), the entire widget is returned from the server. If your widget includes divergent code paths, multiple calls to update the server can affect performance. As a rule, use your server script to set up the initial state of your widget. For subsequent updates, use scripted REST APIs that call script includes on your instance. This practice:

To create the best experience for your users, follow these guidelines: