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.

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

CoreListItem return sublist html in attributes.content #253

Open
MKlblangenois opened this issue Jul 2, 2024 · 2 comments
Open

CoreListItem return sublist html in attributes.content #253

MKlblangenois opened this issue Jul 2, 2024 · 2 comments
Labels
needs: discussion Requires a discussion to proceed scope: html parsing

Comments

@MKlblangenois
Copy link

When I create a list with sublist inside <li>, the query in attributes.content of parent <li> return all HTML content, and duplicate the content at the end of content:

https://github.com/wpengine/wp-graphql-content-blocks/assets/42929225/992249b9-cd10-4b87-ab04-48420ab83435

@theodesp
Copy link
Member

theodesp commented Jul 8, 2024

Hey @MKlblangenois. Looking at the core/list-item block.json spec it looks like this is the expected behavior. The content attribute for this is located here:

https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/list-item/block.json

		"content": {
			"type": "rich-text",
			"source": "rich-text",
			"selector": "li",
			"__experimentalRole": "content"
		}

the selector targets a single li element so it will grab the content of the <li/> HTML node which will contain innerHTML. So the result will be HTML

@jasonbahl jasonbahl added the needs: discussion Requires a discussion to proceed label Jul 30, 2024
@jasonbahl
Copy link
Contributor

@MKlblangenois @theodesp I have 2 thoughts on this.

My first thought was:

Any field that returns HTML should return valid HTML. i.e. this field should return the HTML and include the opening and closing <li> tag so the client doesn't need to to this.

Since this field returns invalid HTML, it requires the user to wrap the field in an <li>{field.value}</li> which is confusing for users to consume and render.

However, the __typename of the Block does indicate what Type of block it is and core/list-item does declare that it is indeed a "list item" which is represnted by <li> so as a client consuming this block, it's not entirely uncalled for do to something like:

(pseudo)

switch ( block.__typename ) {
  case: 'core/list-item':
     return <li>{block.attributes.content}</li>
}

I think long-term it would be nice to see fields that return HTML return valid HTML though. If core WPGraphQL were to introduce an HTML Scalar, this field would fail validation as-is, for example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs: discussion Requires a discussion to proceed scope: html parsing
Projects
None yet
Development

No branches or pull requests

3 participants