Elijah Lewis | Writing

AI Will Change UI Development

Tue, 30 Apr 2024 00:00:00 GMT

Hello reader,

I want to make a prediction, or rather define a possibility: UI development will change. Dramatically.

New Hardware & The App-less Ecosystem

When Humane AI delivered its eagerly anticipated and heavily publicized launch, it presented many distinctive features — most were met with criticism. But, the most intriguing aspect to me was the lack of apps. The founders argued that because of AI, you don't need apps. Initially, I found this perplexing—wouldn't it be a very limiting experience without apps? What if developers outside the company wanted to build something for the device? How would they deliver it without an app platform? A few months later, Rabbit echoed similar sentiments at CES 2024 with its R1 device. Much of the criticism it faced was summed up by a common refrain: "Why is this not just an app on my phone?" This raises an even more interesting question: why are so many AI companies venturing into new hardware?

The answer: access to richer inputs. An AI that can tap into your location, the surrounding noises, voices, visuals, and more can offer significantly better guidance. While your phone contains many of these sensors, it often lacks real-time environmental context — the ambience factor — as it usually remains in your pocket, requiring manual operation of its camera and microphone. This has spurred the development of wearable computers — be it necklaces, glasses, or even pins — designed to capture information seamlessly and effortlessly without user initiation.

The ability to capture a categorically larger variety of inputs (audio, vision, etc.) not only enhances an AI's capabilities but also allows it to display information in a more contextually specific way. Imagine you've been wearing a Humane AI pin for a few months while on a new diet and gym regimen. This device, having recorded all your meals and workouts, could let you ask for a display of your recent exercise data or even generate a graph showing your progress. What if you start struggling with motivation and need a gym buddy? Maybe the AI could generate profiles of others nearby for you to select a potential gym buddy.

This UI would not be hard-coded but dynamic, generated and rendered based on user queries — generative UI. Consider how many traditional apps could be replaced if an AI had access to more data and could dynamically generate UIs. Hence, the app-less economy.

Services vs UI-Centric Apps

There's an important distinction I'd like to draw concerning apps: there are those where the UI merely serves as a vehicle to deliver a service, and then there are those where the UI itself is the main attraction. Consider Spotify. We primarily use the app to listen to music of course, which is the service Spotify provides. Here, the UI is designed to facilitate access to this music, featuring functionalities like search, playlists, and recommendations. Now in contrast, take Instagram. The platform is highly visual; we use the app to view photos and videos, and interact with them through likes and comments. Here, the UI doesn't just support the service — it is the service, as the visual and interactive elements are central to the user experience.

As we've discussed, AI could dynamically generate UI. It's conceivable that an AI could interface with Spotify's APIs to dynamically generate a user-specific UI. Imagine you're in a mall, and you hear a song you like playing in a store. You could ask your AI assistant to identify the song using a Shazam-like feature, add it to your library, and even generate a UI on your phone to show all your library songs while you're on the subway home.

Consider dating apps like Hinge or Tinder, where the service provided is the opportunity to meet people and the UI is just a vehicle. Imagine an AI that knows your music tastes, dietary habits, health information, favorite shows, and hobbies. You tell your AI assistant you're interested in dating, and it finds compatible individuals in your area, checks for mutual time availability, and even sends out a generated profile to those you're interested in.

For companies like Spotify and Tinder/Hinge, the shift towards AI integration would likely mean focusing less on front-end development and more on enhancing their back-end capabilities to support such AI interactions. What about Instagram? To adapt, apps that currently emphasize UI as the core of their experience would likely need to restructure themselves to become more service-oriented.

What becomes of frontend

Generative UI is already available in some fashion with Vercel's v0 and PureCode AI having the ability for users to describe a piece of UI they'd like and AI can generate code. With this emerging technology, one might wonder if frontend development will become obsolete, particularly in companies like Spotify or Tinder that focus more on backend processes. However, replacing human workers with AI in this area would be a grave mistake.

While AI can generate code, it often lacks innate creativity and may merely regurgitate existing human designs rather than produce genuine innovations. The evolving role of AI should transform, not replace, frontend development practices. AI might produce generic interfaces on its own, but these limitations can be addressed with the creative input of frontend developers.

