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

Should webc:nokeep be required on templates that use a single render-function #135

Closed
darthmall opened this issue Mar 21, 2023 · 7 comments
Closed

Should webc:nokeep be required on templates that use a single render-function #135

darthmall opened this issue Mar 21, 2023 · 7 comments
Labels
bug Something isn't working
Milestone
WebC v0.10.0

Comments

@darthmall
Copy link

I don’t know if this should be considered a bug or not. It caught me by surprise, but I can understand why it happens, so maybe it’s just an education problem…

Using a single render function in a template to generate your HTML—instead of just a plain HTML template—requires the use of webc:nokeep to remove the custom element from the output.

Example

test-html-component.webc

<p>hello</p>

test-render-fn.webc

<script webc:type="js">
  "<p>hello</p>";
</script>

index.webc

<test-html-component></test-html-component>
<test-render-fn></test-render-fn>

Output

<p>hello</p>
<test-render-fn><p>hello</p></test-render-fn>

Expected (?) Output

<p>hello</p>
<p>hello</p>

Part of me thinks that since the render function is just generating HTML, it should be treated like an HTML-only template and the custom element should be automatically removed (this was my assumption at the outset). Especially since some logic requires a render function—e.g. loops and if-else blocks—so conceivably, a person would have to use a render function for an HTML-only component.

On the other hand, you could argue that the presence of a <script> tag in the template means it is not an HTML-only component, and if you want to automatically remove the custom element, you should just add webc:root=override to the <script>.
@zachleat
Copy link
Member

zachleat commented Mar 21, 2023 •
edited
Loading

you know what, I think this is a bug. We should ignore host component names outside of <body> by default.

@zachleat zachleat added the bug Something isn't working label Mar 21, 2023
@darthmall
Copy link
Author

One thought that occurs to me is what should happen in the case where the render function returns HTML and CSS/JS?

test-render-fn.webc

<script webc:type="js">
  `<p>hello</p>
  <style>
    p { color: tomato }
  </style>`;
</script>

I would expect that in this case the custom element remains in the output. But this also seems like it’s making evaluation of a template like this very difficult for WebC (and also perhaps for developers to understand).

@zachleat
Copy link
Member

zachleat commented Mar 21, 2023 •
edited
Loading

Just for extra clarity I don’t think it’s valid in any scenarios to output custom element names outside of a <body>. You can output HTML and render HTML fine, but if it isn’t a standard HTML tag name it shouldn’t exist in <head>!

So style should work but my-custom-style would not!

@darthmall
Copy link
Author

So let me make sure I understand: when using a WebC template in the head by doing something like this:

<head>
  <meta webc:is="og-meta" />
</head>

Under no circumstances would you permit <og-meta></og-meta> to be written in the output because it’s in the <head> of the document?

I think that’s handy, but the example I gave above is actually happening in the <body>. Originally when I tooted at the Eleventy account, I thought this was a bug relating to templates in <head>, but I discovered it’s reproduce-able in the <body> as well.

Are you proposing that the behavior of <test-render-fn></test-render-fn> in my example above would remain unchanged, but if I used a render function for a component that was writing out <meta> tags in the head, I would be able to omit webc:nokeep because it’s in the <head>?

That seems pretty reasonable to me. Ensuring that WebC doesn’t knowingly generate invalid HTML seems fine, I just want to be sure I understand what you’re saying. 😅

@zachleat
Copy link
Member

zachleat commented Mar 22, 2023 •
edited
Loading

Under no circumstances would you permit to be written in the output because it’s in the of the document?

Yes.

Are you proposing that the behavior of in my example above would remain unchanged, but if I used a render function for a component that was writing out tags in the head, I would be able to omit webc:nokeep because it’s in the ?

Independent of the other caveat mentioned above I agree with your expected output for <test-render-fn>—it should ignore the parent tag. Looks like there is a bug with the code that determines whether or not to ignore a parent tag. <script webc:type="js"> should be exempted from that as it has an implied webc:is="template" by default.

@zachleat zachleat mentioned this issue Mar 22, 2023
Open
@zachleat
Copy link
Member

Filed that ancillary issue here: #137

@zachleat
Copy link
Member

Shipping with 0.10.0

@zachleat zachleat added this to the WebC v0.10.0 milestone Mar 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
WebC v0.10.0
Development

No branches or pull requests
2 participants
@zachleat @darthmall