· documentation · 6 min read
AstroWind template in depth
While easy to get started, Astrowind is quite complex internally. This page provides documentation on some of the more intricate parts.
Overview
It can be a somewhat daunting task trying to get a handle on AstroWind internals, and particularly various points of usage.
This page outlines and clarifies some of the techniques found in AstroWind. Use it as a guide for further modification, or an instructional for techniques to use in your own endeavors.
Styling
As the name suggests, AstroWind relies on TailWind for styling. Furthermore, AstroWind defines custom low level style settings which are incorporated into TailWind seamlessly, and which provides consistency for higher level styling constructs, as well as enabling dark mode.
The styling mechanism consists of the following files (all paths are prefixed with /src/
):
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.
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.
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.
Dark Mode
Dark Mode is triggered by the little ‘sunlight’ icon: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:
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:
And in usage elsewhere:
Alternate usage
There’s another way we can use slots, useful particularly when a component can have markdown content is as follows (study carefully…):
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).
So, if the usage is in a markdown file, like so:
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.
This allows a great deal of flexibility in component design.
Yet Another Step
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):
Some things to note, here:
The callToAction argument
This argument is actually being passed a javascript object — not a string. (However, in the TS definition, it could be a string…)
There are several Fragment children
Furthermore, these <Fragment/> elements each have a slot=“(value)” specifier.
The latter seems odd, because <Fragment/> is a built-in component over which you have no control, and doesn’t have a provision for rendering slots, per se.
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 slotname="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:
- Given a component that defines a slot:
- you can reference a slot from a child element of that component and,
- 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”> populates the slot with the following content:
And, the CallToAction component defines and renders it thusly:
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.