an odd and unclear behaviour when using jsx-like syntax

[gustavobini]

What version of astro are you using?

1.6.12

Are you using an SSR adapter? If so, which one?

@astrojs/[email protected] | Node.js version is 18.12.1

What package manager are you using?

[email protected]

What operating system are you using?

Mac

Describe the Bug

When using the JSX-like syntax, the behaviour is a bit odd.

Given this example,

---
const props = {
	class: "red"
}
---
<h1 class="blue" {...props}>Should I be blue or red?</h1>
<h1 {...props} class="blue">I'm neither blue or red.</h1>
<h1 {...props}>I'm red.</h1>

<style>
	.red {
		color: red;
	}

	.blue {
		color: blue;
	}
</style>

The HTML output is,

<h1 class="blue astro-HJZ3CPP6">Should I be blue or red?</h1>
<h1 class="red">I'm neither blue or red.</h1>
<h1 class="red astro-HJZ3CPP6">I'm red.</h1>

The first h1 is blue, so props.class is ignored. - This could benefit from a mention in docs, if it's intended
The second h1 is black, even though it receives the red class. - This seems like a bug
The third h1 is red. - This behaves as expected

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-qkr4u8?file=src/pages/index.astro

Participation

• I am willing to submit a pull request for this issue.

[bluwy]

I think this is similar to withastro/compiler#659. We're currently discussing how this should be treated as spreading would simply spread the props as is without accounting for the surrounding props on the element. So you could get duplicated attributes but the browser would pick the first one.

The second h1 is black, even though it receives the red class. - This seems like a bug

This seems like a different bug though so not closing this for now.

[matthewp]

I'm surprised that (2) does not receive the hash class name but (3) does. I would almost expect (3) not too, but then again I'm not super familiar with the hash assignment code. Maybe @natemoo-re has insight here.

[natemoo-re]

Closing this in favor of withastro/compiler#659