Skip to content

fix(compiler-core): add isTemplateFor to ast of For nodes #8991

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Tofandel
Copy link
Contributor

@Tofandel Tofandel commented Aug 16, 2023

There is an inconsistency in the generated ast between v-for and v-if, the v-for only returns a For node with it's direct children, the v-if returns one decorative wrapper node containing the branch nodes as children

Here is a demonstration https://codesandbox.io/p/sandbox/priceless-cache-t7zwzg

While we can work around this inconsistency for the most part, the original node properties on the v-for are entirely lost, there is just no way to know if the node is a template or an element by looking at it to reverse engineer the ast

Even the loc.source does not give this information like the v-if does (unless looking into the codeGen.loc.source)

The IfNode also has a boolean property isTemplateIf which also gives this information

Here is the difference in loc between a v-for

{
    start: { column: 3, line: 3, offset: 13 },
    end: { column: 24, line: 3, offset: 34 },
    source: 'v-for="test in test2"'
  }

and a v-if

{
    start: { column: 1, line: 2, offset: 1 },
    end: { column: 12, line: 5, offset: 55 },
    source: '<template\n    v-if="test">\n    <div></div>\n</template>'
}

As we can see the v-for completely drops it's parent information and uses the information of the Directive, while the v-if uses the information of the Element on which it was found

This PR aims to aleviate a bit this loss of information by adding a isTemplateFor and a templateProps property to the ForNode to indicate whether the original is a template or an element to know how to interpret the children nodes properly and to be able to retrieve the key directive on the template when we reverse engineer the AST

@github-actions
Copy link

Size Report

Bundles

File Size Gzip Brotli
runtime-dom.global.prod.js 85.8 kB 32.6 kB 29.4 kB
vue.global.prod.js 132 kB (+51 B) 49.3 kB (+17 B) 44.3 kB (-52 B)

Usages

Name Size Gzip Brotli
createApp 47.7 kB 18.9 kB 17.2 kB
createSSRApp 50.5 kB 19.9 kB 18.2 kB
defineCustomElement 50.1 kB 19.6 kB 17.9 kB
overall 61.1 kB 23.7 kB 21.6 kB

@skirtles-code
Copy link
Contributor

I was hoping to review this, but I'm unclear what the use case is. Is there a specific tool/library that would benefit from including this extra information?

@Tofandel
Copy link
Contributor Author

Tofandel commented Jun 9, 2024

It's not really extra information, it's information that is missing that is normally available. I was trying to build a tool that would have used it, and this is crucial information that is missing, without it there is no way to know what node/tag is the v for on

Without it we cannot edit the existing source as the original source of the ast is incomplete without it

@edison1105 edison1105 added scope: compiler need guidance The approach/solution in the PR is unclear and requires guidance from maintainer to proceed further. labels Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need guidance The approach/solution in the PR is unclear and requires guidance from maintainer to proceed further. scope: compiler
Projects
Status: Needs Review
Development

Successfully merging this pull request may close these issues.

3 participants