Refactor how signals are created.

[cesarParra]

Having to delete properties out of the signal before returning it is not a great developer experience

lwc-signals/src/lwc/signals/core.ts

Line 274 in 97fa7fe

// We don't want to expose the `get` and `set` methods, so

This can cause issues of us leaking information that we didn't intend if we forget to delete a new property in the future that should not be returned.

The main use case we have is that we allow for custom storages to add additional functionality to the signals. For example, here https://github.com/cesarParra/lwc-signals/blob/main/src/lwc/signals/__tests__/custom-storage.test.ts#L44 we created a custom storage that allows for the undo function to be added to the signal. This is something we want to continue to support.

What we want to accomplish here is:

• Prevent having to delete properties when creating signals
• Continue to allow for custom functions to be added to signals
• Update the Typescript types to correctly represent what the signal has, including if possible the custom functions.

Ideas

• We can change the way that adding custom functions work. It can be pretty cumbersome to have to create a new storage for this. Instead we can allow for custom Mixins to be created. The Dart Signals implementation does this https://dartsignals.dev/mixins/signals-mixin/
  ** Dart has mixin support at the language level, so it is elegant to do it in that language, how would that look in TS/JS?