Developers could focus on creating a UI library for their apps—designing versatile, reusable components that AI systems can dynamically deploy by stitching components together. This "Lego piece development" approach allows developers to assemble UI elements, guided by AI's efficiency but enhanced by human creativity and insight.

UI could be transmitted alongside backend API calls, a concept not new in web development. Frameworks like Rails and Laravel already facilitate the sending of HTML partials from the server to the client. React Server Components introduce a similar paradigm, but with a focus on modern, interactive web applications. This architecture allows for UI components to be dynamically adjusted in real-time. By integrating machine learning frameworks directly on the web server, the system can adapt the UI based on ongoing analysis of user data and interactions.

Frontend development might increasingly focus on the infrastructure that enables AI agents to generate UIs for end users. An example of this today is explorer.globe.engineer, a platform allowing users to query information and receive a dynamically generated, wiki-like UI. While its UI structure is consistent, with only the content changing, we can envision an AI capable of manipulating more elements to tailor the user experience further.

Frontend developers might need to specialize in UX design principles, understand user behavior, and master interactive design to create templates that AI can dynamically populate. Skills in data visualization could become increasingly important, as presenting information in an instantly comprehensible and engaging way is crucial.

Backend developers might shift their focus toward developing sophisticated APIs that handle data transactions and include rich metadata providing contextual descriptions of the data. For example, a music streaming service's API might describe the mood, tempo, and suitable activities (like workout or relaxation) for each track, enabling AI to create intuitive situational playlists. This extends to app-to-app communication, such as how Tinder displays a user's Spotify listening activity or Instagram posts. As AI begins to generate UIs, developers must ensure their APIs and data are well-documented contextually, allowing AI to appropriately integrate and display information from different apps.

Conclusion

The landscape of UI development is poised for profound transformation, though that's common in the frontend world as expectations from users only grow. But the advent of AI-driven interfaces promises not only a shift from traditional apps to more dynamic, context-aware systems but also redefines the roles of frontend and backend developers. I'm personally looking forward to ways we can leverage richer inputs and more personalized interactions, leading to an app-less economy where the boundary between service and interface blurs. Of course, only time will tell whether this possibility becomes a reality.

Coding as Gardening — A Journey into SaaS Productivity

Tue, 12 Dec 2023 00:00:00 GMT

I've always been inclined towards finding the best productivity tools that fit my workflows while also spending countless hours watching productivity gurus on YouTube like Thomas Frank, Ali Abdaal, etc. to learn what the best workflows even are. Somedays, I even consider going back to bullet journaling when I miss the creative tactile pleasure of pen to paper. Of course, there are a lot of benefits you miss out on going analog over digital. But, with time I couldn't resonate with the ideas of these productivity YouTubers and didn't love my productivity tools. So, I decided I could build my own digital task manager.

Planting the Seeds: Building Modal

Wanting to build my own task manager also came at a time of wanting to build my own startup. So, I thought, why not make this my first SaaS startup? Enter Modal, a SaaS productivity app designed to follow the Priority Matrix method while incorporating features from other beloved task apps like Things and Notion.

Inspired by Herman's words in My Product is my Garden, Modal — my newly named task manager app — would be my garden. I would tend to it routinely with care, nurturing it with precision, waiting to bear witness to the fruits it could produce.

Tending to Modal was a chore. Initially, embracing the indie hacker spirit, I envisioned a swift release within a month. However, transitioning from a structured software engineering background at a large tech company, where tasks are distributed among specialized teams, posed a steep learning curve when building a product entirely on my own. Despite this, four months later, I launched a private beta. The reception was less than stellar; feedback at best was lukewarm. I decided I could do a re-write, make it sleeker, and feature-rich.

I poured nearly a year into Modal before launching it on Product Hunt. The satisfaction of seeing it featured on Product Hunt was a moment of pride. The joy, however, was short-lived as the hopeful surge in sales never came to materialize. I found myself at a crossroads, grappling with technical barriers and dwindling motivation in the absence of monetary validation.

Tending to a Wilted Garden

Post-Product Hunt, I continued to toil on Modal, but the struggle became increasingly daunting. The realization hit hard—it wasn't working. The garden I envisioned, filled with thriving users, seemed more like a desolate field. Faced with this harsh truth, I made a difficult decision—I listed Modal's assets for acquisition and closed up shop.

