RFC: JSX shorthand attributes

[GnsP]

Support shorthand syntax for passing variables as props, where the variable
name is same as the prop name; similar to the shorthand properties in ES6
object literals.

For example : can be written as <Component +prop1 +prop2 /> using the shorthand syntax.

This RFC was originally put on reactjs/rfcs. Here is the relevant PR for that. The full text of the RFC is given below.

Summary

Provide a shorthand syntax for passing variables as props, where the variable
name is same as the prop name; similar to the shorthand properties in ES6
object literals.

Basic example

function Toggle ({ onChange, checked, className }) {
    const toggleClasses = classd`checkbox-toggle ${checked && 'active'} ${className}`;

    function onClick () {
        onChange(!checked);
    }

    return <input type='checkbox' className={toggleClasses} +onClick +checked />;
}

This snippet transpiles to

function Toggle ({ onChange, checked, className }) {
    const toggleClasses = classd`checkbox-toggle ${checked && 'active'} ${className}`;

    function onClick () {
        onChange(!checked);
    }

    return <input 
        type='checkbox' 
        className={toggleClasses} 
        onClick={onClick} 
        checked={checked} />;
}

Motivation

While using react, it happens quite a number of times that we need to:

i. pass a prop down the component chain with the same name
ii. pass a variable / function with the same name as the prop

In such cases, we need to write the same name twice as propName={propName}. This
is redundant. Also with the increase in the use of function components and
useState hooks, the usecase for such props is ever increasing.

Providing a shorthand syntax for passing such props would make the code
concise and encourage developers to write cleaner and less redundant code.

Detailed design

The shorthand syntax, +propName (as recommended in this RFC) is to be supported
by existing JSX transpilers. It can be done by updating the parse and transform functions
for JSXAttribute nodes.

NOTE. This design is intended to work only with JSXIdentifier nodes prefixed with
+ in the JSXAttribute.name field. It should not work with JSXNamespacedName and
should throw an Unexpected Syntax Error otherwise.

In parseJSXAttribute

1. check is the Token starts with a +, i.e. charCodes.plusSign (ascii, 43)
2. if true:
   i. eat the tokens.plusMin Token.
   ii. start a JSXAttribute Node node.
   iii. call parseJSXIdentifier and set node.name and node.value to the parsed JSXIdentifier.
   iv. finish and return node
3. otherwise continue with the existing parseJSXAttribute logic.

In transformJSXAttribute visitor (entry phase)

1. Check if the value in the current node (path.node.value) is a JSXIdentifier.
2. If true, set the value in the current node (path.node.value) to a JSXExpressionContainer containing an Identifier with the name same as the name of the JSXIdentifier. i.e. types.jsxExpressionContainer(types.Identifier(path.node.value.name)) and return.
3. Otherwise continue with the existing visitor logic.

Drawbacks

• It goes against the principle "There should be one-- and preferably only one --obvious way of doing it". With the introduction of shorthand attributes, the way of writing JSX attributes becomes 4:
  1. The Standard <Component propName={expr} />
  2. Spread attributes <Component {...props } />
  3. Boolean attributes <Component booleanProp />
  4. Shorthand attributes <Component +prop1 +prop2 />
• There may be confusion with boolean attributes, the syntactic difference being only the + prefix.
• This proposes adding a new/different semantics to the existing unary + operator, even though this addional semantics is valid only within the context of JSXAttributes Nodes.

Alternatives

• Maintaining the status quo, i.e. requiring the propName and the propValue to be written explicitly.
• Using any other symbol than + as the prefix, so that we do not add to semantics of existing operators. maybe @.

Adoption strategy

This is not a breaking change and does not require any change to the codebase of React itself.
It needs to be implemented by JSX transpilers and can be made available with their release cycle.
Create-react-app, react-scripts, Linters and other existing tools need to support use of newer version of the
JSX transpiler (plugin).

Existing react projects will still be valid with the newer syntax without requiring any change. But
styleguides and linters can provide the options like --allow-jsx-shorthand-attributes to process
the newer syntax as valid, and --use-jsx-shorthand-attributes to convert existing code to use
the shorthand syntax where applicable.

How we teach this

If accepted, the shorthand syntax can be specified and taught in the React/JSX documentation.
Conceptually using this shorthand syntax is optional, just like using <> </> for Fragments.
The teaching strategy, therefore, can be similar to that of the Fragments shorthand.

[ljharb]

Using + seems confusing; as +identifier coerces to a number in JS contexts.

[GnsP]

@ljharb what if we use any other symbol than + as the prefix, so that we do not add to semantics of existing js operators ? maybe @ or & . & does not have any associated semantics as an unary operator / prefix.

[ljharb]

True, but <a b &c> does, because b &c is a bitwise operation in JS.

As for @, since that's effectively reserved for decorators, I'd suggest avoiding that as well.

The only syntax I'm aware of that doesn't have conflicting conceptual overload is <a b {c}>.

[GnsP]

True, but <a b &c> does, because b &c is a bitwise operation in JS.

As for @, since that's effectively reserved for decorators, I'd suggest avoiding that as well.

The only syntax I'm aware of that doesn't have conflicting conceptual overload is <a b {c}>.

@ljharb , yes, that's possibly valid for all symbols with binary operator semantics. <a b {c}> does not have conflicting conceptual overload, but would not it be unusual to allow expressions within braces in almost all contexts in JSX, except for attributes ? In case of shorthand attributes with the syntax <a {c}>, the only valid expression type for c is Identifier. But in case of <a b={c}>, c can be any valid expression.

[GnsP]

Though, in case of JSXSpreadAttributes, we are already limiting the possible types of expressions within the braces {}. I suppose that's quite an exceptional case.

[asbjornh]

What about plain ES shorthand notation, which already works? 🙃

<input {...{ disabled, onClick }} />

[yigalirani]

as a heavy react/jsx user, this feature looks awesome, to say the least. please, please approve it
relevant: https://stackoverflow.com/questions/64700558/most-concise-way-to-pass-props-to-a-react-component

[QbDesu]

What about plain ES shorthand notation, which already works? upside_down_face

<input {...{ disabled, onClick }} />

I prefer this a lot. It's more in line with existing JS syntax (because it just is JS syntax). But the syntax I'd suggest would just be the syntax suggested in #23

return <input {disabled} {onClick} type="button" />

This does more closely resemble JS syntax being reminiscent of shorthand properties on objects. In fact it could even be compiled to exactly that:

return React.createElement("input", { disabled, onClick, type: "button" });