<Escaped> and <Raw> components

[boehs]

• Start Date: 2022-01-23
• Implementation PR: (leave this empty)
• Evans sanity spiral 2/4

Summary

This RFC adds two new components to astro, Raw, and Escaped. Both are frontends for existing or to be implemented features

Example

<Raw><>>>><<<SdsdasSd <$%> {let i = 5;}</Raw>

gets compiled to

<>>>><<<SdsdasSd <$%> {let i = 5;}

---

<Escaped><h1>Yo!</h1></Escaped>

gets compiled to

<h1>Yo!</h1>

Motivation

This makes two astro features more easily accessible.

Detailed design

Raw

• Frontend component for astro-data-raw
• Blocked by compiler/#263

Escaped

• Frontend component for https://github.com/withastro/rfcs/blob/main/active-rfcs/0000-set-html.md
  • Unimplemented RFC

This component is mostly possible using the following code

---
  const { privateRenderSlotDoNotUse: renderSlot } = Astro as any;
  let slot = await renderSlot('default')
  slot = slot.replace(/\s?astro-[A-Z0-9]{8}/,'')
             .replace(/\sclass=""/,'')
             .replace(/</g,'&lt;')
             .replace(/>/g,'&gt;')
---
{slot}

This code escapes html elements, but It does not support escaping {}

Drawbacks

• Adds uneeded complexity
• Not really needed, both of these features are to-be native in astro already.

Alternatives

Just don't do it.

---

Incredibly high quality RFC I know.

[matthewp]

This has come up a few times, and I agree that it's a good feature to add. I'm curious of a component is the right approach. The issue is that this logic probably needs to happen in the compiler and the compiler doesn't know about components. Would something like this work?

<div astro-raw>...</div>

?

[boehs]

This has come up a few times, and I agree that it's a good feature to add. I'm curious of a component is the right approach. The issue is that this logic probably needs to happen in the compiler and the compiler doesn't know about components. Would something like this work?

The compiler has logic for data-astro-raw, but that logic is broken.

In any case, the raw component would end up being a wrapper for data-astro-raw

[jonathantneal]

I understand the compiler concern. Astro would need some way to know that Raw was a true reference to the "Raw" component and not another Raw variable, but I’m not sure if the compiler is capable of that level of analysis.

[jonathantneal]

For an attribute solution, my bikeshed suggestion would be raw:text, complimentary to set:text.

[matthewp]

This has come up a few times, and I agree that it's a good feature to add. I'm curious of a component is the right approach. The issue is that this logic probably needs to happen in the compiler and the compiler doesn't know about components. Would something like this work?

The compiler has logic for data-astro-raw, but that logic is broken.

In any case, the raw component would end up being a wrapper for data-astro-raw

So aside from the broken logic do you have an issue with the approach? As @jonathantneal points out, a component wouldn't work in the compiler do to someone possibly doing this:

import Thing from 'some/package';
const { Raw } = Thing;

However, as @jonathantneal suggests we could have a special attribute like raw:text.

[jonathantneal]

With a special blessing from @boehs, I will also present the raw:text alternative.

[jonathantneal]

Early Feedback from the Community RFC Call (2022-01-25)

• Lots of positive feedback to support the idea of this feature.
• Implementation of <Escaped> or <Raw> is problematic, because those uppercase-leading elements maps to a JavaScript variable, and JavaScript variables are not evaluated in the compiler.
• Lots of positive feedback to support an attribute, like raw:html. Naming TBD by a formal proposal.
• Strong desire to support raw content, which may use otherwise-escaped HTML entities, like > for Markdown block-quotes.
• Strong desire to use a syntax style complementary to set:html and set:text.
• Recommendation to @boehs: If you are interested, create a formal RFC using an attribute syntax, including use-cases, and including a formalized syntax.