Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Nested list components using JSX expressions throw error #811

Open
1 task
TheOtterlord opened this issue Jun 22, 2023 · 3 comments
Open
1 task

Nested list components using JSX expressions throw error #811

TheOtterlord opened this issue Jun 22, 2023 · 3 comments
Labels
- P2: nice to have Not breaking anything but nice to have (priority)

Comments

@TheOtterlord
Copy link
Member

What version of astro are you using?

2.6.6

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

None

What package manager are you using?

npm

What operating system are you using?

Linux

What browser are you using?

Firefox

Describe the Bug

This isn't a vital bug (at least not this reproduction) because it misuses li elements.

If you nest a list of li elements in a JSX expression, surrounded by an li element, Astro throws an error.

---
---

<html lang="en">
	<head>
		<meta charset="utf-8" />
		<link rel="icon" type="image/svg+xml" href="/favicon.svg" />
		<meta name="viewport" content="width=device-width" />
		<meta name="generator" content={Astro.generator} />
		<title>Astro</title>
	</head>
	<body>
		<ul>
			<li>
				{
					[''].map(() => (
						<li></li>
					))
				}
			</li>
		</ul>
	</body>
</html>

What's the expected result?

Correctly render the elements

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-aft2nh?file=src%2Fpages%2Findex.astro&on=stackblitz

Participation

  • I am willing to submit a pull request for this issue.
@natemoo-re
Copy link
Member

Ah yes, one of our fun compiler edge cases. Because li > li isn't valid, the compiler silently "corrects" the markup but ends up breaking the expression in the process. It's definitely worth rethinking how that works, but it's a huge task so I'm not sure when we'll be able to tackle it.

Temporary workaround if this output is ever needed for some reason... wrapping invalid markup in a <Fragment> or using set:html usually does the trick.

@natemoo-re natemoo-re added the - P2: nice to have Not breaking anything but nice to have (priority) label Jun 22, 2023
@RobertDS07
Copy link

@natemoo-re, but is there any motivation to have li > li? Considering the HTML standard, it mentions how li can be used. In this case, an error is expected, and it would be strange if there weren't an error, don't you think?

image

@natemoo-re natemoo-re transferred this issue from withastro/astro Jun 27, 2023
@natemoo-re natemoo-re mentioned this issue Jul 19, 2023
Closed
1 task
@MoustaphaDev
Copy link
Member

MoustaphaDev commented Dec 20, 2023 •
edited
Loading

@RobertDS07 I think the issue is that the compiler shouldn't generate invalid code when the markup is invalid, it should try to correct it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
- P2: nice to have Not breaking anything but nice to have (priority)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@natemoo-re @RobertDS07 @TheOtterlord @MoustaphaDev