Handling Web Extension API Requests

In your application, it’s important to understand the order in which Core API requests and additional Web Extension API requests are executed. This knowledge can help you design your user interface to handle various scenarios effectively.

Scenario 1: Core API Request Successful, Additional API Request Fails

In some cases, your Core API request may complete successfully, but subsequent Web Extension API requests may encounter errors. This can result in a situation where part of your process is successful, but additional actions fail. For example, you may successfully update a department’s information, but fail to update related data.

To handle this scenario, consider the following best practices:

• Avoid Using Additional Tabs: If your Web Extension API request can fail, it’s recommended not to use additional tabs on a screen to trigger these requests. Using tabs can create a dependency on the Core API request’s success, and if it fails, the additional requests will be skipped.

• Use a New Dialog: Instead of relying on tabs, consider using a new dialog to initiate Web Extension API requests. This approach allows the frontend to handle the failure independently of the Core API request. Users can be informed of the success or failure of these extension requests, improving the overall user experience.

Scenario 2: Core API Request Fails

In contrast to the previous scenario, if the Core API request fails, by default, any associated Web Extension API requests will be skipped. This behavior is designed to prevent further actions that may depend on the Core API request from executing.

However, there may be cases where you want to override this default behavior and proceed with extension requests even if the Core API request fails. To achieve this, you can use the “NoThrow” mechanism.

Using “NoThrow” to Trigger Extension Requests

The “NoThrow” feature allows you to explicitly specify that extension requests should be made even if the Core API request fails. This can be useful when you have specific use cases that require extension actions to occur independently of the Core API status.

By understanding these scenarios and utilising “NoThrow” where necessary, you can better manage the interactions between Core and Extension API requests in your application.

In your application, it’s important to understand the order in which Core API requests are executed before Web Extension API requests. This knowledge can help you design your user interface to handle various scenarios effectively.

Scenarios Involving Core and Extension API Requests

One common scenario involves your extension making POST/PUT API requests at the same time as the screen is making a core PoST/PUT API request. This can result in one of these requests failing, leading to scenarios you need to account for.

Scenario 1: Core API Request Successful, Additional API Request Fails

In some cases, your Core API request may complete successfully, but subsequent Web Extension API requests may encounter errors. This can result in a situation where part of your process is successful, but additional actions fail.

To handle this scenario, consider the following best practices:

• Managing Concurrent Extension and Core API Requests: If your Web Extension API request can fail, it’s recommended to not include these on screens that make core API requests. For example, do not use additional tabs on the same screen to trigger these requests. Depending on the situation Using tabs can create a dependency on the Core API request’s success, and if it fails, the additional requests will be skipped.

• Use a New Dialog: Consider using a new dialog to initiate Web Extension API requests. This approach allows the frontend to handle the failure independently of the Core API request. Users can be informed of the success or failure of these extension requests, improving the overall user experience.

Scenario 2: Core API Request Fails

In contrast to the previous scenario, if the Core API request fails, by default, any associated Web Extension API requests will be skipped. This behavior is designed to prevent further actions that may depend on the Core API request from executing.

However, there may be cases where you want to override this default behavior and proceed with extension requests even if the Core API request fails. To achieve this, you can use the “NoThrow” mechanism.

Using “NoThrow” to Trigger Extension Requests

The “NoThrow” feature allows you to explicitly specify that extension requests should be made even if the Core API request fails. This can be useful when you have specific use cases that require extension actions to occur independently of the Core API status.

It is important to note that the use of “noThrow” should be approached with care and consideration. Prior to implementing this option, it is essential to thoroughly test and validate your error handling approach to ensure it aligns with the requirements of your application and does not compromise the stability and functionality of the sreeen.