When adding a new custom widget, ensure that the widget name in the manifest file is unique. Else, you could overwrite a deployed custom widget. This could affect not only you but also any other projects using that widget.

Perform strict validation for all user inputs.

Ensure that your code is covered with tests where necessary. Validate that tests cover edge cases, including invalid inputs and error scenarios.

Avoid hard coding secrets in the code. Instead, use secret headers in the REST definitions.

Avoid logging sensitive information in the console log or storing them in local store.

Handle errors and show appropriate information to the users. Avoid using blocking modal dialogs like alerts.

Do not perform HTTP requests to an external URL. Instead, create a "REST request definition" and invoke it. HTTP requests must only target endpoints within the defined project scope.

Always use the project from the widget context to make requests. Do not hardcode project names outside the manifest.

As shown in the example, use a relative path to access the Bosch IoT Insights APIs:

Ensure that the ESLint configuration is adapted correctly. You would see preconfigured examples when you first create a repository. However, if you missed copying the right dependencies, you will also see a review comment when you submit the first pull request. This comment will contain the steps to install and also the required ESLint config.

Widgets should be lightweight and should not excessively consume resources like CPU or memory.

1. Carefully assess the file sizes when adding assets. For example, resize the images appropriately before adding them to assets. Taking good care here will improve the widget loading time.

2. Test the non-functional aspects before merging a pull request. For example, performance.

3. Lazy load dependencies whenever possible to improve performance.

4. Always unsubscribe from event listeners to prevent memory leaks.
   
   

Avoid embedding CSS stylesheets in the HTML imports. Try to avoid inline styles.

1. Ensure that the component uses styles specific to itself and avoids global styles unless necessary.

2. Verify that the styles do not override the look and feel of the Bosch IoT Insights UI.

3. Adhere to CSS best practices. For example, Block Element Modifier (BEM) is a CSS methodology designed to have clear, modular, and reusable code.
   
   

Identify the configProperties (in the manifest) carefully to avoid migration overheads. Especially when the widget is shared with other projects.

1. When a config property is renamed, it will break the existing usages.

2. Handle such situations with proper errors so that users can detect what went wrong.
   
   

Avoid direct manipulation of the DOM using innerHTML or document.write to prevent Cross-Site Scripting (XSS) vulnerabilities.

Use sanitize methods for handling dynamic content or resource URLs (for example, DomSanitizer in Angular).

Ensure TypeScript is being used with strict typing (strictTemplates enabled in tsconfig.json).

Check that the component uses the latest stable dependencies. Minimize reliance on third-party libraries unless necessary, and check for maintained and secure libraries.

Verify that npm audit shows no vulnerabilities. This will also be done by the bot when a pull request is submitted. Below is an example of the review comment added by the bot when vulnerabilities were found.

Check for proper use of internationalization tools (i18n) if the widget will support multiple languages.

Verify the use of responsive design principles to ensure the widget works across multiple screen resolutions.

Ensure that the component follows the Single Responsibility Principle (SRP) and does only what it is designed for.

Avoid embedding excessive business logic in the component; delegate it to services if needed.

Ensure that the component only manages its view and state; delegate external logic (like API calls) to services.

Check for consistent and descriptive naming of files (e.g., component-name.component.ts).

Verify that the component is designed to be reusable and modular, with clear input/output bindings using @Input() and @Output().

Ensure that the templates are clean, easy to read, and use Angular structural directives (*ngIf, *ngFor) effectively.

Ensure proper use of Angular pipes (e.g., | async, | date) to handle data formatting.

Verify the use of Angular’s ViewEncapsulation to avoid unintentional style leakage.

Ensure that the component uses OnPush change detection where applicable to optimize rendering.

Check if heavy assets or modules are lazily loaded to reduce initial load times.

Verify that observable objects are property unsubscribed to avoid memory leaks.

Confirm the use of Angular’s DI (Dependency Injection) system for injecting services rather than manual instantiation.