Minor release

[cesarParra]

Next minor release.

Contains:

Improved error handling

Improves the error handling experience by providing a couple of features to debug and/or modify the way errors are handled when issues occur in a $computed or an $effect

Errors are now surfaced as a console.error by default

Before, when an error occurred in a computed or an effect, the exception was rethrown. The issue is that Salesforce handles these exceptions differently based on the environment. For example, LWC debugging might be on/off, which changes how errors are surfaced, and errors are handled differently in LWR templates, where the user is redirected to the error page.

To improve this experience, when an error occurs in either a computed or effect function, a console.error will be called so that the error is easier to detect (the exception will still be retrhwon after logging).

Computed and effects can now have an "identifier" for logging purposes.

Following on the previous improvement, if you want to pinpoint exactly which effect or which computed values is the one throwing the exception, a new identifier property was introduced. This is only for debugging purposes, and does not affect the functionality otherwise.

Example

      $computed(() => {
        signal.value;
        throw new Error("error");
      }, { identifier: "test-identifier" });

In this example, the test-identifier string will appear as part of the console.error message.

Computed and effects can now have custom error handlers

Both computed and effect signals can receive a custom errorHandler property, that allows developers to completely override the default functionality that logs and rethrows the error.

Effect handlers

For $effect handlers, you can pass a function with the following shape:

(error) => void

The thrown error will be passed as an argument, and nothing should be returned.

Example:

    function customErrorHandlerFn(error) {
      // custom logic or logging or rethrowing here
    }
    $effect(() => {
      throw new Error("test");
    }, {
      errorHandler: customErrorHandlerFn
    });

Computed handlers

For $computed handlers, you can pass a function with the following shape:

(error: unknown) => T | undefined

Where you can return nothing, or a value of type T, which should be of the same type as the computed value itself. This allows you to provide a "fallback" value, that the computed value will receive in case of errors.

Example

    function customErrorHandlerFn(error) {
      // custom logic or logging or rethrowing here
     return "fallback value";
    }
    $computed(() => {
      throw new Error("test");
    }, {
      errorHandler: customErrorHandlerFn
    });

Suite of additional unit tests

Other minor fixes and improvements

[stanleyzapata]

@cesarParra Reviewing it

[stanleyzapata]

You are about to reach the point were it might make sense to put the properties to remove in an array and delete them in a loop. Just something to consider

[cesarParra]

Yup, I have an issue to fix this ugliness already #27

[stanleyzapata]

Looks Good, left you a small comment on a potential improvement but you can leave it as is

[github-actions]

🎉 This PR is included in version 1.2.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