Though the current implementation is fine, what do you think if we add a more advanced support that tries to parse and print the content in {here}? we could normalize quotes ({a+'str'} -> {a+"str"}) for example.

Ah yeah, that would certainly be nice. Is there any example of this somewhere? The value is just javascript so I'd imagine we could use the javascript parser/printer with some modifications (i.e. no trailing semicolon).

It should be just a matter to use textToDoc to get the Doc from regular JavaScript printer, remove all whitespaces and force printing it in flat mode. Something like:

try {
  const jsDoc = textToDoc(/* key={code} */ code, {
    parser: "__js_expression"
  });
  const jsDocWithoutWhitespaces = mapDoc(jsDoc, doc => 
    doc.type === "line" || doc.type === "break-parent"
      ? ""
      : doc.type === "if-break"
      ? doc.flatContents
      : typeof doc === "string"
      ? doc.replace(/\s/g, "")
      : doc
  });
  return concat([node.rawName, "={", jsDocWithoutWhitespaces, "}"]);
} catch (e) {
  // fallback to the current logic if it cannot be parsed
  return ...
}

@ikatyang I tried this out and it seems that any time I put a quote or space inside the attribute value it breaks the parser completely because it isn't valid HTML. For example, I can't use:

<div data-one={foo["baz"]} data-two={foo[ "baz" ]}></div>

Neither of those options is successfully parsed. I am not sure what other cases would be fixed by this so I'm not sure if the textToDoc is needed at all. Let me know what you think.

It's indeed an invalid HTML if there're spaces, which is expected. But it should be valid for quotes, this looks like a bug in the HTML parser, we probably need to open another issue to track this bug and add this feature in other PR.

I opened two bugs to track this. #5815 and #5816 to track these issues.