The decision to part ways with Modal wasn't easy. It was my creation, my digital haven, but the reality was that its roots weren't nourished by the commercial soil I planted it in. To clarify, I am not saying Modal shouldn't be a product for others, but its essence resonated more personally with me than it did as a commercial entity.

A New Seed: Open Sourcing the Future

I came across Linus' compelling blog post on why you should build your own productivity tools. The author asserts that we shouldn't cater our workflows to tools that exist when we can instead code the tools that cater to our specific workflows. In a way, this was what I was doing with Modal — I had a very specific way of doing things, so I built an app around that. But, I tried selling it as a commercial farm rather than tending to it as my personal garden.

I think I'd like to make Modal open source. I'll build it for myself catered to my workflows, but others can use use it or copy it as they like. I can see a future in which, like Linus, I'll build more of my own tools and replace the services that I currently settle for. It would feel like a light touch of the gilded age of tech, where coders were mere tinkerers, learning from the code of others, directly copying it and modifying (a time before the young Bill Gates would issue copyright triggering the creation of copyleft).

While there are many problems worth solving that could make a person a pretty penny, I've recognized a distinction that some of those solutions are best kept...as a garden.

My Self-Study Roadmap for AI

Thu, 02 Nov 2023 00:00:00 GMT

Check it out

https://itsroze.notion.site/My-Self-Study-Roadmap-for-AI-187a2e42872c4a34b8f714ef71c85dc7?pvs=4

Learning AI

Back in college, I spent time studying machine learning. I've admittedly forgotten quite a lot and then I need to learn a lot more. Based on the recommendations of friends, other people's guides, and my own searches I decided to compile the resources into a Notion page. This contains a lot of resources I think are important and that I want to study but by no means complete or perfect. It remains a work in progress. But, feel free to duplicate it and make it your own

Use Astro and Solid to Build a Portfolio

Sun, 17 Sep 2023 00:00:00 GMT

Why Switch

I'd previously used NextJS to host my portfolio but the problem was that I was sending a lot of Javascript to the users' web browser. This is because React (which NextJS uses) needs to be loaded onto the browser for "reactivity." But for a portfolio, I didn't need all that much interactivity so sending the React library to the client is heavy.

That's where Astro comes into play. It lets me serve my website statically resulting in faster load times and smaller bundles. If I need interactivity, I can sprinkle that in where needed (whether it be React, Svelte, Vue, Solid, etc.).

Okay but why Solid instead of React?

I've used React for years, time to learn something new
Solid is fast. SolidJS doesn't use a virtual DOM like React does where it goes node by node to see what's changed between the DOM. SolidJS instead plugs itself directly into the parts of the DOM that can be "reactive." It's a substantially faster and simpler way to add reactivity to a website or app.

What's in this Guide

This isn't quite a full "follow along" type tutorial. I'm going to give you the gist to understand at a high level and if you want to see my source code, you can check it out here

The Tech Stack

Astro for the main framework
SolidJS to sprinkle some reactive components as needed
TailwindCSS because it lets us quickly style our website with easy to remember utility classes
Vercel to deploy

Let's Get Started

Installation

Create a new Astro project

pnpm create astro@latest

Add TailwindCSS

pnpm astro add tailwind

Add SolidJS

pnpm astro add solid

If you're wondering why pnpm, it's because its a whole heck faster.

Now run your project

pnpm dev

Pages

Creating pages in Astro is simple. Within the pages directory you can create a new route e.g. about.astro which would yield portfolio.com/about.

Since I also want to have a blog, I can create markdown files in the pages directory. Particularly subdirectories will yield nested routes e.g. portfolio.com/blog/post-1 if I create a file pages/blog/post-1.md.

Layouts

Pages in my portfolio have a general layout and Astro allows you to create layouts that you can wrap your content within.

---
import "@styles/global.css";
import Head from "@components/Head.astro";
import { Navigation } from "@components/navigation/navigation.tsx";

interface Props {
  title: string;
  ...
}

const { title, ... } = Astro.props;
---

<!doctype html>
<html lang="en">
  <Head
    title={title}
    description={description}
    type={type}
    image={image}
    date={date}
  />
  <body class={background}>
    <Navigation
      client:load
      textColor={navColor}
      underlineColor={navUnderline}
      pathname={Astro.url.pathname}
    />
    <main><slot /></main>
  </body>
</html>

This layout file has two components Head and Navigation defined elsewhere that we'll talk about later.

The slot element is where my page content will go (a sort of placeholder).

I can use this layout as such:


---
import Layout from "../layouts/Layout.astro";
---

<Layout
  title="ROZE | ABOUT"
  ...
>
  <header>
      <h1>
        Hello. I am a Washington D.C. based software engineer 🧑🏽‍💻.
      </h1>
  </header>
</Layout>

Components

In the above example, you saw that I used some components. You can use Astro syntax to make components or you can also make them in another framework like Solid. Components can take in props like we're used to and are reusable.

Since the navbar would be on each page, I had it as a component within my Layout file.

I know I want a list of my projects on my portfolio so I can make this a component.

I can create src/components/projects.tsx to make a solid component.

Let's store some example projects

import modalImg from "../images/projects/modal.png";
import giftableImg from "../images/projects/giftable.png";

const projects = [
  {
    title: "Modal",
    description:
      "My first SaaS app. I never found a great productivity manager, so I built an opinionated one. Modal was designed with simplicity for the everyday user",
    year: "2023-Present",
    url: "https://usemodal.com/",
    image: modalImg,
    tags: ["React", "NextJS", "Tailwind CSS", "React Native", "AWS", "SQL"],
  },
  {
    title: "Giftable",
    description:
      "I created Giftable so that I could remember gift ideas for friends and family, as well as myself :) I thought building a social network would be a great learning experience to up my code skills too",
    year: "2022-2023",
    url: "https://giftableapp.com/",
    image: giftableImg,
    tags: ["React", "NextJS", "Tailwind CSS", "SQL"],
  },
];

You'll notice here that I'm importing images within my src folder. This is because Astro can bundle and optimize them versus if stored in the public/ directory.

Now I can display these projects in a Solid component which has similar syntax to React but with a few differences

export const ProjectList: Component = () => {
  return (
    <div class="w-full xl:h-[30rem] h-[25rem] overflow-y-scroll custom-scroll">
      <For each={projects}>
        {(project) => (
          <FadeIn>
            <div class="xl:p-10 px-10 py-4 flex flex-col lg:flex-row items-center h-full justify-between">
              <div class="flex flex-col items-center lg:w-1/2 w-full">
                <h2 class="lg:text-6xl text-4xl font-light py-2 text-center">
                  <a href={project.url} target="_blank" class="hover:underline">
                    {project.title}
                  </a>
                </h2>
                <div class="w-4/5 pb-10">
                  <img
                    src={project.image.src}
                    class="w-full h-auto shadow-xl shadow-gray-800 rounded-lg"
                  />
                </div>
              </div>
              <div class="flex flex-col lg:w-1/2 w-full lg:gap-10 gap-4">
                <p class="lg:text-4xl lg:text-left text-center text-2xl font-extralight ">
                  {project.description}
                </p>
                <div class="text-center lg:text-left">
                  <For each={project.tags}>
                    {(tag) => (
                      <span class="bg-yellow-200 w-fit px-2 py-0.5 rounded leading-4 mr-1 mb-1 inline-flex font-medium">
                        {tag}
                      </span>
                    )}
                  </For>
                </div>
                <p class="lg:text-3xl lg:text-left text-center text-2xl font-medium">
                  {project.year}
                </p>
              </div>
            </div>
          </FadeIn>
        )}
      </For>
    </div>
  );
};

A few things about this code

We're using TailwindCSS to style our elements
These are actually HTML elements unlike React so you'll see we're using class instead of className
The For component allows us to render a list and is already keyed which is why we're not using the key attribute like you would in React if you were mapping an array

Here's the code for the FadeIn component that I'm using

interface IFadeIn {
  children: JSX.Element | JSX.Element[];
}

const FadeIn: Component<IFadeIn> = (props) => {
  const [visible, setVisible] = createSignal(false);
  let domRef: HTMLDivElement | undefined;

  createEffect(() => {
    const observer = new IntersectionObserver((entries) => {
      entries.forEach((entry) => setVisible(entry.isIntersecting));
    });
    observer.observe(domRef as Element);
  });

  return (
    <div
      ref={domRef}
      class={`fade-in-section ${visible() ? "is-visible" : ""}`}
    >
      {props.children}
    </div>
  );
};

The main thing to note here is createSignal. This is effectively like useState. But remember how I said SolidJS plugs itself into the actual DOM whereas React uses a virtual DOM? Because of that, visible isn't a static variable like in React. It's a getter method, meaning we have to call it as visible().

Another thing to note, createEffect is like useEffect but we don't need to supply it a dependency array like in React because Solid is smart enough to detect the signals being used.

Finally, I can use my Solid component in my Astro page, pages/projects.astro:

---
import Layout from "../layouts/Layout.astro";
import "@styles/projects.css";
import { ProjectList } from "@components/projects";
---
<Layout
  title="ROZE | PROJECTS"
  ...
>
  <header>
    <h1>
      Featured Projects
    </h1>
  </header>
  <section>
    <ProjectList client:load />
  </section>
</Layout>

By default, Astro won't send the component's javascript to the client, so we have to specify the directive client:load to tell Astro to do so! What's awesome about this is I could essentially use Solid (or another UI framework) instead of a mix of Astro and Solid and Astro will only send the HTML by default.

Blog Posts

So now how do I generate 1) a page to display all my blogs posts and 2) a page to show the content of a single post?

On pages/blog.astro for example we can write Javascript within the --- snippet to retrieve all our markdown files.

---
import Layout from "@layouts/Layout.astro";
import BlogCard from "@components/BlogCard.astro";
export interface Frontmatter {
  title: string;
  excerpt: string;
  coverImage: string;
  ogImage: string;
  date: string;
}
const allPosts = await Astro.glob<Frontmatter>("./*.md");
//sort by date
allPosts.sort((a, b) => {
  const dateA = new Date(a.frontmatter.date);
  const dateB = new Date(b.frontmatter.date);
  return dateB.getTime() - dateA.getTime();
});
---
<Layout
  title="ROZE | WRITING"
  ...
>
  <header>
    <h1>Blog</h1>
  </header>
  <section>
    <ul>
      {
        allPosts.map((post) => (
          <li>
            <BlogCard
              url={post.url ?? "/404"}
              frontmatter={post.frontmatter}
              rawContent={post.rawContent()}
            />
          </li>
        ))
      }
    </ul>
  </section>
</Layout>

Astro.glob will import many files at once (in this case all our markdown files within the current folder). We use Typescript to define what the frontmatter will look like, e.g.

---
layout: "../../layouts/MarkdownLayout.astro"
title: What is a Tech Cooperative - A Short Introduction
excerpt: Learn what a tech cooperative is, how it works, and why it's the next big thing in tech.
coverImage: /images/blog/cover-what-is-a-tech-cooperative.png
ogImage: /images/blog/cover-what-is-a-tech-cooperative.png
date: "2023-04-18"
---

> The most tragic form of loss isn’t the loss of security; it’s the loss of the capacity to imagine that things could be different.
>
> &mdash; <cite>Ernest Bloch, The Principle of Hope</cite>

# What's a Cooperative?

...

Here the frontmatter matches the typescript interface we defined, but what about MarkdownLayout. I created another layout file to define the layout of a blog post. BlogCard is a component I created to render a url to each blog post with some information about that post.

In the MarkdownLayout we can pull in the props passeed and slot in our blog post

---
import type { Frontmatter } from "@/pages/writing/index.astro";
import Layout from "./Layout.astro";
import readingTime from "reading-time";
interface Props {
  frontmatter: Frontmatter;
  rawContent: () => string;
}
const { frontmatter, rawContent } = Astro.props;
const { title, excerpt, ogImage, date } = frontmatter;
---
<Layout
  title={title}
  ...
