Skip to content
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(reactivity): remove redundant code #10816

Closed
wants to merge 1 commit into from
Closed

Conversation

Ali-ovo
Copy link

@Ali-ovo Ali-ovo commented Apr 27, 2024

When I was studying the source code from vue3 reactivity
I found that on computed this section there was bloated code
So I thought we could remove it, and the test passed successfully

@skirtles-code
Copy link
Contributor

This PR is currently marked as a feat. I wonder whether refactor might be more appropriate?

The line public dep?: Dep = undefined features in several of the ref implementations. e.g. RefImpl and CustomRefImpl. If we're going to remove it from one then maybe it should be removed from all of them?

The property itself comes from the RefBase type, which marks it as optional. That property is then used in trackRefValue and triggerRefValue. As the property is optional, nothing complains if the initial value isn't explicitly set to undefined, but nevertheless the property will be added once the ref is used elsewhere.

I'm unsure what the reasoning was behind explicitly declaring these properties with undefined values. Perhaps it was just for greater explicitness, or maybe it was to ensure that the 'shape' of the objects won't change at runtime post-creation (for better performance).

@Ali-ovo
Copy link
Author

Ali-ovo commented Apr 27, 2024

This PR is currently marked as a feat. I wonder whether refactor might be more appropriate?

The line public dep?: Dep = undefined features in several of the ref implementations. e.g. RefImpl and CustomRefImpl. If we're going to remove it from one then maybe it should be removed from all of them?

The property itself comes from the RefBase type, which marks it as optional. That property is then used in trackRefValue and triggerRefValue. As the property is optional, nothing complains if the initial value isn't explicitly set to undefined, but nevertheless the property will be added once the ref is used elsewhere.

I'm unsure what the reasoning was behind explicitly declaring these properties with undefined values. Perhaps it was just for greater explicitness, or maybe it was to ensure that the 'shape' of the objects won't change at runtime post-creation (for better performance).

Oh, you're right. I made a mistake

@Ali-ovo Ali-ovo closed this Apr 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants