-
Notifications
You must be signed in to change notification settings - Fork 392
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
refactor: hidden fields instead of internal fields #1478
Conversation
So, I'm fine with this feature, but I think this will pose a perf regression, lets wait for the perf numbers. |
@@ -4,7 +4,7 @@ | |||
* SPDX-License-Identifier: MIT | |||
* For full license text, see the LICENSE file in the repo root or https://opensource.org/licenses/MIT | |||
*/ | |||
import { defineProperty } from './language'; | |||
import { create, isUndefined } from './language'; |
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.
unrelated to this pr: The fields util is replicated in 3 submodules(engine, synthetic-shadow, node-reactions). Is it a good time to pull it out as a shared library or submodule?
cc @caridy
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.
yes, we have an issue for that
} | ||
valuesByField[fieldName] = value; | ||
} | ||
: setInternalField; // Fall back to symbol based approach in compat mode |
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.
@ekashida #860 (comment)
To give your some context as to why we were falling back to symbol based approach in compat mode
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.
Thanks. I didn't get the existing comment because it was actually falling back to the internal field approach (which was also based on symbols), which would fall back to the string-based approach.
@caridy @ravijayaramappa There were no comments from best, does that mean there was no perf regression? Also, any ideas why the perf tests require the vm to be set internally in vm.ts? |
@@ -34,7 +34,7 @@ import { | |||
getComponentAsString, | |||
getTemplateReactiveObserver, | |||
} from './component'; | |||
import { setInternalField, setHiddenField } from '../shared/fields'; | |||
import { setHiddenField, setInternalField } from '../shared/fields'; |
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.
where is getInternalField
used? I thought the idea was to remove that entirely.
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.
Sorry, I mentioned above that it was in vm.ts
but it was actually in def.ts
:
/**
* EXPERIMENTAL: This function provides access to the component constructor,
* given an HTMLElement. This API is subject to change or being removed.
*/
export function getComponentConstructor(elm: HTMLElement): ComponentConstructor | null {
let ctor: ComponentConstructor | null = null;
if (elm instanceof HTMLElement) {
const vm = getInternalField(elm, ViewModelReflection);
if (!isUndefined(vm)) {
ctor = vm.def.ctor;
}
}
return ctor;
}
I'm not sure why, but our perf tests blow up when we access the vm using getHiddenField
here.
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.
hmm, let me look at it.
@ekashida I think BEST summary is posted only if there is a significant regression. |
No @ravijayaramappa it is indeed failing, I have tried in another PR:
|
Details
Fixes #1299
Does this PR introduce breaking changes?
No, it does not introduce breaking changes.