>
  <header class="px-1">
    <h1>{title}</h1>
    <div class="flex items-center gap-2 md:text-lg font-normal text-zinc-500">
      <div
        class="flex grow flex-col sm:flex-row sm:items-center sm:justify-between mt-4"
      >
        <div>
          <span>Roze</span> /{" "}
          <time>
            {
              new Date(date).toLocaleDateString("en-us", {
                year: "numeric",
                month: "short",
                day: "numeric",
              })
            }
          </time>
        </div>
        <div class="flex items-center gap-1">
          <span>{readingTime(rawContent()).text}</span>
        </div>
      </div>
    </div>
  </header>
  <article class="prose max-w-screen-xl md:prose-xl px-1 lg:px-0 lg:mt-8">
    <slot />
  </article>
</Layout>

My Review

Overall, it was really fast to learn Astro especially if you've used other frameworks like NextJS before. Astro's documentation is well written and I even recommend their tutorial.

The developer experience was great, I had a fun time building and very little issues.

But what about performance? So it would be unfair to directly compare my revamped portfolio to my old one because I changed quite a bit. But a few general things to note

Network requests are down by almost 4x. In my NextJS website, I would have close to 40 requests on some pages. Astro will send 10
Loading times were all mostly down, with some down by close to 100ms.
Network resources substantially lowered (over a MB with NextJS, versus a few kB with Astro)

Also, adding <ViewTransition /> that Astro offers added a smooth app like feeling with just that one line!

What about the bad? I have to test this more, but some images (even using Astro's image optimization) loads slow. This could be an issue with Vercel though. More investigation is needed.

Rebuilding my Portfolio with Next, MDX, and Contentlayer

Mon, 21 Mar 2022 00:00:00 GMT

Why I Stopped Using Ghost

I liked the idea of opening up my iPad, sipping on a caramel latte in an overly-hipster Brooklyn cafe, writing a new tech post. Ghost CMS was my way to do that (see my setup). It was, however, expensive ever since Heroku broke up with us and I moved onto Digital Ocean which is $6 month. But also, sometimes Ghost would crash and I didn't want to spend too long debugging when redeploying quickly fixed whatever was broken.

Ultimately, crashes and money didn't warrant a ridiculous aesthetic of writing in a cafe because I never actually did it. Caramel lattes are also expensive.

And I can also use Obsidian, my markdown notetaker, and then just copy that to my blog, achieving all of this for free.

Technologies

Next JS -- my favorite full stack framework
Tailwind CSS -- because I don't know how to do CSS otherwise
MDX -- to use React within my markdown (probably won't use much JSX, but hey why not at least have it)
Contentlayer -- transform the mdx posts into type-safe json data
Vercel -- deployment

Getting Started

I've started using the T3 CLI to make my apps these days because the stack generally is one I enjoy and I love the cohesion together.

npm create t3-app@latest

Only select Tailwind, we don't need the other packages

After installation, we can clear up the homepage

import { type NextPage } from "next";
import Head from "next/head";
const Home: NextPage = () => {
  return (
    <>
      <Head>
        <title>Create T3 App</title>
        <meta name="description" content="Generated by create-t3-app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <main className="flex min-h-screen flex-col items-center bg-gradient-to-b from-[#2e026d] to-[#15162c] pt-20">
        <h1 className="text-7xl font-bold text-white">My Cool Blog</h1>
      </main>
    </>
  );
};

export default Home;

Configuring MDX

To be able to write .mdx files, we'll need a few plugins

@next/mdx -- to use with Next
@mdx-js/loader -- required package of @next/mdx
@mdx-js/react -- required package of @next/mdx
gray-matter -- to ignore frontmatter from rendering
rehype-autolink-headings -- allows to add links to headings with ids on there already
rehype-slug -- allows to add links to headings for documents that don't already have ids
rehype-pretty-code -- makes code pretty with syntax highlighting, line numbers, etc
remark-frontmatter -- plugin to support frontmatter
shiki -- coding themes we can use for rendering code snippets

yarn add @next/mdx @mdx-js/loader @mdx-js/react gray-matter rehype-autolink-headings rehype-slug rehype-pretty-code remark-frontmatter shiki

Setting Up Contentlayer

Contentlayer makes it super easy to grab our mdx blog posts in a type-safe way.

First install it and its associated Next js plugin

yarn add contentlayer next-contentlayer

Modify your next.config.mjs

// next.config.mjs

import { withContentlayer } from "next-contentlayer";

/** @type {import('next').NextConfig} */
const nextConfig = {
  // Configure pageExtensions to include md and mdx
  pageExtensions: ["ts", "tsx", "js", "jsx", "md", "mdx"],
  reactStrictMode: true,
  swcMinify: true,
};

// Merge MDX config with Next.js config
export default withContentlayer(nextConfig);

Modify your tsconfig.json

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "contentlayer/generated": ["./.contentlayer/generated"]
    }
  },
  "include": ["next-env.d.ts", "**/*.tsx", "**/*.ts", ".contentlayer/generated"]
}

