|
|
|
|
@ -1,5 +1,5 @@
|
|
|
|
|
---
|
|
|
|
|
publishDate: 2023-01-08T00:00:00Z
|
|
|
|
|
publishDate: 2023-07-17T00:00:00Z
|
|
|
|
|
title: AstroWind template in depth
|
|
|
|
|
description: Internals documentation
|
|
|
|
|
excerpt: While easy to get started, Astrowind is quite complex internally. This page provides documentation on some of the more intricate parts.
|
|
|
|
|
@ -32,7 +32,7 @@ The styling mechanism consists of the following files (all paths are prefixed wi
|
|
|
|
|
Note also styling on elements selected by 'attribute' selectors at the bottom of the files, particularly those selected by 'data' attributes.
|
|
|
|
|
</DListItem>
|
|
|
|
|
<DListItem dt="components/CustomStyles.astro">
|
|
|
|
|
Defines custom colors and fonts. For these to take effect in the 'base.css' file, they have to be loaded in the html header section. See next.
|
|
|
|
|
Defines custom colors and fonts. For these to take effect in the 'base.css' file, they need to be loaded in the html header section. See next.
|
|
|
|
|
</DListItem>
|
|
|
|
|
<DListItem dt="components/common/MetaTags.astro">
|
|
|
|
|
Instantiates the _CustomStyles.astro_ component, along with other meta information (as the name implies). All of this is injected in to the header - see next.
|
|
|
|
|
@ -91,6 +91,7 @@ There's another way we can use slots, useful particularly when a component can h
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const content:string = await Astro.props.render('default');
|
|
|
|
|
// renders the html to the 'content' variable
|
|
|
|
|
---
|
|
|
|
|
<div>
|
|
|
|
|
<h2>{title}</h2>
|
|
|
|
|
@ -121,7 +122,7 @@ This allows a great deal of flexibility in component design.
|
|
|
|
|
|
|
|
|
|
### Yet Another Step
|
|
|
|
|
|
|
|
|
|
Now, we get to the techniques used in _AstroWind_, particularly in the main _pages/index.astro_ file.
|
|
|
|
|
Now, we get to the techniques used in _AstroWind_, we'll use the _pages/index.astro_ file to illustrate.
|
|
|
|
|
|
|
|
|
|
You'll note that the index file imports a lot of components, each one roughly analagous to a panel in the index page. Each of these components, in turn, is instantiated sequentially throughout the page. But, you'll notice that some of them use this kind of construct (we'll use the last section, _CallToAction_, as it is most illustrative of the technique):
|
|
|
|
|
|
|
|
|
|
@ -157,9 +158,12 @@ The answer lies in a paragraph in the _Astro_ docs, slots section, which states:
|
|
|
|
|
|
|
|
|
|
> Use a `slot="my-slot"` attribute on the child element that you want to pass through to a matching slot `name="my-slot" />` placeholder in your component.
|
|
|
|
|
|
|
|
|
|
That's a bit of a head-scratcher to read, but basically what it says is that you can reference a slot from a child of a component that defines a slot, and provide the contents to the parent component's slot as something of a surrogate.
|
|
|
|
|
That's pretty concise and a bit of a head-scratcher to read, but basically what it says is that:
|
|
|
|
|
1. Given a component that defines a slot:
|
|
|
|
|
1. you can reference a slot from a child element of that component and,
|
|
|
|
|
1. provide content to the parent component's slot from the child by naming the slot in the child with a `slot="<slot-name>"` property assignment, where the _slot-name_ is the parent's slot.
|
|
|
|
|
|
|
|
|
|
So, in the example above, the _CallToAction_ component defines the _subtitle_ slot, and the following _<Fragment slot="subtitle">_ with the following content:
|
|
|
|
|
So, in the example above, the _CallToAction_ component defines the _subtitle_ slot, and the following _<Fragment slot="subtitle">_ with populates the slot with the following content:
|
|
|
|
|
|
|
|
|
|
```astro
|
|
|
|
|
<Fragment slot="subtitle">
|
|
|
|
|
@ -187,8 +191,26 @@ There's a lot to wrap your head around, here.
|
|
|
|
|
Notice first that _subtitle_ is defined as a prop/argument, but it's being processed as a slot. Interestingly, prop args and slots seem to be somewhat interchangeable: if the subtitle was just a string, it would simply take that assignment. The main difference is that if you render them independently, you have to call the render with an _await_ modifier.
|
|
|
|
|
|
|
|
|
|
## CallToAction Property
|
|
|
|
|
<table style="color:red">
|
|
|
|
|
<tr>
|
|
|
|
|
<td class="font-bold">Note:</td>
|
|
|
|
|
<td>
|
|
|
|
|
There's a _lot_ of duplicate code in the following components, especially as regards the _CallToAction_ mechanism -- adding to a lot of confusion and something of a maintenance headache:
|
|
|
|
|
|
|
|
|
|
Finally, note that the _CallToAction_ property can be of type `string | CallToAction` where the `CallToAction` is a typed object. In the component, this is handled thusly:
|
|
|
|
|
<div style="margin-left:2em;">
|
|
|
|
|
src/components/widgets/Hero.astro
|
|
|
|
|
src/components/widgets/Steps2.astro
|
|
|
|
|
src/components/widgets/CallToAction.astro
|
|
|
|
|
src/components/widgets/Hero2.astro
|
|
|
|
|
src/pages/landing/startup.astro
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Seems like this could be cleaned up.
|
|
|
|
|
</td>
|
|
|
|
|
</tr>
|
|
|
|
|
</table>
|
|
|
|
|
|
|
|
|
|
The _CallToAction_ property can be of type `string | CallToAction` where the `CallToAction` is a typed object. In the component, this is handled thusly:
|
|
|
|
|
```astro
|
|
|
|
|
---
|
|
|
|
|
const {
|
|
|
|
|
@ -218,7 +240,8 @@ Finally, note that the _CallToAction_ property can be of type `string | CallToAc
|
|
|
|
|
```
|
|
|
|
|
First, the property type is checked to see if it's a string: if so, it's just set into a child _<Fragment>'s_ html.
|
|
|
|
|
|
|
|
|
|
If not, it is validated and then...
|
|
|
|
|
If not, it is validated as an object and then members of the object are assigned to various
|
|
|
|
|
html elements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rickbsgu