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! 


7 Figma plugins to increase your productivity

Is it possible to build a fully functional calendar component under 7 kB without using CSS Flex or `useState`?

Build a Tiny Calendar without Flex or useState

Is it possible to build a fully functional calendar component under 7kB without using CSS Flex or `useState`? Let's explore that possibility using Day.js with CSS Grid, TailwindCSS, React, and TypeScript. Here's what each of these is bringing to the table today:

* **Day.js** — a [tiny and fast 2kB alternative API](https://day.js.org/en/) to parse, manipulate and display dates on the web (`date-fns` is [9.5 times larger](https://bundlephobia.com/package/dayjs@1.11.5)).
* **TailwindCSS** — skip CSS Flex by learning the fundamentals of [CSS Grid](https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Grids) the smart way using [Tailwind's Grid ](https://tailwindcss.com/docs/display#grid)utility classes.
* **React** — extract state logic into reducers by exploring [useReducer](https://beta.reactjs.org/apis/react/useReducer) and skipping additional re-renders using [useCallback](https://beta.reactjs.org/apis/react/useCallback)
* **TypeScript** — work smarter and faster by taking advantage of TypeScript's autocompletion and IntelliSense.

There's a lot of ground to cover, so please go through this guide along with the finished component: [Calendar GH Repo](https://github.com/ekqt/calendar) | [Open 'Calendar' in StackBlitz](https://stackblitz.com/github/ekqt/calendar?file=src/components/Calendar.tsx&title=Calendar%20Component).

## Getting started with Day.js

Regardless of the library of choice (if any), here's what we need: (a) current date, (b) current month, and (c) dates for the entire month. Let's take a look at how Day.js helps us to get started in defining those initial values:

```javascript
// USING THE LIBRARY `dayjs`
// dayjs().toDate()      -> Timestamp of today's date / typeof Date
// dayjs().daysinMonth() -> Days in today's month / typeof number

// REUSABLE UTILITY FUNCTIONS FOR `dayjs`
/** Create a date at the start of the day 00:00. */
function today() {
    return dayjs().startOf("day").toDate();
}

/** Create an array of Dates for a given month */
function createMonth(month = today()) {
    return Array.from(
        { length: dayjs(month).daysInMonth() },
        (n, i) => n = dayjs(month).date(i + 1).toDate()
    );
}
```

These functions will help us clearly define initial values for our calendar with very little code.  Once these values are defined, we are ready to build our first Calendar grid to display each of those dates. The initial values are kept separately for our reducer function to use when we introduce our state logic into our component.

```javascript
const initialValues = {
    selectedDate: today(),
    currentMonth: today(),
};

export default function Calendar() {
    const { selectedDate, currentMonth } = initialValues;
    const currentMonthDates = createMonth(currentMonth);
    return (
        <div>
            {currentMonthDates.map((date) => (
                <div key={date.toString()}>
                    {dat.toString()}
                </div>
            ))}
        </div>
    );
}
```

## Building our Calendar using CSS Grid and TailwindCSS

Using TailwindCSS we can apply and define our Grid property with the utility class `grid grid-cols-7`, then we can map over our array of dates and create a button for each of them for our users to interact with. By applying the CSS property `grid-template-columns: repeat(7, minmax(0, 1fr));` using `grid-cols-7`, we are explicitly defining the columns and allocation of our columns for all the rows of content to follow.

We also have an array named `firstDayOfMonth` that contains more Tailwind utility classes. We used this array to define a given utility class for our first item (set conditionally using `index === 0`) and start the calendar on the correct day of the week (i.e. Monday, Tuesday, etc.).

For any given date (i.e. 1st of October 2022), Day.js can tell us which day of the week that date falls in. For example, the 1st of October 2022 falls on a Saturday, so it's the 7th day of the week (based on a Sunday to Saturday calendar week), calling `dayjs(date).day()` will return 7 accessing the right utility class to display our calendar.

```javascript
export default function Calendar() {
    // ...
    const firstDayOfMonth = [
        "col-start-1",
        "col-start-2",
        "col-start-3",
        "col-start-4",
        "col-start-5",
        "col-start-6",
        "col-start-7",
    ];
    return (
        <div className="grid grid-cols-7">
            {currentMonthDates.map((date, index) => (
                <div
                    className={index === 0 ? firstDayOfMonth[dayjs(date).day()] : ""}
                    key={date.toString()}
                >
                    <button>{dayjs(date).format("D")}</button>
                </div>
            ))}
        </div>
    );
}
```

## Using Reducers to Manage State

Now we need to think about how to further reduce complexity, keeping all of our calendar logic in a single easy-to-access place using **reducers**.

**„Components with many state updates spread across many event handlers can get overwhelming. For these cases, you can consolidate all the state update logic outside your component in a single function, called a _reducer_.“**

Reducers are a great way to cut down on code when many event handlers modify state in a similar or related way (i.e. when updating a month, we also need to update the days of the month). It also helps you cleanly separate your state logic and improve readability to easily understand _what happened_ on each update.

We need to (1) write a **reducer function** (which will process all of our actions), (2) **use the reducer** (function and initial values) in our component, and (3) set **dispatch actions** to update our component.

```javascript
// REDUCER FUNCTION OUTSIDE COMPONENT
/** Manages state for selected date and current month  */
function reducer(state, action) {
    switch (action.type) {
        case "SELECT_DATE": {
            return {
                ...state,
                selectedDate: action.value,
            };
        }
        case "UPDATE_MONTH": {
            return {
                ...state,
                currentMonth: action.value,
            };
        }
    }
}

// USING OUR REDUCER IN COMPONENT
export default function Calendar() {
    const [ state, dispatch ] = useReducer(reducer, initialValues);
    // ...
    return (
        // ...
    );
}

// DISPATCHING AN ACTION WITHIN COMPONENT
/** Performs calculations and dispatches reducer actions to update state */
function handleDispatch(action) {
    const { type, value } = action;
    switch (type) {
        case "SELECT_DATE": {
            dispatch({ type, value });
            // TODO: Return component's value
            // setValue: value;
            break;
        }
        case "UPDATE_MONTH": {
            const updatedMonth = dayjs(currentMonth)
                .add(value, "month")
                .toDate();
            dispatch({ type, value: updatedMonth });
            break;
        }
    }
}
```

## Avoiding Additional Renders

**„When you optimize rending performance, you will sometimes need to cache the functions that you pass to child components.“**

Once our calendar is looking good and behaving the way we want it to, we need to figure out a way for our Calendar to return a Date value for our application. To avoid re-rendering our component, we can use a combination of the `ref` property and React's `useCallback`. 

React uses `ref` as a reserved property on built-in primitives, where it stores DOM nodes once a component is rendered/mounted. However, the `ref`'s type declaration `type Ref<T> = RefCallback<T> | RefObject<T> | null` not only allows  a `ref` object into it, but also a callback function. This allows us to cache a function definition (using both `ref` and `useCallback`) without having to use `useEffect`. Let's implement a callback ref for our calendar component:

```javascript
export default function Calendar({value, setValue}) {
    /** Cached function to update component's state at load */
    const callbackRef = useCallback(() => {
        setValue(selectedDate);
    }, []);
    /** Performs calculations and dispatches reducer actions to update state */
    function handleDispatch(action) {
        const { type, value } = action;
        switch (type) {
            case "SELECT_DATE": {
                dispatch({ type, value });
                setValue(value);
                break;
            }
            // ...
        }
    }
    // ...
    return (
        <div ref={callbackRef}>
            // ...
        </div>
    );
}
```

**„`useCallback` will return a memoized version of the callback that only changes if one of the `inputs` has changed.“**

For a more detailed explanation, Tk's post has a more detailed explanation of this structure: [Avoiding useEffect with Callback refs](https://tkdodo.eu/blog/avoiding-use-effect-with-callback-refs).

## Nice things to add

After setting up our data, styling our calendar, and managing its state, here are a couple of nice things that we added to our component:

* Refactor the component into a "container/presentational" pattern. Use the "container" component to work with the data/state and then pass the data as props to the "presentational" component to display its UI.
* Use an array and map it to create labels for the days of the week: `dayjs().day(index).format("dd")`.
* Add a function to generate dynamic TailwindCSS classes using the native Boolean function: `function classNames(...classes) { return classes.filter(Boolean).join(" ")}`.
* Use focusable elements `<button />` and descriptive labels `aria-label` to make sure your component is accessible.

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/calendar?file=src/components/Calendar.tsx&title=Calendar%20Component)

What is tRPC and how it ensures client-server type safety

tRPC: Understanding Typesafety

Type safety is the extent to which a programming language prevents type errors. The process of verifying and enforcing the constraints of types may occur at compile time or run-time. A programming language like [TypeScript](https://typefully.com/) checks a program for errors before execution (at compile time) as a static type checker. 

In contrast, a library like [Zod](https://zod.dev/) can also provide type checking at run-time. So how does a library like tRPC helps us better understand type safety?

**„tRPC allows you to easily build and consume fully typesafe APIs, without schemas or code generation.“**

At its core, [tRPC](https://trpc.io/) provides the solution to statically type our API endpoints and share those types between our client and server, enabling type safety from end-to-end.

## How does tRPC share types between client/server?

Types are shared based on one or many _procedures_ contained in Routers. A **procedure** is a _composable_ query, mutation, or subscription where you define how your client/server interacts with each other.

Let's see what you'd need to create a query procedure for a [Next.js application](https://trpc.io/docs/v10/nextjs). We'll explore these concepts by reviewing our [tRPC-basic-starter](https://github.com/webscopeio/examples/tree/main/trpc-basic-starter) GH repo. Here's what our file structure initially looks like:

```graphql
# @path: ./src
├── pages
│   └── api/trpc
│       └── [trpc].ts # <-- tRPC HTTP handler
│   └── _app.tsx      # <-- tRPC Provider
│   └── index.tsx
│   └── [...]
├── server
│   └── routers
│       └── _app.ts   # <-- Main app router
│       └── user.ts   # <-- User sub-router
│       └── [...]     # <-- More sub-routers
│   └── trpc.ts       # <-- Procedure helpers
├── utils
│   └── trpc.ts       # <-- Typesafe tRPC hooks
```

You could define all of your procedures within the **tRPC HTTP handler** and completely skip the server directory. However, this wouldn't be a scalable approach. Your backend will likely require several endpoints, for which it is recommended to separate your procedures into different sub-routers and merge them as suggested in the file structure above.

To create a query procedure, at the most basic level we need to define an `input` (optional and validated with your library of choice), and a `query` (the actual implementation of the procedure) which runs a function returning the data you need. In the end, the types of each router are exported to provide a fully-typed experience on the client without importing any server code.

```typescript
// @path: ./src/server/routers/user.ts
import { t } from "../trpc";
import { z } from "zod";

export const userRouter = t.router({
    // Define a procedure (function) that
    // ...takes an input and provides a query
    // ...as `user.greet.useQuery()`
    greet: t.procedure
        // Input validation
        .input(z.object({ name: z.string() }))
        .query(({ input }) => {
            // Here you would process
            // any information you'd need
            // ..to return it to your client
            return { text: `Hello, ${input.name}!` };
        }),
});
```

## Using your new tRPC-backend on the client

[@tRPC/react](https://trpc.io/docs/v10/react-queries) provides a set of hooks wrapped around [@tanstack/react-query](https://tanstack.com/query/v4/docs/guides/queries), so under the hood, they work just the same to fetch data from a server. You'll notice that the conventional _querying keys and functions_ are defined within your procedure.

```tsx
// @path: ./src/pages/index.tsx
import { trpc as t } from "../utils/trpc";

export default function Home() {
    // Wrapped around @tanstack/react-query
    // Can also destructure to access
    // isLoading, isError, isSuccess, error and data
    const result = t.user.greet.useQuery({ name: "Client" });

    if (result.isLoading) {
        return (
            <div>
                <h1>Loading...</h1>
            </div>
        );
    }

    return (
        <div>
            <h1>{result.data?.text}</h1>
        </div>
    );
}
```

...and that's the basic setup. Both the result and input are type-inferred from the procedures as defined and will get **TypeScript autocompletion and IntelliSense** that matches your backend API without requiring any code generation.

## More examples of tRPC usage

Let's create an additional sub-router `@path: ./src/server/routers/post.ts` where we need to provide our client with the following: (a) fetch all posts, (b) fetch post by ID, (c) create a new post. Notice that requirements for `a` and `b` are different than for `c`, as the first two are query procedures and the last one requires a **mutation procedure**. However, you will notice that there is _no difference_ between queries and mutation apart from semantics.

```typescript
import { t } from "../trpc";
import { z } from "zod";

type PostType = {
    userId: number;
    id: number;
    title: string;
    body: string;
};

export const postRouter = t.router({
    // Define a procedure that
    // ...doesn't require an input and provides a query
    // ...as `post.allPosts.useQuery()`
    allPosts: t.procedure.query(async () => {
        const allPosts = await fetch(
            "https://jsonplaceholder.typicode.com/posts"
        ).then((response) => response.json());
        return { posts: posts as Array<PostType> };
    }),
    // Define a procedure that
    // ...takes an id and provides a query
    // ...as `post.postById.useQuery({ id })`
    postById: t.procedure
        .input(z.object({ id: z.string() }))
        .query(async ({ input }) => {
            const post = await fetch(
                `https://jsonplaceholder.typicode.com/posts/${input.id}`
            ).then((response) => response.json());
            return { post: post as PostType };
        }),
});
```

## How can we use procedures?

[Procedures](https://trpc.io/docs/v10/quickstart#add-a-query-procedure) are able to resolve any custom function to process a validated `{ input }`. Just to name a few examples: you could make use of an ORM like [Prisma](https://www.prisma.io/), a Baas like [Supabase](https://supabase.com), or a headless CMS like [Sanity](https://www.sanity.io/) to process your data with the benefits of fully typesafe APIs.

## What about Mutations?

[Mutations](https://tanstack.com/query/v4/docs/guides/mutations) are typically used to create/update/delete data. Let's take a look at how we could create a mutation procedure using our Post sub-router:

```typescript
import { t } from "../trpc";
import { z } from "zod";

type PostType = {
    userId: number;
    id: number;
    title: string;
    body: string;
};

export const postRouter = t.router({
    // Define a procedure that
    // ...takes an id and executes a mutation
    // ...as `post.createPost.useMutation()`
    // ...from `*.mutate({ input })`
    createPost: t.procedure
        .input(
            z.object({
                title: z.string().min(1),
                body: z.string().min(1),
                userId: z.number(),
            })
        )
        .mutation(async ({ input }) => {
            const post = await fetch(
                "https://jsonplaceholder.typicode.com/posts",
                { method: "POST", body: JSON.stringify(input) }
            ).then((response) => response.json());
            return { response: post as PostType };
        }),
});
```

Here is how we could execute the mutation from the client:

```tsx
import { FormEvent, ChangeEvent, useState } from "react";
import { trpc as t } from "../../utils/trpc";

export default function NewPost() {
    // User is fixed for simplicity
    const initValue = { title: "", body: "", userId: 1 };
    const [form, setForm] = useState(initValue);
    const mutation = t.post.createPost.useMutation();

    function handleChange(
        e: ChangeEvent<HTMLInputElement | HTMLTextAreaElement>
    ) {
        setForm({ ...form, [e.target.id]: e.target.value });
    }

    function handleSubmit(e: FormEvent<HTMLFormElement>) {
        e.preventDefault();
        mutation.mutate(form);
        setForm(initValue);
    }

    return (
        <form onSubmit={handleSubmit}>
            <label htmlFor="title">Title</label>
            <input
                type="text"
                id="title"
                name="title"
                value={form.title}
                onChange={handleChange}
            />
            <label htmlFor="body">Body</label>
            <textarea
                id="body"
                name="body"
                value={form.body}
                onChange={handleChange}
            />
            <button type="submit">Submit</button>
        </form>
    );
}
```

> Mutations are as simple to do as queries, they're actually the same underneath, but are just exposed differently as syntactic sugar and produce an HTTP POST rather than a GET request.

## So WIFY by using tRPC?

What's in it for you using tRPC? We barely scratched the surface, here is a list of features:

-   Full static type-safety with auto-completion on the client, inputs, outputs, and errors.
-   No code generation, run-time bloat, or build pipeline.
-   Zero dependencies and a tiny client-side footprint.
-   All requests can be batched automatically into one.
-   Framework agnostic and compatible with all JavaScript frameworks and runtimes.

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/webscopeio/examples/tree/main/trpc-basic-starter?file=src/pages/index.tsx&file=src/server/routers/user.ts&view=editor)

UX study by our product team at Webscope.io, taking on traveling during global pandemic.

UX Case study: Traveling during COVID-19

At the peak of the pandemic when it became clear that we are not going to get rid of it anytime soon, public institutions became burdened by the task of providing daily information about new rules, restrictions, and guidelines for how to cope with it.  

As it usually goes for the public sector, the idea might be well appreciated but the execution often trails behind. Most of the time we have gotten used to it however, with the pandemic affecting our everyday lives it became more and more vexing. 

## Starting point

When European Union 🇪🇺 came up with the idea to unify all the information across the member states we were really thrilled with it. With the *#strongertogether* hashtag they unveil their new portal. Have a look below 👇

![img](https://images.prismic.io/webscopeio/746d00d1-e752-427f-89ce-051f4c51b560_mapa.png?auto=compress,format)With a strong message and a lot of useful information - this had great potential. But after seeing the final result we have decided to put it through our standard design process starting with UX research 🔎.

## UX Research and more

The tool informs about the current coronavirus situation in European countries in one place and keeps the data up-to-date. However, we discovered that users had trouble finding what they were looking for. We realized that the website includes too much information which, in most cases, is not clear.  

In our UX research, we also saw people using the **Travel** ✈️ section the most. They had found this to be the number one reason why they would visit the platform. That is why we decided to focus solely on this use case and to adjust the information presented in this way. 



![img](https://images.prismic.io/webscopeio/afb143bb-b56a-4e59-834c-8fc31e1bdc2b_chart.png?auto=compress,format)



Once we decided on the general use case we had to better understand our target audience, in order to identify what exactly they need from the product. We focused on their goals and observed behavioral  patterns. Based on these we have defined **user personas** to cover their needs. 🙋

We have noticed that users were missing **some functions** in the current platform like **watchdog** 🐶 to be reminded about the actual status of the restrictions, ability to search for routes based on different means of transport or find specific restrictions based on the type of traveler. 





![img](https://images.prismic.io/webscopeio/a45bee4e-d0d7-4baa-a85b-06797520f10c_type.png?auto=compress,format)





After collecting all of this information we have created preliminary **wireframes** to be tested and edited before applying the final design. Once we had this confirmed we were ready to publish our results.

## Solution

Based on all the information we gathered in our UX research we have created a **simple travel app** where you could search for your destination in the EU and find out all the restrictions that apply along the way.✈️ 🌍



![img](https://images.prismic.io/webscopeio/76a73fcf-13c4-4ccc-93e4-2f7a0b736fbd_solution.png?auto=compress,format)





When you are visiting a particular country you want to **know the route - not just the destination.** In this way the user journey follows the most common behavior and saves time spent searching for the information.

For better understanding your route at first glance we decided to implement a simple color palette. We follow the 3 categories already created and used by re-open the EU platform and applied them to our use case.  





![img](https://images.prismic.io/webscopeio/94d5a48f-a60e-4bb7-8875-c7d4b2d7059b_palette.png?auto=compress,format)



We also included most of the features to further complete the user journey. To make sure user has always up to date information we introduced a **watchdog** 🐶 that you ca set-up as in-browser notifications 🔔 ​or via email. 📧 



![img](https://images.prismic.io/webscopeio/9cc0ad9f-d636-4305-a6e1-79e23dcf55aa_watchdog.png?auto=compress,format)



We have tested our concept with users and they loved it. ♥️

Everything is much more clearer comparing to the current platform. From finding your route to getting notified about restrictions, it is faster and much smoother. 

If you want to know more about the process or want to give us feedback check out out [case study on Behance](https://bit.ly/covid-travel-made-simple)

## Implications and outcome

After we have completed and **shared** our version we got really positive feedback within our community. Therefore we have decided to **contact EU representatives** and present them our ideas since as they have put it we are *#strongertogether*.

We have sent them an email with our solution explaining the reasoning and the whole process behind it. After some time after sending the email, we have noticed that the https://reopen.europa.eu/ portal introduced a **new functionality - Travel plan.** 

Here is a little sample of the theor implementation.👇



![img](https://images.prismic.io/webscopeio/fdb24b90-5788-4082-b680-0405bd56dea7_reopen_road.png?auto=compress,format) 



When we forget about UI :smirk: and focus solely on the functional of the feature it accomplished the basic idea we had set out to do. So good job EU for listening to **our feedback!** 🎉

Once the **Travel Plan** has been published we even got a **response email** from the team behind Re-open Europe. They piqued our interest by explaining a few behind-the-scenes obstacles that they have to deal with while building this feature. 


> “Due to the high number of variables, individual situations and fragmentation of rules, it is nearly impossible to offer concise sentences describing the restrictions in place” 



When we hear that something can't be done, we see it as an opportunity for creativity, therefore we agreed to **schedule a call with the EU team** 🇪🇺 to get to the bottom of this and make the portal better for all of us. 

UX Case study: Travel during Covid-19

# Setting up OAuth

In our previous post, we have created a slack command, which needs to be initiated by a user writing `/<name-of-the-command>`.
In the next articles, we will learn how your app can post a message to Slack directly as a reaction to some event.
In our example, we will send a notification about new project report once user reports it. 

For doing this, we need a [Slack Webhook](https://api.slack.com/messaging/webhooks) URL where we will send blocks to be displayed. You can either take them
from Slack Dev UI, but that doesn't really help if you want to distribute your app to users. We will need to generate them programmatically and that is exactly 
where OAuth flow will help us.

In this tutorial we will skip the part where you can manually generate a webhook and send data to it. It's pretty easy and it doesn't really help with a production app.
If you still want to go through this, follow [this tutorial](https://api.slack.com/messaging/webhooks#incoming_webhooks_programmatic).

## What is OAuth

Describing OAuth is out of scope of this article. [This Digial Ocean's tutorial] is probably the one that explains it in the best way.
In their article, they have the following image:

![OAuth Flow](https://assets.digitalocean.com/articles/oauth/abstract_flow.png)

_Source: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2_


## Configuring Your App

In our case, Application is our Slack application and Slack API is the Service API.

1. Go to your _Application Settings_, and define your Redirect URL. This is where Authorization Server (Slack) will send you an Access Token.

![Slack Commmand](https://images.prismic.io/webscopeio/4f97e1f1-0d49-4904-8733-5c72e41cbe11_defining-redirect-url.png?auto=compress,format)

2. In your _Application Settings_ > _Manage Distribution_ you'll find a different ways how your users can install your app.

We'll choose `Embeddable Slack Button` and put it on our homepage. Have a look at [this commit](https://github.com/webscopeio/slack-tutorial/commit/1937e4c74431e0d9176a2a5f2986a093eef9ac43) to see how to do this if you're not experienced with Django.

The important part is to add a new entry to your `urls.py`, create a view that renders HTML and add a Slack button.
Optionally, you can define your `base.html` so that you can re-use the basic styles in other templates e.g. redirect address url that Slack will follow after installing our application.

Right now, we see the following screen at our index.

![Home Page](https://images.prismic.io/webscopeio/4d1535d0-92aa-4657-9304-db2954daa106_homepage+Django+Slack+Tutorial.png?auto=compress,format)

After your users click the button, they'll be redirected to Slack _(Authorization Server)_ (Step 3.) 

![Slack Installation Process](https://images.prismic.io/webscopeio/739e88a3-189c-4162-a64a-3fdfe29a35d2_slack-install-process.png?auto=compress,format)

And Slack will redirect them to your application (Step 4.) with an *Access Token*.

![Non Existing Redirect URL](https://images.prismic.io/webscopeio/6022dd84-aa63-487e-b372-a00172cf6d71_non-existing-redirect-url.png?auto=compress,format)

😮 Our redirect URL doesn't exist, we need it to store an access token. We will use it to talk to Slack later on.

## Setting up Redirect URL

When Slack redirects to our URL. We will have the following data in `request.GET`.

![Non Existing Redirect URL](https://images.prismic.io/webscopeio/f8829f9d-2b6e-4723-af29-b7b459296ae0_oauth-response.png?auto=compress,format)

We will need these data to interact with Slack later on. Let's build models that will persist this information in a database.

Blog

Shipping Zero JavaScript with Astro

7 Figma plugins to increase your productivity

Build a Tiny Calendar without Flex or useState

tRPC: Understanding Typesafety

UX Case study: Travel during Covid-19

Slack Tutorial Part 5 - Incoming Webhooks

Let’s stay connected