Create a file contentlayer.config.ts and we will do three things

Define the schema of our Post and where the content lives
Setup our remark and rehype plugins

import { defineDocumentType, makeSource } from "contentlayer/source-files";
import rehypeAutolinkHeadings from "rehype-autolink-headings";
import rehypePrettyCode from "rehype-pretty-code";
import rehypeSlug from "rehype-slug";
import remarkFrontmatter from "remark-frontmatter";

export const Post = defineDocumentType(() => ({
  name: "Post",
  filePathPattern: `**/*.mdx`,
  contentType: "mdx",
  fields: {
    title: {
      type: "string",
      description: "The title of the post",
      required: true,
    },
    excerpt: {
      type: "string",
      description: "The excerpt of the post",
      required: true,
    },
    date: {
      type: "string",
      description: "The date of the post",
      required: true,
    },
    coverImage: {
      type: "string",
      description: "The cover image of the post",
      required: false,
    },
    ogImage: {
      type: "string",
      description: "The og cover image of the post",
      required: false,
    },
  },
  computedFields: {
    url: {
      type: "string",
      resolve: (post) => `/blog/${post._raw.flattenedPath}`,
    },
    slug: {
      type: "string",
      resolve: (post) => post._raw.flattenedPath,
    },
  },
}));

const prettyCodeOptions = {
  theme: "material-theme-palenight",

  onVisitLine(node: { children: string | unknown[] }) {
    if (node.children.length === 0) {
      node.children = [{ type: "text", value: " " }];
    }
  },

  onVisitHighlightedLine(node: { properties: { className: string[] } }) {
    node.properties.className.push("highlighted");
  },

  onVisitHighlightedWord(node: { properties: { className: string[] } }) {
    node.properties.className = ["highlighted", "word"];
  },
};

export default makeSource({
  contentDirPath: "content",
  documentTypes: [Post],
  mdx: {
    remarkPlugins: [remarkFrontmatter],
    rehypePlugins: [
      rehypeSlug,
      [rehypeAutolinkHeadings, { behavior: "wrap" }],
      [rehypePrettyCode, prettyCodeOptions],
    ],
  },
});

If you're using git, don't forget to add the generated content to your gitignore

# contentlayer
.contentlayer

Add Post Content

Create a folder called content

Create a file in content called first-post.mdx

---
title: First Post
excerpt: My first ever post on my blog
date: "2022-02-16"
---

# Hello World

My name is Roze and I built this blog to do cool things

- Like talking about pets
- And other cool stuff

## Random Code

```mdx {1,15} showLineNumbers title="Page.mdx"
import { MyComponent } from "../components/...";

# My MDX page

This is an unordered list

- Item One
- Item Two
- Item Three

<section>And here is _markdown_ in **JSX**</section>

Checkout my React component

<MyComponent />
```

Once you've created a new post, make sure to run your app to trigger contentlayer to generate

yarn dev

You should see a new folder called .contentlayer which will have a generated folder that defines your schemas and types.

Display All Blog Posts

We can use getStaticProps to pull data from our content folder because contentlayer provides us with allPosts

import { allPosts } from "../../.contentlayer/generated";
import { type GetStaticProps } from "next";
...
export const getStaticProps: GetStaticProps = () => {
  const posts = allPosts.sort(
    (a, b) => new Date(b.date).getTime() - new Date(a.date).getTime()
  );

  return {
    props: {
      posts,
    },
  };
};

Then update the component to show these posts

interface Props {
  posts: Post[];
}

const Home: NextPage<Props> = ({ posts }) => {
  r