-
Notifications
You must be signed in to change notification settings - Fork 386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: [WIP] first prototype of node reactions #1431
Conversation
forEach.call(reactionQueue, (entry: ReactionEvent, index: number) => { | ||
// TODO: Should this be fault tolerant? If one callback failed, should the processing end of continue? | ||
entry.callback.call(entry.node, entry.type); | ||
reactionQueue.slice(index, 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@@ -19,8 +21,10 @@ export default function queueReactionsForTree( | |||
reactionTypes: Array<ReactionEventType>, | |||
reactionQueue: Array<ReactionEvent> | |||
): void { | |||
if (process.env.NODE_ENV !== 'production') { | |||
assert.invariant(!isUndefined(root), `Expected a dom node but received ${root}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... but received undefined
isn't it?
if (root instanceof Element && !!root.shadowRoot) { | ||
const nodeType = nodeTypeGetter.call(root); | ||
// Perf optimization: Only Element type can have shadowRoot | ||
if (nodeType === 1 && (root as Element).shadowRoot) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worry about this check here. if the element has a closed shadowRoot, we can't do much. That's why I think my suggestion was to patch attachShadow()
so we can always grab the shadowRoot when needed, and we can have a custom mechanism to determine shadow. Something like:
if (!isUndefined(root.$$myInternalFn$$)) {
const sr = root.$$myInternalFn$$();
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the patch on attachShadow will create $$myInternalFn$$
or a symbol to provide a fn to access the shadow root instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, agreed. Closed shadow was an open question in the RFC too.
About patching attachShadow and adding a field, if I put my security hat on: What stops external users from utilizing the same field to bypass closed shadow?
} | ||
|
||
if (isTrue(hasChildNodes.call(root))) { | ||
// Perf optimization: Element and Document Fragment are the only types that need to be processed | ||
if ((nodeType === 1 || nodeType === 11) && isTrue(hasChildNodes.call(root))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably the call to hasChildNodes then childNodesGetter is slower than just childNodesGetter because you cross the bridge only once.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
enumerable: true, | ||
configurable: true, | ||
get(this: Node) { | ||
return isConnected.call(this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this isConnected
is the same you import from Node.prototype
, I suspect that it must be patched here if it doesn't exist, and to provide shadow semantics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be generating environment-specific dist files in this package? We don't do that for engine
, synthetic-shadow
, or wire-service
.
@ekashida you're right, this is not different than those other pkgs, we shouild have the same build step. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Benchmark resultsBase commit: |
24b1326
to
7d0851b
Compare
Benchmark resultsBase commit: |
7d0851b
to
c0a9db9
Compare
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
} | ||
if (qualifiedReactionTypes.length > 0) { | ||
if (ObjectKeys(qualifiedReactionTypes).length > 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bitwise flag with be just compare to something different than 0
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
035ed11
to
286f00b
Compare
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
Web Platform Testswpt branch: command: // without node-reactions // with node-reactions |
to preserve native behavior for invalid arguments
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
for perf reasons
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
⚠ Performance RegressionBest has detected that there is a Please click here to see more details. Click to view significantly changed benchmarkslwc-engine-benchmark
|
Closed in favor of #1504 |
Details
First prototype of node-reactions RFC salesforce/lwc-rfcs#11
Started with #1173 as the base.
Does this PR introduce breaking changes?
No, it does not introduce breaking changes.
If yes, please describe the impact and migration path for existing applications.
The PR fulfills these requirements: