JSXTransformer, concatenate consecutive strings #489
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
JSXTransformer currently produces suboptimal code when fixed strings are inserted with braces,
{'Abc'}
or{"Abc"}
, as is required if you want to override the JSX whitespace collapsing.This means that
<div>A{'\n'}B</div>
does not generate 1 div, but 1 div and 3 spans<div><span>A</span><span>\n</span><span>B</span></div>
rather than just<div><span>A\nB</span></div>
.My proposed changes treats
{'Abc'}
and{"Abc"}
, and ONLY those as if they were actually written inline without braces, but after whitespace collapsing has occured, so their content is exactly what ends up in the DOM. To clarify{StringVar}
,{'A'+'B'}
and even{('Abc')}
are not transformed, so this will have no effect on runtime keying.If my PR for stricter whitespace collapsing rules is accepted, this will hopefully be less of an issue. But still, a single
{'\n'}
can cause 0 spans to become 3 which can be a heavy price considering the DOM is the costly part, and this is part of the JSXTransformer which in my opinion, should make a reasonable effort to generate "fast code" as long as it doesn't affect readability.I also removed a duplicated piece of code (I can move it into it's own PR), because it simplifies the implementation of this PR.
Example
Before
Although a contrived example, this will end up creating 9 spans.
After
After fixed strings have been concatenated, only 5 spans will be generated. Note that the two expressions with
Var
have not been concatenated, but remains as arguments, and as such still have their own spans.