Replies: 8 comments 9 replies
-
|
I don't really like this idea. The triple dashes make it more seperate and emphasizes that that is build time run javascript etc. |
Beta Was this translation helpful? Give feedback.
-
|
For backward compatibility - I think the frontmatter syntax probably wouldn't be able to go away for quite some time anyway, so maybe I should have phrased this differently - maybe allow script tags in addition to frontmatter? Although that'd introduce multiple ways of doing the same thing, which also maybe less than ideal. I agree that frontmatter emphasizes the separation between what's build time and what isn't, but I don't think learning one special Thinking about this some more - we could even have multiple astro tags: <script astro:build>
// ...
</script>
<script astro:ssr>
// ...
</script>
<script astro:client>
// ...
</script>Like the |
Beta Was this translation helpful? Give feedback.
-
|
+1 With the script tag it would automatically work in all IDEs fairly well out-of-the-box. It's just HTML with some JSX additions. The Frontmatter syntax on the other hand requires special plugins for all IDEs, including WebStorm/Jetbrains – Astro is currently not usable with WS which is a blocker for many. The workaround with the Textmate bundle is just that (fixes syntax errors but nothing else, no autocompletions, quick fixes, intelligence in any sense, etc.). Besides, it "feels" more like you're doing actual web dev... in a familiar syntax. |
Beta Was this translation helpful? Give feedback.
-
|
+1 I really like Frontmatter and the simplicity it adds but I feel like using it in a .astro is slightly awkward. To me Frontmatter is tained by its most common use in Markdown. So frontmatter to me = YAML while script = JS. The above proposed script solution with astro namespace tags is likely the most justifiable. Also I think having a .astro extension disengages concerns about cross-pollinating standard HTML script tag. I could argue that the .astro file extension helps assert the DSL inside the file. The astro namespace within the script tag actually reinforces the file designation so the colocation seems more intentional. This to me feels like a firmer argument than using arbitrary and untagged/unspecified Frontmatter. |
Beta Was this translation helpful? Give feedback.
-
|
What is nice about the frontmatter syntax is that it is a clear separate from the template part. In Svelte and other similar frontend oriented frameworks the If we used <script astro>
import MyHeader from '../components/Header.astro';
</script>
<html>
<head>
<title>My page</title>
<script>/* A regular in-page script tag */</script>
</head>
<body>
<MyHeader title="My page" />
</body>
</html> |
Beta Was this translation helpful? Give feedback.
-
|
If we're talking awkward, I think both the script tag and front matter are equally awkward :) And while the script tags are awkward in situations where there's <script astro>
const title = Astro.fetchContent('');
</script>
<h1> Hello World {title}</h1>---
const title = Astro.fetchContent('');
---
<h1> Hello World {title}</h1> |
Beta Was this translation helpful? Give feedback.
-
|
Ah yes, good point! We definitely made the decision to go with the dashes based on the page component problem, like I said that's something that frameworks don't (usually) have to worry about. But I definitely agree that it's largely a personal preference! What I find awkward others might not mind and vice versa. Curious to hear how others feel in this issue. |
Beta Was this translation helpful? Give feedback.
-
|
My personal take is thinking about the probability of user error.
I can also understand the potential advantages of distinguishing SSR and build scripts, or explicitly supporting |
Beta Was this translation helpful? Give feedback.
-
|
Speaking of user error, in markdown files, |
Beta Was this translation helpful? Give feedback.
-
That might be the aspiration, but we're not there yet. After trying to build a couple of sites with Astro and Svelte I've hit a lot of bugs and quirks making it impossible for me to actually use Svelte - which is actually where this suggestion is kind of coming from. I've found that for a lot of things I don't really need Svelte - I just need a way to make small neat self-contained components. And for that, the triple dashes are awkward. Also, .astro files still don't have a VSCode formatter (without installing prettier) because no other language uses |
Beta Was this translation helpful? Give feedback.
-
|
I personally also prefer the current syntax over a The context in which the frontmatter and script tags run is so different that I'd rather we have them as separate as possible. I actually personally like that it's similar to Markdown because I like to think of the frontmatter of Astro files as the "metadata" of the file? I don't know if that makes sense but it fits my way of thinking very well 😅 And just for context on the editor integration part (as the person working on all of our editor integration things at Astro), using a script tag wouldn't make it any easier to support things really. It wouldn't make parsing necessarily easier, JSX does not support script tags so no grounds gained there, frontmatter and script tags run in separate contexts so you still need special care etc etc For formatting, we already have a Prettier plugin, almost since the birth of Astro actually 😅 Using script tags wouldn't have made it easier, the Svelte prettier plugin, which is what they use in VS Code, is pretty Svelte-exclusive. It uses their compiler to parse files and their compiler, script tag or not, does not support Astro files for sure haha 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Exactly! Also it would be weird if you would have to use different frontmatters. Like |
Beta Was this translation helpful? Give feedback.
-
|
So I learned Frontmatter is actually defined in the traditional sense as:
Software has appropriated the concept to mean the head of the file and it works well that way. The most common use and perhaps only that I've seen to date, is as a KV structure usually to define configuration or specification for the material contained within the document. Bringing it back to Astro, sure you can use it as the logic/scripting ahead of the body but it really takes the definition of "frontmatter" very far outside the original meaning and common use. In practical terms the importance of the frontmatter is arguably secondary, despite being preliminary to the body. In the Astro case JS (typically the longer business logic portion) is being placed in a location considered secondary/preliminary. This insinuates or inherently emphasizes the markup is the critical piece. This may be intended intended in which case it triggers more thoughts/concerns. Regardless of what the intention is, it feels rather inappropriate to repurpose in this manner? Like a square peg in a round hole. |
Beta Was this translation helpful? Give feedback.
-
|
Tech is not traditional books. I actually even think it's pretty similar. You tell the reader what to expect -> You tell astro what to insert :) |
Beta Was this translation helpful? Give feedback.
-
|
I'm not trying to compare it to traditional books I'm trying to assert the meaning or intention of Frontmatter concept in origin from book to software. Basically it was extended to mean basically configuration or metadata for a file. Like header info. Now we're extending with business logic. It's not really a congruent use of the idea of Frontmatter. I rather see Astro invent a whole new syntax for this than repurposing something used differently more times than not. Perhaps a new syntax or tag structure? Some possible alternatives (not sure if this works with the compiler):
I personally like the HTML tag option but the PHP/ASP option is interesting. |
Beta Was this translation helpful? Give feedback.
-
It is now! |
Beta Was this translation helpful? Give feedback.
-
|
The current syntax makes sense in an HTML-first kind of way, but requires it comes with a significant maintenance burden for various toolings you need to maintain, and bugs. For a plain JavaScript syntax, that works for both HTML and JSON responses, take a look at e.g. https://mastrojs.github.io |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Is it too late to change the syntax of Astro?
I think frontmatter makes a lot of sense in markdown files, but in
.astrofiles it just feels like an awkward HTML augmentation.So instead of triple dashes, I'd really love to see something like:
The added benefit of using just plain script tags is that I think it would be a lot easier to make a VScode formatter by just forking whatever Svelte is already using and removing things like
{#if ...Beta Was this translation helpful? Give feedback.
All reactions