chore: remove perf regression for signals re-enablement#5347
chore: remove perf regression for signals re-enablement#5347jhefferman-sfdc merged 1 commit intomasterfrom
Conversation
| safeHasProp(target, 'value') && | ||
| safeHasProp(target, 'subscribe') && | ||
| isFunction(target.subscribe) && |
There was a problem hiding this comment.
Why are we no longer checking the shape target to make sure it's a signal? Won't that potentially break things?
There was a problem hiding this comment.
I assumed this was because checking for the properties doesn't guarantee correctness and it's up to the consumer to use the API properly? CC: @divmain
There was a problem hiding this comment.
isTrustedSignal(target) is adequate. Objects won't be in the WeakMap unless they're actual signals, which means they'll have the required shape.
If we remove the trusted signal mechanism in the future, we'll have to revisit how to detect signals properly without risking performance regressions. For the specific regression that we encountered, we could add !Array.isArray(target) as a condition. In an case, we can deal with this when/if we remove the trusted signals mechanism. That'll be a couple of years out at the earliest.
There was a problem hiding this comment.
@divmain turns out this is not adequate if the trusted signal tracking set isn't initialized. It defaults to assuming everything is a trusted signal, and therefore tries to subscribe to every mutated object. It doesn't break the framework because it's wrapped in a try/catch, but it's a major console noise and a perf hit. Oops! 😓
| safeHasProp(target, 'value') && | ||
| safeHasProp(target, 'subscribe') && | ||
| isFunction(target.subscribe) && |
There was a problem hiding this comment.
isTrustedSignal(target) is adequate. Objects won't be in the WeakMap unless they're actual signals, which means they'll have the required shape.
If we remove the trusted signal mechanism in the future, we'll have to revisit how to detect signals properly without risking performance regressions. For the specific regression that we encountered, we could add !Array.isArray(target) as a condition. In an case, we can deal with this when/if we remove the trusted signals mechanism. That'll be a couple of years out at the earliest.
Remove perf regression for signals re-enablement. Once removed, we can re-enable
ENABLE_EXPERIMENTAL_SIGNALSin mainDetails
Does this pull request introduce a breaking change?
Does this pull request introduce an observable change?
GUS work item
W-18381293