Add a custom scope to React component in JSX about ecmascript-sublime HOT 9 CLOSED

@aziz I’m currently rewriting the JSX stuff from scratch. I’d worked originally off the published grammar, which in practice isn’t accurate (uses xml-style namespacing, for example). I’ve added tentative half-assed support for Styled JSX to the latest release, but am hoping to address it properly soon.

from ecmascript-sublime.

that's great to hear. BTW, JSX has got some additions last week, Fragments.
I hope you can add support for that as well

render() {
  return (
    <>
      <ChildA />
      <ChildB />
      <ChildC />
    </>
  );
}

from ecmascript-sublime.

We can add this to ES Sublime, but with the context limitations it will only be possible to add the extra annotation to classes that conform to the pattern class ws+ (name ws+)? extends ws+ React ws* dot ws* Component ws* leftBrace. Do you consider that good enough? Are there other patterns that you can think of that would be signals and are unlikely to generate false positives?

from ecmascript-sublime.

I don't think you understand me correctly. I asked to add a more specific scope to React component names when they're referenced in JSX.
Note the different color in the screenshot above between <BasketContent> and a normal html tag like <div>.
This is easy since inside JSX, all react component should always be capitalized and html tags are lower cased. I think this is what VSCode Syntax Highlighter is doing.

so inside JSX, <Div> is a react component but <div> is the normal html tag.

from ecmascript-sublime.

Ah, got it, when I saw the scope list in the screenshot I was thinking 'support.class.component' was an outer scope containing the entire class declaration. Yes, distinct scopes for html vs custom component names makes sense — and unless I’m mistaken about how JSX works today, I’m pretty sure it literally determines token type by casing (i.e. they don’t use a whitelist anymore, and it’s not merely convention but actually part of the syntax ... I think?).

BTW, I’m currently on a project that uses JSX at work, and now that I’m using it regularly myself I may look into further enhancements to how ES Sublime handles it — if you have more ideas for this I can hit them all at once.

from ecmascript-sublime.

it literally determines token type by casing

Yes

if you have more ideas for this I can hit them all at once.

I'll see what I can put on my wishlist

from ecmascript-sublime.

My biggest pain in working with JSX is that I lose all the nice features that sublime gives you when working with a normal HTML file.
Things like, Auto-completion or Auto closing tags or Auto indentation.
I know JSX is not HTML but it would be awesome if we could find a way to make those features work inside a JSX block as well.

from ecmascript-sublime.

We can probably lift this logic from the XML syntax def wholesale (JSX is slightly closer to XML than HTML as far as element logic goes).

from ecmascript-sublime.

• JSX syntax highlighter is a bit aggressive and quickly mark half of the page as invalid

from ecmascript-sublime.