How can we build from scratch buttons and links that are easy to use, typesafe and modular that just make sense?

Understanding Buttons and Links from Zero

How can we build from scratch buttons and links that are easy to use, typesafe and modular that just make sense? Welcome to a new series on basic React Components that are built with TypeScript and TailwindCSS from the ground up. All of these will be OSS and free to use.

**Disclaimer**: If you aren't onboard using React, TypeScript or TailwindCSS. Please note this series includes all of them.

**TL;DR**: at the end of the article you can find examples of how to use both of them by themselves or to create Navigation and Footer components.

Here's what we're building:

!["Examples"](https://raw.githubusercontent.com/ekqt/nulacss/main/public/examples/buttons-links.gif)

## Buttons vs Links

Maybe a hot take: let's treat our buttons and links differently, no? Let's keep things simple, a button shouldn't be a link and vice-versa.

> **Buttons** start an action. The text on the button *should* tell what will happen when the user clicks on it. A **Link** is a reference to a resource. This can either be external (e.g. a different website) or internal (e.g. a specific element or page in the current website).

If you need to execute an action: use a button. If you need to navigate to a resource: use a link. What experience you want the user to have entirely depends on you.

## What to consider - Buttons and Links

Here are some decisions you need to take when making either of these:

* Typography and color: family, size, text/background color
    
* Borders and spacing: radius, width, color, padding
    
* Responsive design
    
* Handling hover, focus, and other states
    
* Dark mode styles
    

Here are some *personal* considerations when designing a button:

* Name, role and keyboard-focusable should all be accessible (use the right HTML elements)
    
* The contrast between text and background should pass accessibility checks with both light and dark modes (you can check this with the inspection tool from your Devtools)
    
* Choose borders to define the look and type of your element (Tertiary buttons sometimes only have bottom borders. Inline, external, and navigation links should look different)
    
* The padding ratio should be at least a 3 to 1 (horizontal to vertical) or bigger for buttons and for links it should be at least 2 to 1.
    
* At smaller viewports the buttons should take full length, the links should remain at its length and they should both be stacked (very personal opinion)
    
* Hover, active, focus, and disabled states are a must and should be significantly different from each other (use the Force element state pane from your DevTools to design accordingly)
    
* The dark mode should alter all the color-related properties (background, color, borders, states)
    

Test these elements by clicking on each of them, using the keyboard's Tab key to toggle focus between them, change the viewport's size and enable dark mode all to see how these iterations work.

Here's a Button element [TailwindPlayground](https://play.tailwindcss.com/mZvLRs7jbW):

!["Examples"](https://raw.githubusercontent.com/ekqt/nulacss/main/public/examples/buttons-links-2.png)

Here's a Links Anchor element [TailwindPlayground](https://play.tailwindcss.com/AcdgwApY1O):

!["Examples"](https://raw.githubusercontent.com/ekqt/nulacss/main/public/examples/buttons-links-3.png)

## Creating a Button Component

A button component will allow you to use all of the design decisions made until now, integrate variants for different button types and also quickly consume the component around your code. Let's take a look at the decisions you need to make:

* What props definitions do you need to create vs which ones can you reuse (more is less here, the more you can inherit from the button element, the better)
    
* How will you allow your custom props (let's call these variants) to interact with each other (will you need discriminated unions or will your props overlap with each other by design)
    
* What variants will you define as default (the fewer props you need to declare when using your custom component, the better)
    

Our goal here is to create a button component that can handle the following markup with typesafety:

```tsx
import Button from '@/components/Button';

/* All buttons should be able to use the button attributes */
export default function Buttons() {
  return (
    <>
      /* When variant isn't define the button should default to primary */
      <Button icon>Submit</Button>
      /* Only primary buttons can have an icon */
      <Button variant="secondary">Save</Button>
      <Button variant="tertiary">Cancel</Button>
    </>
  );
}
```

Here you need to decide what is it that you need. It's all up to you, but for now let's create three variants ("primary", "secondary", and "tertiary") and an icon prop (that defaults to an arrow on the right side of the button) that can only be used when the variant is primary.

```tsx
/* Most component won't need to obtain a ref for its inner element  */
type ButtonProps = React.ComponentPropsWithoutRef<'button'> &
  /* 1. A discriminated union with a never type will signal
       when should the icon prop be used.
       2. Partials constructs all of its properties as optional.
    */
  Partial<
    | {
        variant: 'primary',
        icon: boolean,
      }
    | {
        variant: 'secondary' | 'tertiary',
        icon: never,
      }
  >;

export default function Button({
  variant = "primary",
  icon,
  ...props
}: ButtonProps){
  return (
    <button
      {...props}
      className={`
        ...defaultStyles
        ${variant === "primary" ? "..." : ""}
        ${variant === "secondary" ? "..." : ""}
        ${variant === "tertiary" ? "..." : ""}
      `}
    >
      {props.children}
      {variant === "primary" && icon && (
        <svg aria-hidden>{...}</svg>
      )}
    </button>
  )
}
```

If you need to reference the full example visit: [Button Component](https://github.com/ekqt/nulacss/blob/main/src/components/UI/Button.tsx)

## Creating a Link Component

All starting considerations from the button component apply here too. Our goal here is to create a link component (will call anchor component to avoid name conflicts with framework components) that can handle the following markup with typesafety:

```tsx
import Anchor from '@/components/Anchor';

/* All links should be able to use the anchor attributes */
export default function Links() {
  return (
    <>
      /* Only primary Anchors can have an icon */
      <Anchor variant="external" href="#" target="_blank" rel="noreferrer">
        External
      </Anchor>
      <Anchor variant="nav" href="#">
        Navigation
      </Anchor>
    </>
  );
}
```

Here we'll create two variants ("external", "nav") and and add an icon conditionally without a prop and depending on which variant is used.

```tsx
type AnchorProps = React.ComponentPropsWithoutRef<"a"> & {
  variant?: "external" | "nav";
};

/* No need to worry about all of the additional props */
export default function Anchor({ variant, ...props }: AnchorProps) {
  return (
    <a
      {...props}
      className={`
        ...defaultStyles
        ${variant === "external" ? "..." : ""}
        ${variant === "nav" ? "..." : ""}
      `}
    >
      {props.children}
      {variant && (
        <svg 
          aria-hidden 
          className={`${variant === "external" ? "..." : "..."}`} 
        >{...}
        </svg>
      )}
    </a>
  )
}
```

If you need to reference the full example visit: [Anchor Component](https://github.com/ekqt/nulacss/blob/main/src/components/UI/Anchor.tsx)

Here's an example project for you to take a look on more implementation details: [NulaCSS](https://github.com/ekqt/nulacss). Visit the Components folder to see how these elements can be created using React, TypeScript and TailwindCSS.

Thanks for reading, until next time!

How Suspense made "UI Loading state" a first class declarative concept in the React programming model.

Understanding Suspense with Next 13

Before even talking about Suspense we need to know that the most important addition in React 18 is concurrency. In computer science, **Concurrency** is the ability to deal with lots of things at once, which is not the same as doing lots of things at once (as parallelism is).

> *How* React has achieved concurrency has been completely abstracted from us, as React wants us to focus on *what* we want the user experience to look like, whereas they'll handle *how* to deliver that experience.

When it comes to UX, Concurrency is such a big deal because it's the driving mechanism that enables our applications to have multiple versions of its UI at any time without blocking the *main thread*, all whilst enabling fast, consistent and reliable experiences for our users.

## Where does Suspense fit in all this?

If you're new to the React ecosystem, you might be asking yourself: **What's Suspense?** Suspense lets you declaratively specify the loading state for a part of the component tree if it's not yet ready to be displayed.

Suspense isn't new in the React ecosystem. However, now in React 18, Suspense has support for server-rendering and brings all of React's new concurrent features. This also is a huge win for DX, because as developers, we are no longer forced between doing something early, or doing something late, we just literally need to start using Suspense.

> Concurrency in React 18 is unlocked by Suspense, making "UI Loading state" a first-class declarative concept in the React programming model.

### How does it work?

Conceptually, you can think of Suspense as being similar to a `catch` block. However, instead of catching errors, it catches components "suspending". Any component in the tree can "suspend", which means that it's not ready to render.

**Only Suspense-enabled data sources will activate Suspense**, such as:

* Lazy-loading component code using `lazy()` (*pre-React 18*) 
* Data fetching with Suspense-enabled frameworks like Relay, Next.js, Remix
    

Luckily for us, the code looks exactly the same:

```typescript
<div>
    <Card />
    <Suspense fallback={<PhotoSkeleton />}>
        // The Photo component will suspend 
        // and React will show PhotoSkeleton until ready
        <Photo /> 
    </Suspense>
</div>
<div>
    <Suspense fallback={<ContentSkeleton />}>
        <Content />
    </Suspense>
</div>
```

## What are the biggest perks of using Suspense in React 18?

* **Streaming HTML** lets you start emitting HTML as early as you’d like, streaming HTML for additional content together with the `<script>` tags that put them in the right places.
* **Selective Hydration** lets you start hydrating your app as early as possible before the rest of the HTML and the JavaScript code are fully downloaded. It also prioritizes hydrating the parts the user is interacting with, creating an illusion of instant hydration.
    

## How to use Suspense in Next 13?

Thanks to Next 13 [new file-system based router](https://beta.nextjs.org/docs/routing/fundamentals) and [special file conventions](https://beta.nextjs.org/docs/routing/fundamentals#special-files) using Suspense becomes a breeze. Their framework abstracts boundaries altogether (this also includes Error boundaries) by letting us focus even more on what we want the user experience to look like, while they handle the rest.

Next 13 achieves this abstraction using their file-based router. Let's imagine a directory structure where we are building a route called `/loading` (we probably should've used a better name but as you all know, naming is hard):

```graphql
# @path: ./app/examples
├── loading            # <-- Route segment
│   └──loading.tsx    # <-- Loading UI
│   └──page.tsx       # <-- Page content for `/examples/loading` route
```

As you can already tell, each folder in a route represents a route segment as long as it has a `page.tsx` file (so `./app/examples/loading` directory structure would translate to the path `/examples/loading`).

In Next 13, `loading.tsx` files *automatically wrap* a page or child layout in a React Suspense boundary without having to declare it manually, providing an instant loading state on the first load and when navigating between sibling routes.

The directory structure above would translate into the following component hierarchy:

```typescript
// @path: ./app/examples/loading
<Layout>
    <Suspense fallback={<LoadingSkeleton />}>
        <Page />
    </Suspense>
</Layout>
```

By using these special file conventions, you can structure your Suspense boundaries with ease:

```typescript
// @path: ./loading/loading.tsx
export default function Loading() {
    // You can add any UI inside Loading, including a Skeleton.
    return <LoadingSkeleton />;
}

// @path: ./loading/Page.tsx
export default function Page() {
    return <PageContent />;
}
```

## Main takeaways

Next 13 help us create meaningful Loading UI with **React Suspense**. Here is what you need to know:

* The special file `loading.tsx` (by default server components) enables us to show instant loading states from the server for an entire route segment while its content loads.
* You can mix and match your app's architecture using manually-defined `<Suspense />` boundaries for more granular loading UI.
* Navigation is interruptible, shared layouts remain interactive while nested layouts or pages load.
    

Feel free to explore this example using the resources below:

[GitHub Repository: Suspense-demo](https://github.com/ekqt/suspense-demo)

We designed a mobile app concept for cafe Cafeco that allows users to order products in advance and skip the waiting line.

UX Case study: Order products from the cafe in advance | Webscope.io

## Introduction
Cafeco is a local cafe located in a suburban area. They are offering a variety of products and trying to target younger/middle-aged and busy people, who don‘t have time to prepare products on their own. 

Based on the user research we find out that people mainly face the same problem - the amount of time spent waiting in line for a product to order and collect. So, we have decided to conduct UX research to come up with a solution of allowing users to order products in advance and skip the waiting line.

![The problem and goal](https://images.prismic.io/webscopeio/1ba7b1d5-07c7-4ac9-876b-f76031b40aa1_cafeco_1.png?auto=compress,format)

## Summary of user research
Conducting the research and creating empathy maps were things that helped us understand users' needs. The main issue for users was lack of time and the fact, that they do not want to wait in line for products.

It was not all about lacking the time and need for a faster process. These people are really enjoying their coffees and the products that are offered by Cafeco are meeting their exact needs, but often frustration stopped a lot of people from enjoying them.

&nbsp;
## Pain points

![Pain points](https://images.prismic.io/webscopeio/d2ece9cd-4bcd-4a33-a370-530b020e2022_cafeco_2.png?auto=compress,format)
&nbsp;
## Persona Amy

![Persona](https://images.prismic.io/webscopeio/5d653943-0136-4066-a819-5cc0e66215e5_cafeco_3.png?auto=compress,format)

### About Amy
**“If I don’t start my day with a cup of nice coffee, I will be unbearable.”**

Amy is a 40-year-old single mother living in Brno, Czechia. She has a 7-year-old daughter. She is working as an accountant in the international corporate. She has really stressful job and does not have much free time.

### Goals
- To enjoy a nice cup of coffee on a regular basis
- To visit the coffee house as often as possible
- To have more free time

### Frustrations
- Not enough time
- Afraid of not getting high-quality coffee

### Problem statement
Amy is a busy accountant who needs to get a cup of coffee as fast as possible because she does not have much free time.

&nbsp;
## User journey map
Mapping Amy‘s user journey revealed how helpful would it be for users to use Cafeco app for mobile ordering.
![User journey map](https://images.prismic.io/webscopeio/57b94607-0e1a-4aa9-a2c1-5684ae239017_cafeco_4.png?auto=compress,format)
&nbsp;
## Wireframes and usability study
We have created wireframes and conducted user testing to ensure we found the perfect solution for the users. During the user testing, critical things were discovered that helped to general user flow. These discoveries were then incorporated into the designs.
![Wireframes and usability study](https://images.prismic.io/webscopeio/9defe63d-7011-4596-9208-cb74e7dfdb68_cafeco_5.png?auto=compress,format)
## Final design
After finalizing wireframes we dived into making the app's user interface design. We chose neutral colors of violet, supported by brown colors on coffee thumbnails to represent the taste and smell of coffee. 
![Final design](https://images.prismic.io/webscopeio/a331b388-d326-4b9b-bedc-9ed04e2d7201_cafeco_6.png?auto=compress,format)

## Thanks for watching!
Webscope builds software solutions tailored to your needs
We have rock-solid experience with the entire software development process.

See more work on our Dribbble: https://dribbble.com/webscope-design

UX Case study: Order products from the cafe in advance

Let's explore the limitations of React's Client Component and how the new React@18/Next.js@13 Server Components architecture helps us deal with these shortcomings.

So, why Server Components?

Is it possible to ship ZERO JavaScript and still deliver a functional website?

Shipping Zero JavaScript with Astro

Astro is an **all-in-one web framework** designed for building **content-focused** websites. With this approach in mind, it delivers an incredible developer experience to build server-first, intuitive to use, flexible and fully-featured websites. Anyone who knows a little bit of HTML and CSS all the way up to seasoned developers can leverage Astro's _opt-in complexity_ framework to build for the web.

### Astro's biggest perks

Let's see what are the basics that Astro brings to the table, **Astro is...**

-   ...**easy to use** and by design less complex than any other UI framework or language (any valid HTML is a valid Astro component, see [Why Astro - Easy to Use](https://docs.astro.build/en/concepts/why-astro/#easy-to-use)),
-   ...**fast by default** shipping ZERO Javascript out of the box, it takes an MPA approach loading on average 90% less JavaScript (see [MPAs vs SPAs](https://docs.astro.build/en/concepts/mpa-vs-spa/)),
-   ...**incredibly featured, flexible and UI-agnostic** supporting several frameworks (supporting React, Preact, Svelte, Vue and more), an easier JSX, scoped CSS, file-based routing, data-fetching, and a lot more (see [Integrations](https://astro.build/integrations/)).

We've built a sample project called [Astro for Docs](https://astrofordocs.vercel.app/) (see source code: [GH: Astro for Docs](https://github.com/ekqt/astrofordocs)) to showcase how straight-forward and flexible it is to use Astro for Beginners.

### What's in the menu for today?

After playing around with this project, it turns out you CAN REALLY build a content-focused website with ZERO JavaScript using Astro. Based on what we've learned, here's what we'd like to show you:

1. Writing in "Astro" as a language to write [Astro Components](https://docs.astro.build/en/core-concepts/astro-components/)
2. Use Markdown files as pages with Astro's [MDX](https://docs.astro.build/en/guides/integrations-guide/mdx/) and [TailwindCSS](https://docs.astro.build/en/guides/integrations-guide/tailwind/) integrations.
3. Design [nested layouts](https://docs.astro.build/en/core-concepts/layouts/) for better developer experience.
4. Leverage Astro's [Runtime APIs](https://docs.astro.build/en/reference/api-reference/) to build components.

We ran `npm create astro@latest` with TypeScript and a blank, empty project.

## Astro as a language

### Will I have to learn a new programming language?

TLDR; no. If you know HTML, you already know enough to write an Astro component. At its core, its syntax is a superset of HTML. Capable of anything any other UI framework component can do, they are designed to feel familiar to anyone with HTML and JSX experience without any unnecessary complexity.

All Astro components are incredibly lean and have access to fetch remote data at build time, taking advantage of top-level await inside their **component's script** to render data in its **component's template**.

```javascript
/*** @file MyComponent.astro */
---
// Component Script (JavaScript)
---

```

### Astro components are dynamic but NOT reactive

Unless you use Astro in *SSG mode*, Astro components are templates that only run once, at build time. Therefore, their values are dynamic (NOT reactive) and will never change. Let's check out some of the great features Astro brings to the table as opposed to conventional components:

```javascript
---
// Template with multiple elements
const DynamicTag = 'div'; // Dynamic Tags
const items = ['2020', '2021', /*...*/]; // Fragments
const visible = true; // Conditionally display
---
<DynamicTag>Hello!</DynamicTag> // renders as <div>Hello!</div>

<p>
  Astro supports multiple root elements in a template. Bye `<>`!
  However, when using an expression to dynamically create
  multiple children there is no need to declare a `key` but
  you should wrap these inside a fragment as usual.
</p>

<ul>
  {items.map(item => (
    <>
      <li>Halloween {item}</li>
      <li>Thanksgiving {item}</li>
    </>
  ))}
</ul>

<p>Astro supports either `<Fragment/>` or its shorthand `<></>`.</p>

{visible && <p>I'm alive!</p>} // This WILL show
```

However, writing content in HTML can be a monumental task out of itself. Which brings us to the question: *How does Astro integrate local or remote content using Markdown or MDX?*

## Integrations Setup

### What to know about integrations?

[Astro Integrations](https://docs.astro.build/en/guides/integrations-guide/) can change the function and look of your projects with a single line of code. Astro has several official integrations to choose from. Broadly speaking, integrations can help you:

-   ...bring your UI framework of choice (React, Svelte, Vue, etc.),
-   ...change Astro into SSR mode, fetching all data at request time,
-   ...transform and model content easier (with MDX and TailwindCSS among others).

Getting started with integrations is incredibly easy. For official integrations, the `astro add` CLI automates installations for you. Installing with NPM you run `npx astro add mdx` and `npx astro add tailwind` to get your project bootstrapped with both. Detailed instructions on how to install and/or troubleshoot can be found in: [Using Integrations](https://docs.astro.build/en/guides/integrations-guide/).

### What happens under the hood?

The `astro add` CLI, installs the NPM packages and applies the integrations into your `astro.config.*` file. Additionally, for TailwindCSS it creates its own `tailwind.config.cjs` file with the necessary file extensions for HTML, MD, MDX and all supported UI frameworks.

### Nice combo to have

When working with Markdown files (locally or remotely) and TailwindCSS, we'd also recommend installing the following dev dependencies:

-   [@tailwindcss/typography](https://tailwindcss.com/docs/typography-plugin) official plugin gives you default styles for your HTML that work straight out of the box (see [installation](https://tailwindcss.com/docs/typography-plugin#installation)).
-   [Automatic class sorting with Prettier](https://tailwindcss.com/docs/editor-setup#automatic-class-sorting-with-prettier) with `prettier` and `prettier-plugin-tailwindcss` just makes sense to keep your utility classes in order (see [installation](https://github.com/tailwindlabs/prettier-plugin-tailwindcss#installation)).

## Using MDX files

### How to get started?

Once the integration is installed, it is as easy as adding `.mdx` files within your `src/pages/` directory to get started. Let's swap our project's `index.astro` for an `index.mdx` to test this out. Regardless if you're building with Astro or not, please note these two files are not one-to-one. A standalone `*.mdx` file does require an HTML boilerplate to give our browser the full information about our project. So let's see how Astro helps us with this.

We can interact with our `*.mdx` files from the perspective of two parts: (1) _Frontmatter_, a composable YAML-based section to declare your document's meta data and (2) the body composed of _MDX-syntax_ content.

```md
---
layout: ../layouts/Page.astro
title: Index
# <- These key-value pairs will be accessible via
# <- the `frontmatter` property from any `.astro` file
---

# Hello world



```

Anything written in inside the frontmatter fence (`---`) is accessible via the `frontmatter` property. So you can expect `title` in addition to the Astro provided key-value pairs to result in a payload like this (except for `layout`):

```js
{
  title: 'Index',
  file: '/../../../../../src/pages/index.mdx',
  url: '',
  astro: {}
}
```

### Where does TailwindCSS come in?

Let's get back to that `layout` property we declared in our frontmatter. Think of [Layouts](https://docs.astro.build/en/core-concepts/layouts/) as reusable page shells where you'd inject content using the `<slot /`> element. They are useful for all of your HTML boilerplate and common UI elements (such as headers, navbars, footers and more). Layout components are commonly placed in a `src/layouts` directory in your project. So let's add a `Page.astro` layout file to see how that looks:

```jsx
---

const { frontmatter: title } = Astro.props;
---
<html lang="en">
  <head>
    <title>{title}</title>
  </head>
  <body>
    <article>
      <h1>{title}</h1>
      <slot /> 
    </article>
  </body>
</html>
```

Here is where you have HTML markup available to style your Astro project using TailwindCSS. In Astro, you are able to use the standard `kebab-case` format for all HTML attributes instead of the `camelCase` used in JSX. It even works for `class`, which is not supported by React.

## Using TailwindCSS

### All your styles in a single line

The official Tailwind CSS Typography plugin provides a set of prose classes you can use to add style defaults to any vanilla HTML you don’t control, like HTML rendered from Markdown, or pulled from a CMS with a single line of code. If we'd go back and add a couple of classes to our `src/layouts/Page.astro` layout file it would be enough to apply these styling defaults.

```jsx
---
const { frontmatter: title } = Astro.props;
---
<html lang="en">
  <head>
    <title>{title}</title>
  </head>
  <body>
    <main class="min-h-screen max-w-6xl mx-auto">
      <article class="prose lg:prose-xl">
        <h1>{title}</h1>
          <slot />
        </div>
      </article>
    </main>
  </body>
</html>
```

#### Styling individual HTML elements

There are plenty of [element modifiers](https://tailwindcss.com/docs/typography-plugin#element-modifiers) that you can use to add utility classes to style individual elements. Additionally, we'd recommend adding: `dark:prose-invert`, which triggers hand-designed dark mode versions for every default color theme.

### How to use CSS in Astro

Styling an Astro component is as easy as adding a `<style>` tag in any `*.astro` file, where they are automatically **scoped by default**. You can also opt-out of scoping by adding the `is:global` attribute. If you aren't using TailwindCSS, advance styling languages like [Sass](https://sass-lang.com/) and [Less](https://lesscss.org/) are also supported. 

Say we want to change the look of an HTML element, even if we aren't authoring traditional CSS for our `<a>` and `<pre>` elements, could do something like this :

```jsx
<style>
    .prose * > a {
        @apply no-underline border-b-2 pb-1 hover:pb-2 transition-all;
    }
    .prose pre {
        @apply p-5 drop-shadow-2xl;
    }
</style>
```

**Don't abuse `@apply` just for the sake of making things look "cleaner"**. As Tailwind recommends: If you’re going to use `@apply`, use it for very small, highly reusable things like buttons and form controls — and even then only if you’re not using a framework like React where a component would be a better choice.

## Nested Layouts

### Let's talk basics

Layout components are conventionally used to provide a page shell for a given `<slot />` of content. Incredibly useful to manage components, `<html>`, `<head>`, and `<body>` tags and other layouts too. However, Layouts don't need to contain an entire page of HTML. We are able to break down layouts into smaller layouts and then reuse them to create even more flexible pages.

Let's see how could we extract some boilerplate for our `src/layouts/Page.astro` layout by refactoring our code:

```jsx
---
import Base from './Base.astro'
const {frontmatter: title} = Astro.props;
---
<Base title={title}>
  <article class="prose lg:prose-xl">
    <h1>{title}</h1>
      <slot />
    </div>
  </article>
</Base>
```

### Understanding nested layouts

So what's happening here? We are extracting all the HTML boilerplate `<html>`, `<head>`, `<body>`, and `<main>` tags to a Base layout. This new layout can take any props as needed. Here, we are passing the page's title for it to be rendered in our HTML's `<head>` tag. 

Our Base layout will function the same way as our Page layout did before, now with the added benefit that it can be reutilized for other none-MDX pages. Here's how our Base layout looks like:

```jsx
---
type Props = {
    title: string;
};

const { title } = Astro.props;
---
<html lang="en">
  <head>
    <title>{title}</title>
  </head>
  <body>
    <main class="min-h-screen max-w-6xl mx-auto">
      <slot />
    </main>
  </body>
</html>
```

#### Component Props

Props in layouts work as they do in any Astro component. On the example above, notice we are defining our props with TypeScript with the `Props` type interface. This is incredibly helpful to destructure our props from `Astro.props` and ensure typesafety throughout our project.

## Typesafety in Layouts

### Why Typesafety?

Typesafety is the extent to which a programming language prevents type errors. Naturally, when structuring an application with different layouts, components and pages, at the most fundamental level, it is useful to ensure that we are consuming the right types at all times.

Astro ships with built-in support for TypesScript out of the box. Within any of our `*.astro` files, we can author TypeScript code to prevent errors at runtime by defining the shapes of objects and components in our code. Let's talk about a couple of the recommended practices when using TypeScript for your Astro project.

#### Type Imports

In order to avoid duplication and maintain structure at scale, we recommend extracting all of your types into a separate `*.ts` file. Whenever importing any of these types, Astro recommends using explicit type imports and exports whenever possible. Use `import type { SomeType } from './types` instead of a traditional import. This avoids any edge-cases where Astro's bundler may incorrectly treat your imported types as if they were JavaScript.

### Typesafety by example

We can add typesafety to our `/*.astro` files for our frontmatter's object by adding a `category` property in addition to our `title` and declaring its type by using the `MDXLayoutProps` helper:

```jsx
---
import Base from './Base.astro'
import type { MDXLayoutProps } from "astro";

type Props = MDXLayoutProps<{
    // Define any frontmatter property here
    title: string;
    category: string;
}>;

const {
    frontmatter: { title, category },
} = Astro.props;
// Now your properties are typesafe in your script/template!
---
<Base title={title} category={category}>
  <article class="prose lg:prose-xl">
    <h1>{title}</h1>
      <slot />
    </div>
  </article>
</Base>
```

## Astro's Runtime APIs

### Working with Astro's toolbox

Astro's Runtime APIs is what really brings all of its power together. For example, we have been using `Astro.props` all along to read all the attributes passed as component props. You can browse their documentation to learn more about their APIs, see [API Reference](https://docs.astro.build/en/reference/api-reference/).

For now, let's introduce more of their APIs to build a _Table of contents_ and a _Side navigatation_ component.

### Building a Table of contents

`Astro.props` is an object containing any values that have been passed as attributes. In addition to its `frontmatter` object, a **Markdown layout** will have access to the default props, such as `url` and `headings` among others (see [Markdown Layout Props](https://docs.astro.build/en/guides/markdown-content/#markdown-layout-props)). 

Excluding the `frontmatter` object, which we have already talked about, let's log the entire `Astro.props` to understand how easy Astro makes this information available to use:

```js
{
  file: '.../src/pages/docs/runtime-apis.mdx',
  url: '/docs/runtime-apis',
  content: {
    title: "Astro's Runtime APIs",
    category: 'Runtime APIs',
    file: '.../src/pages/docs/runtime-apis.mdx',
    url: '/docs/runtime-apis',
    astro: {}
  },
  frontmatter: {...},
  headings: [
    {
      depth: 1,
      slug: 'working-with-astros-toolbox',
      text: 'Working with Astro’s toolbox'
    },
  ],
  'server:root': true
}
```

We can destructure the properties we need to access their values and work with them in a separate Astro component like this:

```jsx
/** LAYOUT: /src/layouts/Page.astro */
---
import TOC from "../component/TOC.astro";
const { headings } = Astro.props;
---

<TOC headings={headings} />

/** COMPONENT: /src/components/TOC.astro */
---
import type { HeadingsType } from "../lib/types";
type Props = HeadingsType;

const { headings } = Astro.props;
---

<ul>
    {headings.map(({ slug, text }) => (
        <li><a href={`#${slug}`}>{text}</a></li>
    ))}
</ul>

```

### Building a Side Navigation

For a side navigation, we do need to read all the files within a given folder in our project. In order to do that, Astro also offers another API for this purpose. `Astro.glob()` is the easiest way to load multiple files into your static site setup. It only takes a single parameter: a relative URL glob of which files you'd like to import.

Each of our `/*.mdx` pages has a title and a category. We'd like to group each page by category and display them in a component for navigation. Let's take a look how we build a Side navigation component using `Astro.blog()`:

```jsx
import type { MDXInstance } from "astro";
import type { DocsType } from "../lib/types";

const pages = (await Astro.glob("../pages/docs/*.mdx")) as Array<
    MDXInstance<DocsType>
>;

const sortedPages = pages.sort((a, b) =>
    a.frontmatter.category.localeCompare(b.frontmatter.category, "en", {
        sensitivity: "base",
    })
);

const categories = [
    ...new Set(pages.map((p) => p.frontmatter.category)),
];
```

Once we have this information gathered, we can dynamically create a component mapping over our categories and creating children if they belong within that given category.

A huge thing to note is that `Astro.glob()` is a wrapper of Vite's `import.meta.glob()` API, and it's only available in `/*.astro` files. In case you need access to your files in other file extension types, you can always use Vite's API (see [Vite's Glob Import](https://vitejs.dev/guide/features.html#glob-import)).

That's all there is to it, if you'd like to see the source code in more detail, feel free to check out: [GH: Astro for Docs](https://github.com/ekqt/astrofordocs).

## Conclusion

-   Astro does deliver a great DX regardless of your level of experience, as building Astro components only really requires HTML and CSS.
-   Astro is UI-agnostic, meaning you can **BYOF** it and bring your own framework. They have official support for React, Preact, Solid, Svelte, Vue, and Lit. You can even mix and match different frameworks.
-   Astro shines with statically generated content. Even if there is no [SSR or ISR like Next.js](https://nextjs.org/docs/basic-features/data-fetching/overview), Astro is considering per-page support for SSR in their [2022 Q4 roadmap](https://github.com/withastro/rfcs/discussions/302).
-   Astro can ship ZERO JS (you'd be surprised how many things can be achieved with only HTML and CSS). Regardless if you need to introduce [Astro Islands](https://docs.astro.build/en/concepts/islands/) and UI frameworks, it loads [40% faster with 90% less JavaScript](https://twitter.com/t3dotgg/status/1437195415439360003) in comparison to modern frameworks.

Feel free to explore this example using the resources below:

[![Open in StackBlitz](https://developer.stackblitz.com/img/open_in_stackblitz.svg)](https://stackblitz.com/github/ekqt/astrofordocs?file=src/pages/index.mdx&title=Astro)

We’re big fans of Figma design tool and therefore we decided to list out our favorite plugins which help us increase our productivity. Learn more about them!

7 Figma plugins to increase your productivity | Webscope.io

Do you use Figma for your web&mobile designs? We love this tool so we decided to share with you 7 plugins we are using daily to **boost our productivity**. Keep reading! 

## Stark
This plugin integrates all accessibility tools to ensure your **designs are accessible** and meet legal requirements and standards. Its main functions are **contrast checker** and **colorblind simulation**.

Learn more about [Stark here](https://www.figma.com/community/plugin/732603254453395948/Stark). 
![Figma Plugin recommended by Webscope.io – Stark](https://images.prismic.io/webscopeio/05e454e4-883d-4bf1-a83d-aa4385f69fc6_1.png?auto=compress,format)

## Chart 
With this plugin, you can easily create the most popular **charts using random data**, tabular data (Google Sheets, Excel, Numbers, and CSV files are supported), or JSON data. Built-in edit feature allows you to change chart type or style.

Read more about this [plugin here](https://www.figma.com/community/plugin/734590934750866002/Chart). 
![Figma Plugin recommended by Webscope.io – Chart](https://images.prismic.io/webscopeio/2602d71b-e877-402f-81b0-2deac9cdabb1_2.png?auto=compress,format)

## Rename It
This plugin allows you to **batch rename layers and frames**. Rename current layer name, sequentially rename layers or replace any word(s) or character(s) from selected layers. Keep your design files organized.

Learn more about [Rename It here](https://www.figma.com/community/plugin/731271836271143349/Rename-It).
![Figma Plugin recommended by Webscope.io – Rename It](https://images.prismic.io/webscopeio/3729f17a-7e8b-47af-af96-0f81d0eeb132_3.png?auto=compress,format)

## Similayer
Using this plugin you can select **similar layers** based on a whole range of properties. It’s perfect when you want to change all layers with a specific Text Style to a new one or just select all “cards” with the same corner radius.

Find out more about [Similayer here](https://www.figma.com/community/plugin/735733267883397781/Similayer). 
![Figma Plugin recommended by Webscope.io – Similayer](https://images.prismic.io/webscopeio/d108ca12-0348-49d6-950d-6a9d618ee6c3_4.png?auto=compress,format)

## Remove BG
Do you need to **remove the background** of the image? There is no easier way how to do it than using this plugin which allows you to do it automatically with just a single click. It works perfectly!

Learn more about [Remove BG here](https://www.figma.com/community/plugin/738992712906748191/Remove-BG). 
![Figma Plugin recommended by Webscope.io – Remove BG](https://images.prismic.io/webscopeio/b40fe865-db23-403c-a0b7-71cd010f72bd_5.png?auto=compress,format)

## Iconify
This plugin contains literally **tons of icons**, (the well-known packs are included) which you can easily import into your designs. With the build-in edit feature, you can also change icon color, size, and rotation.

Find out more about [Iconify plugin here](https://www.figma.com/community/plugin/735098390272716381/Iconify).
![Figma Plugin recommended by Webscope.io – Iconify](https://images.prismic.io/webscopeio/bb02695d-9ea1-4a8c-8be5-9c82da70746a_6.png?auto=compress,format)

## Content Reel
Do you struggle with the content of your designs? This plugin offers **a palette of text strings, images, avatars, icons, and many more**. Just find what you need and make your content look more real.

Read more about [Content Reel plugin here](https://www.figma.com/community/plugin/731627216655469013/Content-Reel). 
![Figma Plugin recommended by Webscope.io – Content Reel](https://images.prismic.io/webscopeio/d8ad6245-eac6-4a7c-8188-dbce91cd8dfa_7.png?auto=compress,format)

We hope these plugins will help you increase your productivity like in our case. Do you have your favorite ones? Let us know, we’re all ears! 


Blog

Understanding Buttons and Links from Zero

Understanding Suspense with Next 13

UX Case study: Order products from the cafe in advance

So, why Server Components?

Shipping Zero JavaScript with Astro

7 Figma plugins to increase your productivity

Let’s stay connected