JSX Feature: Optional Curly Braces for Attributes

[lxsmnsyc]

This feature would allow JSX to allow optional usage of curly braces when providing JS expressions for attributes.

<button onClick=increment>Increment</button>
<Button value=3.14159 />

Considered

The feature would only apply to the following expressions:

• ArrayLiteral

<For each=[1, 2, 3] />

• Identifier
  • NullLiteral
  • BooleanLiteral

<button onClick=increment>Increment</button>
<button disabled=true>Example</button>
<Input value=null />
<Input value=undefined />

• StringLiteral

<a href="mailto:">Mail</a>
<a href='mailto:'>Mail</a>

• NumericLiteral

<Number value=3.14159 />
<Number value=0xDEADBEEF />
<Number value=0x10010110 />

• RegularExpressionLiteral

<InputMask pattern=/^\d+$/ />

• TemplateLiteral

<Message value=`${greeting}, ${name}` />

• ParenthesizedExpression

<button onClick=(() => increment(100))>Increment By 100</button>

Not considered

Most of the rejected expressions relates to allowing whitespace for tokens that do not have opening/closing symbols (which allows definition of token boundaries).

• FunctionExpression, AsyncFunctionExpression, GeneratorExpression, AsyncGeneratorExpression, ClassExpression - The syntax has no initial opening/closing tokens that would allow proper identification. Would require curly braces or parentheses to work (see ParenthesizedExpression)
• ArrowFunction - allows optional whitespace, doesn't have initial opening/closing tokens for proper identification. Requires curly braces or parentheses.
• MemberExpression, ImportMeta, OptionalChain - allows optional whitespace between chains, doesn't have initial opening/closing tokens for proper identification. Requires curly braces or parentheses
• ObjectLiteral - conflict with curly braces.
• NewExpression - requires whitespace
• CallExpression, ImportCall - allows optional whitespace between callee and the parameter list.
• UnaryExpression, AssignmentExpression, BinaryExpression, TernaryExpression - allows optional whitespace

[DylanPiercey]

FYI Marko's parser handles this but in a way that supports the vast majority of JS/TS expressions as attributes, mostly the only cases that our parser would not treat as an expression is when it conflicts with the html syntax, eg <tag x=a>b for obvious reasons is not going to treat a>b as the expression.

It works by maintaining a stack for enclosed sections (think string literals, brackets, regexps) and then outside of any enclosed thing using a regex that will match TS/JS binary and unary operators (https://github.com/marko-js/htmljs-parser/blob/main/src/states/EXPRESSION.ts#L214-L235)

You can see the types of values that can be expressions in our test snapshot here: https://github.com/marko-js/htmljs-parser/blob/main/src/__tests__/fixtures/attr-operators-space-between/__snapshots__/attr-operators-space-between.expected.txt

Just thought it might be interesting!

[lxsmnsyc]

I think the part where it becomes confusing is the consistency of expressions (because of the markup's limitation)

[DylanPiercey]

Could you elaborate?

[lxsmnsyc]

Since you mentioned that there are expressions in Marko that are supported but there are some that isn't, specifically those that conflict with the markup. So I felt like some user would find it surprising.

[DylanPiercey]

In Marko there's not really much that can conflict. For HTML mode it's > and for concise mode its newlines and --.

[DylanPiercey]

I think when you see it syntax highlighted it's obvious why those two don't work.