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

Is there support for JSX fragments? #348

Open
mhluska opened this issue Dec 7, 2017 · 17 comments

Comments

@mhluska
Copy link

commented Dec 7, 2017

React fragments have been awesome but they completely mess up the syntax highlighter.

For example:

<>
  <span>hello</span>
  <span>world</span>
</>

facebook/jsx#84

@borela

This comment has been minimized.

Copy link

commented Jan 10, 2018

Try https://github.com/borela/naomi

@gaearon

This comment has been minimized.

Copy link
Member

commented Feb 18, 2018

@borela

This comment has been minimized.

Copy link

commented Feb 19, 2018

@gaearon Did you find any bugs on FJSX15?

@gaearon

This comment has been minimized.

Copy link
Member

commented Feb 19, 2018

I'm not super happy with how it special-cases state or changes the default extension.

@borela

This comment has been minimized.

Copy link

commented Feb 19, 2018

I can remove the special case for state as it had some issues with some color schemes, it's an easy fix. I am not sure what you mean about the default extension, isn't it coloring .js files?

@borela

This comment has been minimized.

Copy link

commented Feb 19, 2018

Ooo I know what you mean, it wasn't using FJSX15 by default and so it tried to save as .fjsx instead of .js, this is something that I was working on the lastest pulls, in >= v3.4.3 it should be working as expected and I removed the special cases for state.

@Thom1729

This comment has been minimized.

Copy link

commented Feb 19, 2018

@gaearon JS Custom is a configurable extension of Sublime's core syntax highlighting that supports JSX. As of fifteen minutes ago, it should be a complete superset of babel-sublime's functionality.

Because babel-sublime is basically defunct, I'm hoping to establish a seamless migration path once I've gone down the babel-sublime bug tracker and made sure all of the issues are fixed in JS Custom, but it should be production-ready right now.

@im-sunil

This comment has been minimized.

Copy link

commented Sep 14, 2018

Hello @zertosh and @Thom1729 When will adding support for <>...</> fragment short tag

@suchipi

This comment has been minimized.

Copy link
Member

commented Sep 15, 2018

@im-sunil use JS Custom instead

@vadzim

This comment has been minimized.

Copy link

commented Oct 15, 2018

+1

JS Custom has many disadvantages like not coloring jsx keys, changing colors inside functions in jsx, coloring object keys with default values as strings, not as variables and so on. It's not possible to setup it to look like babel-sublime.

@Thom1729

This comment has been minimized.

Copy link

commented Oct 15, 2018

@vadzim JS Custom is intended to function as a drop-in replacement. Could you post examples of the differences you're talking about?

@vadzim

This comment has been minimized.

Copy link

commented Oct 15, 2018

@Thom1729 this is what I remembered:

code:

const ComponentA = ({
  valueA,
  valueB = {
    'fieldA': 'a',
    fieldB,
  },
  valueC,
}) => <>
  {`ComponentB${valueC}`}
  <ComponentB
    propA={valueA}
    propB={typeof valueB === 'function' ? valueB(id) : valueB}
  />
</>

babel-sublime (locally patched for fragments):
default

js custom:
default

config:

{
	"defaults": {
		"string_object_keys": true	
	}
}

Differences that cannot be eliminated by modifying theme:

  • valueB has color like fieldA, but in babel-sublime it has color like fieldB
  • different colors of commas in parameter list of a function

Differences in js-custom that I guess should be probably eliminated be modifying theme, but present by default:

  • brackets in template strings are visually connected with content
  • in jsx key={variable} expressions has no highlighting
  • in jsx variable names inside an expression propB={typeof valueB === 'function' ? valueB(id) : valueB} has not a black color as they have outside of jsx

Anyway it's much easier to patch babel-sublime locally for fragments using Dan's PR than to spend time to change theme for jsx in js-custom.

@Thom1729

This comment has been minimized.

Copy link

commented Oct 15, 2018

  • valueB has color like fieldA, but in babel-sublime it has color like fieldB
  • different colors of commas in parameter list of a function

Mostly, this is a consequence of the Sublime parsing engine's inability to recognize arrow functions. See SublimeTextIssues/Core#2241 for a proposal that would fix this. JS Custom inherits the core JavaScript syntax's behavior in this case.

There may be an opportunity to improve the fallback behavior here. As implemented, when the syntax fails to recognize an arrow function parameter list, it will "recover" after the parameter list and everything from the => will be highlighted correctly. However, the object literal body code doesn't do anything special. In principle, when the syntax is parsing the body of an object literal, and it encounters = after a property name, it could guess that it was actually inside destructured arrow function parameters and parse the = and the following expression accordingly. The commas would be fixed as a consequence.

I'm glad you brought this up. I'd appreciate it if you could open an issue on the default packages tracker. Improvements in the core syntax are typically merged into JS Custom within a day or two (sometimes even ahead of the Sublime dev builds).

brackets in template strings are visually connected with content

The brackets are marked punctuation.definition, which is standard. I am surprised to learn that babel-sublime uses the keyword scope here; that is plainly incorrect. The default Sublime themes all highlight punctuation.definition. The color scheme you're using should be doing the same.

in jsx key={variable} expressions has no highlighting

This is strange. Both syntaxes highlight key as entity.other.attribute-name, which has been standard since the TextMate days. I don't see why a color scheme should highlight one differently from the other.

in jsx variable names inside an expression propB={typeof valueB === 'function' ? valueB(id) : valueB} has not a black color as they have outside of jsx

I could not reproduce this; they are highlighted identically for me except for the enclosing curly braces. I can only guess that the color scheme you're using is adding the extra color on a meta scope, which is discouraged.

What color scheme are you using? I think that most of the quirks you've identified are due to unusual or nonstandard behavior in the color scheme rather than substantive differences in scoping. Because JS Custom is based directly on the core JavaScript syntax, it should work well with any color scheme that works well with the standard core syntaxes.

@vadzim

This comment has been minimized.

Copy link

commented Oct 15, 2018

@Thom1729 in my sublime that color scheme is named as LAZY. Indeed, js-custom looks better with other color schemes, but babel-sublime still remains easier to use for me because it just works)

I'm not sure I've got your thoughts about arrow functions and what should be filled in that new issue.

I've found another difference:
code:

const { valueA, valueB: varB = { 'fieldA': 'a', fieldB: 'b' }} = {}

babel:
default

js-custom:
default

note valueB color

@Thom1729

This comment has been minimized.

Copy link

commented Oct 15, 2018

in my sublime that color scheme is named as LAZY.

It looks like that's one of the Sublime 2 legacy color schemes. Unfortunately, it doesn't look like those are maintained anymore, so I would expect them to have problems with newer syntaxes. There may be a third-party update out there somewhere.

I'm not sure I've got your thoughts about arrow functions and what should be filled in that new issue.

I had a few spare moments, so I submitted a PR to improve the fallback behavior in that case. Hopefully it will be reviewed and merged into the default package soon. Thanks for pointing out the issue.

const { valueA, valueB: varB = { 'fieldA': 'a', fieldB: 'b' }} = {}

This is rooted in another core syntax bug: the destructuring implementation doesn't correctly handle unbound property names that aren't bare identifiers. This is rather embarrassing; we have four hundred seventy-nine assertions in the bindings test and none of them covers this case. I'll take a look at it posthaste.

@Thom1729

This comment has been minimized.

Copy link

commented Oct 15, 2018

I've submitted a PR to implement the missing cases for object destructuring. Once that change is merged into core, JS Custom will need a minor change to extend string_object_keys.

@sparrowDom

This comment has been minimized.

Copy link

commented Aug 6, 2019

Thanks for he naomi link. This has been my frustration for far too long

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.