Emmet not working in JSX statement when condition contains less than

[mathdeziel]

• VSCode Version: 1.25.1 (also tried w/ 1.26.0-insider)
• OS Version: Windows_NT ia32 10.0.17134

I was going through an intro course to React and stumbled on some issues with Emmet. After reading the documentation, I got it to work for the most part, but I couldn't find anything regarding to my issue.

There seems to be a bug with emmet in else if blocks with JSX in .JS and .JSX files.

---

Edit: A member of the community pointed out that the issue was related to the less than sign (<) and not to the else if and so the issue was renamed. Pleased read through the other comments for more information.

---

In short, the tab completion will work in a return if it is located in an if or an else, but will not work if it is located in an else if block (please refer to the GIF below).

Steps to Reproduce:

1. Create a temp folder for the project
2. Add the emmet config provided below to the User Settings or Workspace Settings
3. Add a new file named List.js and populate it with the content provided below
4. Locate the method renderChangePercent around line 19 of the file, the comments will show where emmet works and where is located the bug.

Here is a GIF of the issue :

Here is my emmet config :

{
    "emmet.includeLanguages": {
        "javascript": "javascriptreact"
    },
    "emmet.triggerExpansionOnTab": true
}

And here is the file for testing :

import React from 'react';

class List extends React.Component {
    constructor() {
        super();

        this.state = {
            loading: false,
            currencies: [],
            error: null,
        };
    }

    componentDidMount() {
        this.setState({loading: true});
    }
    

    renderChangePercent(percent) {
        if (percent > 0) {
            return <span className="percent-raised">{percent}% &uarr;</span>
        } 
        // Emmet does not work (tabs)
        else if (percent < 0) {
            return <div></div> 
        }
        // Emmet works
        else {
            return <span className="itWorks"></span>
        }
    }

    render() {
        if (this.state.loading) {
            return <div>Loading...</div>
        }
    }
}

export default List;

[ramya-rao-a]

Thanks for reporting @mathdeziel

@JacksonKearl Can you take a look at this next week? https://github.com/Microsoft/vscode/blob/master/extensions/emmet/src/defaultCompletionProvider.ts would be the place to start.

[JacksonKearl]

Looks like the real culprit is the <.

0 < 1;
sp // wont trigger
1 > 0;
sp // will trigger

[mathdeziel]

Good catch @JacksonKearl, you're right! I should've tested that...

Here is a GIF attesting this hypothesis (PS: don't look at the typo in the comment...)

I also retitled the issue to better reflect the real problem.

Thanks!

[JacksonKearl]

This was likely caused by #35128, where we wanted to disable emmet inside tags:

<img sr| // emmet shouldnt trigger here

I'll have to think about what the best solution here is. An obvious one would be to disable backtracking to look for opening brackets once you reach some set of characters (maybe semicolon, end paren, or newline?). But I'm not convinced that's the right fix.

[ramya-rao-a]

When backtracking, if we reach < but the character right after that cannot be part of a valid tag name, then we can ignore it. So the change can go here: https://github.com/Microsoft/vscode/blob/c3ad9789820afc6f9cab985bfa6e48175e414499/extensions/emmet/src/abbreviationActions.ts#L497 which already ignores the case of <? (found in php)

[JacksonKearl]

But in this case, the character after is a space, which is valid as a tag too

[ramya-rao-a]

space is not valid in a tag name as far as I know...

[mathdeziel]

Based on the W3C recommendation, spaces are valid in a tag name but only after the tag name itself, even if there are no attributes.

From my understanding,

<tag>            // valid
<tag >           // valid
<tag src="">     // valid
<  tag>          // invalid

So I would guess @ramya-rao-a's solution would work.

[JacksonKearl]

Looks like you’re right. I thought
< tag/> could be valid because we syntax hilight it as a normal tag.

[mathdeziel]

I took the liberty to create a PR since it seemed to be an easy fix for a first OSS contribution with the help of @ramya-rao-a's recommendations -- which were spot on 😉 .

[mathdeziel]

PR has been merged, closing the issue.