mikeconrad/blog
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update astrowind-template-in-depth.mdx

Browse Source
This commit is contained in:
widgeter
2023-08-14 08:55:49 -04:00
committed by GitHub
parent 6c2ba7a62c
commit dace8cd5ed
1 changed files with 3 additions and 60 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
src/content/post/astrowind-template-in-depth.mdx
View File

@ -27,7 +27,7 @@ As the name suggests, _AstroWind_ relies on _TailWind_ for styling. Furthermore,
The styling mechanism consists of the following files (all paths are prefixed with `/src/` ):
<DListItem dt="assets/styles/base.css">
<DListItem dt="assets/styles/tailwind.css">
This file is essentially an extension of _TailWind's_ base.css. High-level component styles are defined here. Note
also styling on elements selected by 'attribute' selectors at the bottom of the files, particularly those selected by
'data' attributes.
@ -36,12 +36,8 @@ The styling mechanism consists of the following files (all paths are prefixed wi
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.
</DListItem>
<DListItem dt="layouts/BaseLayout.astro">
This layout is used for all of the pages rendered by _AstroWind_. The contents of _MetaTags.astro_ component,
<DListItem dt="layouts/Layout.astro">
This layout is used for all of the pages rendered by _AstroWind_. The contents of _tailwind.css_ and _CustomStyles.astro_ component,
described above, is injected into the html header.
</DListItem>
@ -209,56 +205,3 @@ const { subtitle = await Astro.slots.render('subtitle') } = Astro.props;
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>
<tr>
<td class="font-bold">Note:</td>
<td>
There's a _lot_ of duplicate (or at least very similar code) in the following components, especially as regards the _CallToAction_ mechanism -- adding to a lot of confusion and something of a maintenance headache:
<div class="ml-8">
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 { callToAction = await Astro.slots.render('callToAction') } = Astro.props;
// also rendered as a slot
---
<div>
...
{
typeof callToAction === 'string' ? (
<Fragment set:html={callToAction} />
) : (
callToAction &&
callToAction.text &&
callToAction.href && (
<div class="mt-6 max-w-xs mx-auto">
<a class="btn btn-primary w-full sm:w-auto" href={callToAction.href} target="_blank" rel="noopener">
{callToAction.icon && <Icon name={callToAction.icon} class="w-5 h-5 mr-1 -ml-1.5" />}
{callToAction.text}
</a>
</div>
)
)
}
</div>
```
First, the property type is checked to see if it's a string: if so, it's just set into a child _&lt;Fragment&gt;'s_ html.
If not, it is validated as an object and then members of the object are assigned to various
html elements.