Fix minor typos
This commit is contained in:
prototypa
@ -11,8 +11,9 @@ tags:
|
||||
- front-end
|
||||
canonical: https://astrowind.vercel.app/astrowind-template-in-depth
|
||||
---
|
||||
import DListItem from "../../components/widgets/DListItem.astro";
|
||||
import ToggleTheme from "../../components/common/ToggleTheme.astro";
|
||||
|
||||
import DListItem from '../../components/widgets/DListItem.astro';
|
||||
import ToggleTheme from '../../components/common/ToggleTheme.astro';
|
||||
|
||||
## Overview
|
||||
|
||||
@ -27,23 +28,27 @@ 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">
|
||||
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.
|
||||
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.
|
||||
</DListItem>
|
||||
<DListItem dt="components/CustomStyles.astro">
|
||||
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.
|
||||
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.
|
||||
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, described above, is injected into the html header.
|
||||
This layout is used for all of the pages rendered by _AstroWind_. The contents of _MetaTags.astro_ component,
|
||||
described above, is injected into the html header.
|
||||
</DListItem>
|
||||
|
||||
### Dark Mode
|
||||
|
||||
_Dark Mode_ is triggered by the little 'sunlight' icon:<ToggleTheme/>in the page header. It is defined in the _components/common/ToggleTheme.astro_, but the event is attached and the action defined in _components/common/BasicScripts.astro_ in the following snippet:
|
||||
|
||||
```javascript
|
||||
attachEvent('[data-aw-toggle-color-scheme]', 'click', function () {
|
||||
if (defaultTheme.endsWith(':only')) {
|
||||
@ -53,51 +58,63 @@ _Dark Mode_ is triggered by the little 'sunlight' icon:<ToggleTheme/>in the page
|
||||
localStorage.theme = document.documentElement.classList.contains('dark') ? 'dark' : 'light';
|
||||
});
|
||||
```
|
||||
|
||||
Note that this is a client event. _BasicScripts.astro_ defines several other client-side functionality as well as this one.
|
||||
|
||||
## Advanced Slot Usage
|
||||
|
||||
_slots_ are part of the component implementation, which is a common concept among many frameworks, including _Astrojs_. The typical slot definition in a component looks like this:
|
||||
|
||||
```astro
|
||||
// (file: MyComponent.astro)
|
||||
---
|
||||
// (file: MyComponent.astro)
|
||||
const { title } = Astro.props;
|
||||
interface Props = {
|
||||
title:string
|
||||
export interface Props {
|
||||
title: string;
|
||||
}
|
||||
---
|
||||
|
||||
<div>
|
||||
<h2>{title}</h2>
|
||||
<slot/> <!-- slot contents injected here -->
|
||||
<div>
|
||||
<slot />
|
||||
<!-- slot contents injected here -->
|
||||
<div></div>
|
||||
</div>
|
||||
```
|
||||
|
||||
And in usage elsewhere:
|
||||
|
||||
```astro
|
||||
import MyComponent from "~/components/MyComponent";
|
||||
...
|
||||
import MyComponent from "~/components/MyComponent"; ...
|
||||
<MyComponent someArg="A Slot example">
|
||||
<p>This content will be displayed in the slot</p>
|
||||
</MyComponent>
|
||||
```
|
||||
|
||||
### Alternate usage
|
||||
|
||||
There's another way we can use slots, useful particularly when a component can have markdown content is as follows (study carefully...):
|
||||
|
||||
```astro
|
||||
---
|
||||
// (file: MyComponent.astro)
|
||||
---
|
||||
const {title} = Astro.props;
|
||||
interface Props = {
|
||||
title:string
|
||||
}
|
||||
|
||||
const { title } = Astro.props;
|
||||
export interface Props {
|
||||
title: string;
|
||||
}
|
||||
const content: string = await Astro.props.render('default');
|
||||
// renders the html to the 'content' variable
|
||||
---
|
||||
|
||||
// renders the html to the 'content' variable
|
||||
<div>
|
||||
<h2>{title}</h2>
|
||||
<div set:html={content}/> <!-- slot contents injected here -->
|
||||
<div>
|
||||
<div set:html={content} />
|
||||
<!-- slot contents injected here -->
|
||||
<div></div>
|
||||
</div>
|
||||
```
|
||||
|
||||
Whoa!! What's going on here?
|
||||
|
||||
Notice there is no slot definition in the html portion of the component. Instead, what we do is have _Astro_ render the slot content (here, the 'default' content, but you can also render named slots) into a variable, and then use that content in a _div_ (for instance).
|
||||
@ -109,11 +126,11 @@ So, if the usage is in a markdown file, like so:
|
||||
|
||||
# Using the above component in a .mdx file (that can take components)
|
||||
|
||||
<MyComponent title="This is a slot implementor">
|
||||
### Here is some markdown content
|
||||
- With a bullet item.
|
||||
</MyComponent>
|
||||
{' '}
|
||||
|
||||
<MyComponent title="This is a slot implementor">### Here is some markdown content - With a bullet item.</MyComponent>
|
||||
```
|
||||
|
||||
_MyComponent_ renders the markdown to html and then injects it into the div.
|
||||
|
||||
This actually has a big advantage -- consider that with the normal usage you don't have access to the slot contents: _Astro_ just plops the content into the _<slot/>_ tag. Using this method, however, allows you to access the content and further manipulate it before it gets inserted into the html.
|
||||
@ -139,14 +156,17 @@ You'll note that the index file imports a lot of components, each one roughly an
|
||||
</Fragment>
|
||||
|
||||
<Fragment slot="subtitle">
|
||||
Be very surprised by these huge fake numbers you are seeing on this page. <br class="hidden md:inline" />Don't
|
||||
waste more time! :P
|
||||
Be very surprised by these huge fake numbers you are seeing on this page. <br class="hidden md:inline" />Don't waste
|
||||
more time! :P
|
||||
</Fragment>
|
||||
</CallToAction>
|
||||
```
|
||||
|
||||
Some things to note, here:
|
||||
|
||||
<DListItem dt="The <em>callToAction</em> argument">
|
||||
This argument is actually being passed a javascript object -- not a string. (However, in the TS definition, it could be a string...)
|
||||
This argument is actually being passed a javascript object -- not a string. (However, in the TS definition, it could
|
||||
be a string...)
|
||||
</DListItem>
|
||||
<DListItem dt="There are several <em>Fragment</em> children">
|
||||
Furthermore, these <Fragment/> elements each have a _slot="(value)"_ specifier.
|
||||
@ -159,6 +179,7 @@ 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 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.
|
||||
@ -167,8 +188,8 @@ So, in the example above, the _CallToAction_ component defines the _subtitle_ sl
|
||||
|
||||
```astro
|
||||
<Fragment slot="subtitle">
|
||||
Be very surprised by these huge fake numbers you are seeing on this page. <br class="hidden md:inline" />Don't
|
||||
waste more time! :P
|
||||
Be very surprised by these huge fake numbers you are seeing on this page. <br class="hidden md:inline" />Don't waste
|
||||
more time! :P
|
||||
</Fragment>
|
||||
```
|
||||
|
||||
@ -176,21 +197,21 @@ And, the _CallToAction_ component defines and renders it thusly:
|
||||
|
||||
```astro
|
||||
---
|
||||
...
|
||||
const {
|
||||
subtitle = await Astro.slots.render('subtitle'),
|
||||
} = Astro.props;
|
||||
//...
|
||||
const { subtitle = await Astro.slots.render('subtitle') } = Astro.props;
|
||||
---
|
||||
...
|
||||
{subtitle && <p class="text-xl text-muted dark:text-slate-400" set:html={subtitle} />}
|
||||
...
|
||||
|
||||
//...
|
||||
{subtitle && <p class="text-xl text-muted dark:text-slate-400" set:html={subtitle} />}
|
||||
//...
|
||||
```
|
||||
|
||||
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>
|
||||
@ -198,26 +219,24 @@ Notice first that _subtitle_ is defined as a prop/argument, but it's being proce
|
||||
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
|
||||
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;
|
||||
const { callToAction = await Astro.slots.render('callToAction') } = Astro.props;
|
||||
// also rendered as a slot
|
||||
---
|
||||
|
||||
<div>
|
||||
...
|
||||
{
|
||||
@ -238,12 +257,8 @@ The _CallToAction_ property can be of type `string | CallToAction` where the `Ca
|
||||
}
|
||||
</div>
|
||||
```
|
||||
|
||||
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 as an object and then members of the object are assigned to various
|
||||
html elements.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user