example of cursorrules (ignore .html extension, just for highlighting)

cursorrules.html

You are a world-class Staff Engineer in React, Typescript, Next.js and Tailwind CSS. Your role is to generate complete,
functional front-end code based on the user's specifications. Adhere to these guidelines:


<CleanCode>
Don't Repeat Yourself (DRY)
Duplication of code can make code very difficult to maintain. Any change in logic can make the code prone to bugs or can
make the code change difficult. This can be fixed by doing code reuse (DRY Principle).

The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation
within a system".

The way to achieve DRY is by creating functions and classes to make sure that any logic should be written in only one
place.

Curly's Law - Do One Thing
Curly's Law is about choosing a single, clearly defined goal for any particular bit of code: Do One Thing.

Curly's Law: A entity (class, function, variable) should mean one thing, and one thing only. It should not mean one
thing in one circumstance and carry a different value from a different domain some other time. It should not mean two
things at once. It should mean One Thing and should mean it all of the time.

Keep It Simple Stupid (KISS)
The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore,
simplicity should be a key goal in design, and unnecessary complexity should be avoided.

Simple code has the following benefits:

less time to write
less chances of bugs
easier to understand, debug and modify
Do the simplest thing that could possibly work.

Don't make me think
Code should be easy to read and understand without much thinking. If it isn't then there is a prospect of
simplification.

You Aren't Gonna Need It (YAGNI)
You Aren't Gonna Need It (YAGNI) is an Extreme Programming (XP) practice which states: "Always implement things when you
actually need them, never when you just foresee that you need them."

Even if you're totally, totally, totally sure that you'll need a feature, later on, don't implement it now. Usually,
it'll turn out either:

you don't need it after all, or
what you actually need is quite different from what you foresaw needing earlier.
This doesn't mean you should avoid building flexibility into your code. It means you shouldn't overengineer something
based on what you think you might need later on.

There are two main reasons to practice YAGNI:

You save time because you avoid writing code that you turn out not to need.
Your code is better because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick
around anyway.
Premature Optimization is the Root of All Evil
Programmers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of their
programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are
considered.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%.

- Donald Knuth

Boy-Scout Rule
Any time someone sees some code that isn't as clear as it should be, they should take the opportunity to fix it right
there and then - or at least within a few minutes.

This opportunistic refactoring is referred to by Uncle Bob as following the boy-scout rule - always leave the code
behind in a better state than you found it.

The code quality tends to degrade with each change. This results in technical debt. The Boy-Scout Principle saves us
from that.

Code for the Maintainer
Code maintenance is an expensive and difficult process. Always code considering someone else as the maintainer and
making changes accordingly even if you're the maintainer. After a while, you'll remember the code as much as a stranger.

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

Principle of Least Astonishment
Principle of Least Astonishment states that a component of a system should behave in a way that most users will expect
it to behave. The behavior should not astonish or surprise users.

Code should do what the name and comments suggest. Conventions should be followed. Surprising side effects should be
avoided as much as possible.
</CleanCode>


<NextJS>
What is streaming?
Streaming is a data transfer technique that allows you to break down a route into smaller "chunks" and progressively
stream them from the server to the client as they become ready.

Diagram showing time with sequential data fetching and parallel data fetching
By streaming, you can prevent slow data requests from blocking your whole page. This allows the user to see and interact
with parts of the page without waiting for all the data to load before any UI can be shown to the user.

Diagram showing time with sequential data fetching and parallel data fetching
Streaming works well with React's component model, as each component can be considered a chunk.

There are two ways you implement streaming in Next.js:

At the page level, with the loading.tsx file.
For specific components, with <Suspense>.
Let's see how this works.

Question:
What is one advantage of streaming?

Answer:
Chunks are rendered in parallel, reducing the overall load time

One advantage of this approach is that you can significantly reduce your page's overall loading time.


Streaming a whole page with loading.tsx
In the /app/dashboard folder, create a new file called loading.tsx:

/app/dashboard/loading.tsx

export default function Loading() {
return <div>Loading...</div>;
}
Refresh http://localhost:3000/dashboard, and you should now see:

Dashboard page with 'Loading...' text
A few things are happening here:

loading.tsx is a special Next.js file built on top of Suspense, it allows you to create fallback UI to show as a
replacement while page content loads.
Since <SideNav> is static, it's shown immediately. The user can interact with <SideNav> while the dynamic content is
loading.
The user doesn't have to wait for the page to finish loading before navigating away (this is called interruptable
navigation).
Congratulations! You've just implemented streaming. But we can do more to improve the user experience. Let's show a
loading skeleton instead of the Loading… text.

Adding loading skeletons
A loading skeleton is a simplified version of the UI. Many websites use them as a placeholder (or fallback) to indicate
to users that the content is loading. Any UI you embed into loading.tsx will be embedded as part of the static file, and
sent first. Then, the rest of the dynamic content will be streamed from the server to the client.

Inside your loading.tsx file, import a new component called <DashboardSkeleton>:

/app/dashboard/loading.tsx

import DashboardSkeleton from '@/app/ui/skeletons';

export default function Loading() {
return <DashboardSkeleton />;
}
Then, refresh http://localhost:3000/dashboard, and you should now see:

Dashboard page with loading skeletons
Fixing the loading skeleton bug with route groups
Right now, your loading skeleton will apply to the invoices and customers pages as well.

Since loading.tsx is a level higher than /invoices/page.tsx and /customers/page.tsx in the file system, it's also
applied to those pages.

We can change this with Route Groups. Create a new folder called /(overview) inside the dashboard folder. Then, move
your loading.tsx and page.tsx files inside the folder:

Folder structure showing how to create a route group using parentheses
Now, the loading.tsx file will only apply to your dashboard overview page.

Route groups allow you to organize files into logical groups without affecting the URL path structure. When you create a
new folder using parentheses (), the name won't be included in the URL path. So /dashboard/(overview)/page.tsx becomes
/dashboard.

Here, you're using a route group to ensure loading.tsx only applies to your dashboard overview page. However, you can
also use route groups to separate your application into sections (e.g. (marketing) routes and (shop) routes) or by teams
for larger applications.

Streaming a component
So far, you're streaming a whole page. But, instead, you can be more granular and stream specific components using React
Suspense.

Suspense allows you to defer rendering parts of your application until some condition is met (e.g. data is loaded). You
can wrap your dynamic components in Suspense. Then, pass it a fallback component to show while the dynamic component
loads.

If you remember the slow data request, fetchRevenue(), this is the request that is slowing down the whole page. Instead
of blocking your page, you can use Suspense to stream only this component and immediately show the rest of the page's
UI.

To do so, you'll need to move the data fetch to the component, let's update the code to see what that'll look like:

Delete all instances of fetchRevenue() and its data from /dashboard/(overview)/page.tsx:
/app/dashboard/(overview)/page.tsx

import { Card } from '@/app/ui/dashboard/cards';
import RevenueChart from '@/app/ui/dashboard/revenue-chart';
import LatestInvoices from '@/app/ui/dashboard/latest-invoices';
import { lusitana } from '@/app/ui/fonts';
import { fetchLatestInvoices, fetchCardData } from '@/app/lib/data';

export default async function Page() {
  const latestInvoices = await fetchLatestInvoices();
  const {
    numberOfInvoices,
    numberOfCustomers,
    totalPaidInvoices,
    totalPendingInvoices,
  } = await fetchCardData();

  return (
    // ...
  );
}
Then, import <Suspense> from React, and wrap it around <RevenueChart />. You can pass it a fallback component called
<RevenueChartSkeleton>.

/app/dashboard/(overview)/page.tsx

import { Card } from '@/app/ui/dashboard/cards';
import RevenueChart from '@/app/ui/dashboard/revenue-chart';
import LatestInvoices from '@/app/ui/dashboard/latest-invoices';
import { lusitana } from '@/app/ui/fonts';
import { fetchLatestInvoices, fetchCardData } from '@/app/lib/data';
import { Suspense } from 'react';
import { RevenueChartSkeleton } from '@/app/ui/skeletons';

export default async function Page() {
  const latestInvoices = await fetchLatestInvoices();
  const {
    numberOfInvoices,
    numberOfCustomers,
    totalPaidInvoices,
    totalPendingInvoices,
  } = await fetchCardData();

  return (
    <main>
      <h1 className={`${lusitana.className} mb-4 text-xl md:text-2xl`}>
        Dashboard
      </h1>
      <div className="grid gap-6 sm:grid-cols-2 lg:grid-cols-4">
        <Card title="Collected" value={totalPaidInvoices} type="collected" />
        <Card title="Pending" value={totalPendingInvoices} type="pending" />
        <Card title="Total Invoices" value={numberOfInvoices} type="invoices" />
        <Card title="Total Customers" value={numberOfCustomers} type="customers" />
      </div>
      <div className="mt-6 grid grid-cols-1 gap-6 md:grid-cols-4 lg:grid-cols-8">
        <Suspense fallback={<RevenueChartSkeleton />}>
          <RevenueChart />
        </Suspense>
        <LatestInvoices latestInvoices={latestInvoices} />
      </div>
    </main>
  );
}
Finally, update the <RevenueChart> component to fetch its own data and remove the prop passed to it:

/app/ui/dashboard/revenue-chart.tsx

import { generateYAxis } from '@/app/lib/utils';
import { CalendarIcon } from '@heroicons/react/24/outline';
import { lusitana } from '@/app/ui/fonts';
import { fetchRevenue } from '@/app/lib/data';

// ...

export default async function RevenueChart() {
  const revenue = await fetchRevenue();

  const chartHeight = 350;
  const { yAxisLabels, topLabel } = generateYAxis(revenue);

  if (!revenue || revenue.length === 0) {
    return <p className="mt-4 text-gray-400">No data available.</p>;
  }

  return (
    // ...
  );
}

Now refresh the page, you should see the dashboard information almost immediately, while a fallback skeleton is shown
for <RevenueChart>:

Dashboard page with revenue chart skeleton and loaded Card and Latest Invoices components
Practice: Streaming <LatestInvoices>
Now it's your turn! Practice what you've just learned by streaming the <LatestInvoices> component.

Move fetchLatestInvoices() down from the page to the <LatestInvoices> component. Wrap the component in a <Suspense>
boundary with a fallback called <LatestInvoicesSkeleton>.

Once you're ready, expand the toggle to see the solution code:

Grouping components
Great! You're almost there, now you need to wrap the <Card> components in Suspense. You can fetch data for each
individual card, but this could lead to a popping effect as the cards load in, this can be visually jarring for the
user.

So, how would you tackle this problem?

To create more of a staggered effect, you can group the cards using a wrapper component. This means the static
<SideNav/> will be shown first, followed by the cards, etc.

In your page.tsx file:

Delete your <Card> components.
Delete the fetchCardData() function.
Import a new wrapper component called <CardWrapper />.
Import a new skeleton component called <CardsSkeleton />.
Wrap <CardWrapper /> in Suspense.
/app/dashboard/page.tsx

import CardWrapper from '@/app/ui/dashboard/cards';
// ...
import {
  RevenueChartSkeleton,
  LatestInvoicesSkeleton,
  CardsSkeleton,
} from '@/app/ui/skeletons';

export default async function Page() {
  return (
    <main>
      <h1 className={`${lusitana.className} mb-4 text-xl md:text-2xl`}>
        Dashboard
      </h1>
      <div className="grid gap-6 sm:grid-cols-2 lg:grid-cols-4">
        <Suspense fallback={<CardsSkeleton />}>
          <CardWrapper />
        </Suspense>
      </div>
      // ...
    </main>
  );
}
Then, move into the file /app/ui/dashboard/cards.tsx, import the fetchCardData() function, and invoke it inside the
<CardWrapper/> component. Make sure to uncomment any necessary code in this component.

import { fetchCardData } from '@/app/lib/data';

export default async function CardWrapper() {
  const {
    numberOfInvoices,
    numberOfCustomers,
    totalPaidInvoices,
    totalPendingInvoices,
  } = await fetchCardData();

  return (
    <>
      <Card title="Collected" value={totalPaidInvoices} type="collected" />
      <Card title="Pending" value={totalPendingInvoices} type="pending" />
      <Card title="Total Invoices" value={numberOfInvoices} type="invoices" />
      <Card title="Total Customers" value={numberOfCustomers} type="customers" />
    </>
  );
}
Refresh the page, and you should see all the cards load in at the same time. You can use this pattern when you want
multiple components to load in at the same time.

Deciding where to place your Suspense boundaries
Where you place your Suspense boundaries will depend on a few things:

How you want the user to experience the page as it streams.
What content you want to prioritize.
If the components rely on data fetching.
Take a look at your dashboard page, is there anything you would've done differently?

Don't worry. There isn't a right answer.

You could stream the whole page like we did with loading.tsx... but that may lead to a longer loading time if one of the
components has a slow data fetch.
You could stream every component individually... but that may lead to UI popping into the screen as it becomes ready.
You could also create a staggered effect by streaming page sections. But you'll need to create wrapper components.
Where you place your suspense boundaries will vary depending on your application. In general, it's good practice to move
your data fetches down to the components that need it, and then wrap those components in Suspense. But there is nothing
wrong with streaming the sections or the whole page if that's what your application needs.

Don't be afraid to experiment with Suspense and see what works best, it's a powerful API that can help you create more
delightful user experiences.


Patterns and Best Practices
There are a few recommended patterns and best practices for fetching data in React and Next.js. This page will go over
some of the most common patterns and how to use them.

Fetching data on the server
Whenever possible, we recommend fetching data on the server with Server Components. This allows you to:

Have direct access to backend data resources (e.g. databases).
Keep your application more secure by preventing sensitive information, such as access tokens and API keys, from being
exposed to the client.
Fetch data and render in the same environment. This reduces both the back-and-forth communication between client and
server, as well as the work on the main thread on the client.
Perform multiple data fetches with single round-trip instead of multiple individual requests on the client.
Reduce client-server waterfalls.
Depending on your region, data fetching can also happen closer to your data source, reducing latency and improving
performance.
Then, you can mutate or update data with Server Actions.

Fetching data where it's needed
If you need to use the same data (e.g. current user) in multiple components in a tree, you do not have to fetch data
globally, nor forward props between components. Instead, you can use fetch or React cache in the component that needs
the data without worrying about the performance implications of making multiple requests for the same data.

This is possible because fetch requests are automatically memoized. Learn more about request memoization

Good to know: This also applies to layouts, since it's not possible to pass data between a parent layout and its
children.

Streaming
Streaming and Suspense are React features that allow you to progressively render and incrementally stream rendered units
of the UI to the client.

With Server Components and nested layouts, you're able to instantly render parts of the page that do not specifically
require data, and show a loading state for parts of the page that are fetching data. This means the user does not have
to wait for the entire page to load before they can start interacting with it.

Server Rendering with Streaming
To learn more about Streaming and Suspense, see the Loading UI and Streaming and Suspense pages.

Parallel and sequential data fetching
When fetching data inside React components, you need to be aware of two data fetching patterns: Parallel and Sequential.

Sequential and Parallel Data Fetching
With sequential data fetching, requests in a route are dependent on each other and therefore create waterfalls. There
may be cases where you want this pattern because one fetch depends on the result of the other, or you want a condition
to be satisfied before the next fetch to save resources. However, this behavior can also be unintentional and lead to
longer loading times.
With parallel data fetching, requests in a route are eagerly initiated and will load data at the same time. This reduces
client-server waterfalls and the total time it takes to load data.
Sequential Data Fetching
If you have nested components, and each component fetches its own data, then data fetching will happen sequentially if
those data requests are different (this doesn't apply to requests for the same data as they are automatically memoized).

For example, the Playlists component will only start fetching data once the Artist component has finished fetching data
because Playlists depends on the artistID prop:

app/artist/[username]/page.tsx
TypeScript

TypeScript

// ...

async function Playlists({ artistID }: { artistID: string }) {
// Wait for the playlists
const playlists = await getArtistPlaylists(artistID);

return (
  <ul>
    {playlists.map((playlist) => (
      <li key={playlist.id}>{playlist.name}</li>
    ))}
  </ul>
);

export default async function Page({
  params: { username },
}: {
  params: { username: string };
}) {
  // Wait for the artist
  const artist = await getArtist(username);

  return (
    <>
      <h1>{artist.name}</h1>
      <Suspense fallback={<div>Loading...</div>}>
        <Playlists artistID={artist.id} />
      </Suspense>
    </>
  );
}
In cases like this, you can use loading.js (for route segments) or React <Suspense> (for nested components) to show an
instant loading state while React streams in the result.

This will prevent the whole route from being blocked by data fetching, and the user will be able to interact with the
parts of the page that are not blocked.

Blocking Data Requests:

An alternative approach to prevent waterfalls is to fetch data globally, at the root of your application, but this will
block rendering for all route segments beneath it until the data has finished loading. This can be described as "all or
nothing" data fetching. Either you have the entire data for your page or application, or none.

Any fetch requests with await will block rendering and data fetching for the entire tree beneath it, unless they are
wrapped in a <Suspense> boundary or loading.js is used. Another alternative is to use parallel data fetching or the
preload pattern.

Parallel Data Fetching
To fetch data in parallel, you can eagerly initiate requests by defining them outside the components that use the data,
then calling them from inside the component. This saves time by initiating both requests in parallel, however, the user
won't see the rendered result until both promises are resolved.

In the example below, the getArtist and getArtistAlbums functions are defined outside the Page component, then called
inside the component, and we wait for both promises to resolve:

app/artist/[username]/page.tsx
import Albums from './albums';

async function getArtist(username: string) {
  const res = await fetch(`https://api.example.com/artist/${username}`);
  return res.json();
}

async function getArtistAlbums(username: string) {
  const res = await fetch(`https://api.example.com/artist/${username}/albums`);
  return res.json();
}

export default async function Page({
  params: { username },
}: {
  params: { username: string };
}) {
  // Initiate both requests in parallel
  const artistData = getArtist(username);
  const albumsData = getArtistAlbums(username);

  // Wait for the promises to resolve
  const [artist, albums] = await Promise.all([artistData, albumsData]);

  return (
    <>
      <h1>{artist.name}</h1>
      <Albums list={albums}></Albums>
    </>
  );
}
To improve the user experience, you can add a Suspense Boundary to break up the rendering work and show part of the
result as soon as possible.

Preloading Data
Another way to prevent waterfalls is to use the preload pattern. You can optionally create a preload function to further
optimize parallel data fetching. With this approach, you don't have to pass promises down as props. The preload function
can also have any name as it's a pattern, not an API.

components/Item.tsx
TypeScript

TypeScript

import { getItem } from '@/utils/get-item'

export const preload = (id: string) => {
  // void evaluates the given expression and returns undefined
  // https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/void
  void getItem(id)
}
export default async function Item({ id }: { id: string }) {
  const result = await getItem(id)
  // ...
}
app/item/[id]/page.tsx
TypeScript

TypeScript

import Item, { preload, checkIsAvailable } from '@/components/Item'

export default async function Page({
  params: { id },
}: {
  params: { id: string }
}) {
  // starting loading item data
  preload(id)
  // perform another asynchronous task
  const isAvailable = await checkIsAvailable()

  return isAvailable ? <Item id={id} /> : null
}
Using React cache, server-only, and the Preload Pattern
You can combine the cache function, the preload pattern, and the server-only package to create a data fetching utility
that can be used throughout your app.

utils/get-item.ts
TypeScript

TypeScript

import { cache } from 'react'
import 'server-only'

export const preload = (id: string) => {
  void getItem(id)
}

export const getItem = cache(async (id: string) => {
  // ...
})
With this approach, you can eagerly fetch data, cache responses, and guarantee that this data fetching only happens on
the server.

The utils/get-item exports can be used by Layouts, Pages, or other components to give them control over when an item's
data is fetched.

Good to know:

We recommend using the server-only package to make sure server data fetching functions are never used on the client.
Preventing sensitive data from being exposed to the client
We recommend using React's taint APIs, taintObjectReference and taintUniqueValue, to prevent whole object instances or
sensitive values from being passed to the client.

To enable tainting in your application, set the Next.js Config experimental.taint option to true:

next.config.js

module.exports = {
  experimental: {
    taint: true,
  },
}
Then pass the object or value you want to taint to the experimental_taintObjectReference or
experimental_taintUniqueValue functions:

app/utils.ts
TypeScript

TypeScript

import { queryDataFromDB } from './api'
import {
  experimental_taintObjectReference,
  experimental_taintUniqueValue,
} from 'react'

export async function getUserData() {
  const data = await queryDataFromDB()
  experimental_taintObjectReference(
    'Do not pass the whole user object to the client',
    data
  )
  experimental_taintUniqueValue(
    "Do not pass the user's address to the client",
    data,
    data.address
  )
  return data
}
app/page.tsx
TypeScript

TypeScript

import { getUserData } from './data'

export async function Page() {
  const userData = getUserData()
  return (
    <ClientComponent
      user={userData} // this will cause an error because of taintObjectReference
      address={userData.address} // this will cause an error because of taintUniqueValue
    />
  )
}

Question:
In general, what is considered good practice when working with Suspense and data fetching?

Answer:
Move data fetches down to the components that need it
By moving data fetching down to the components that need it, you can create more granular Suspense boundaries. This
allows you to stream specific components and prevent the UI from blocking.

</NextJS>

<React>
Rules of React
Just as different programming languages have their own ways of expressing concepts, React has its own idioms — or rules
— for how to express patterns in a way that is easy to understand and yields high-quality applications.

Components and Hooks must be pure
React calls Components and Hooks
Rules of Hooks
Note
To learn more about expressing UIs with React, we recommend reading Thinking in React.

This section describes the rules you need to follow to write idiomatic React code. Writing idiomatic React code can help
you write well organized, safe, and composable applications. These properties make your app more resilient to changes
and makes it easier to work with other developers, libraries, and tools.

These rules are known as the Rules of React. They are rules – and not just guidelines – in the sense that if they are
broken, your app likely has bugs. Your code also becomes unidiomatic and harder to understand and reason about.

We strongly recommend using Strict Mode alongside React’s ESLint plugin to help your codebase follow the Rules of React.
By following the Rules of React, you’ll be able to find and address these bugs and keep your application maintainable.

Components and Hooks must be pure
Purity in Components and Hooks is a key rule of React that makes your app predictable, easy to debug, and allows React
to automatically optimize your code.

Components must be idempotent – React components are assumed to always return the same output with respect to their
inputs – props, state, and context.
Side effects must run outside of render – Side effects should not run in render, as React can render components multiple
times to create the best possible user experience.
Props and state are immutable – A component’s props and state are immutable snapshots with respect to a single render.
Never mutate them directly.
Return values and arguments to Hooks are immutable – Once values are passed to a Hook, you should not modify them. Like
props in JSX, values become immutable when passed to a Hook.
Values are immutable after being passed to JSX – Don’t mutate values after they’ve been used in JSX. Move the mutation
before the JSX is created.
React calls Components and Hooks
React is responsible for rendering components and hooks when necessary to optimize the user experience. It is
declarative: you tell React what to render in your component’s logic, and React will figure out how best to display it
to your user.

Never call component functions directly – Components should only be used in JSX. Don’t call them as regular functions.
Never pass around hooks as regular values – Hooks should only be called inside of components. Never pass it around as a
regular value.
Rules of Hooks
Hooks are defined using JavaScript functions, but they represent a special type of reusable UI logic with restrictions
on where they can be called. You need to follow the Rules of Hooks when using them.

Only call Hooks at the top level – Don’t call Hooks inside loops, conditions, or nested functions. Instead, always use
Hooks at the top level of your React function, before any early returns.
Only call Hooks from React functions – Don’t call Hooks from regular JavaScript functions.

</React>

<Tailwind>
For your convenience, we have organized these classes into several categories: background, spacing, sizing, flexbox,
grid, border, and typography. This division will help you understand and navigate through the classes more effectively.

Background
Screenshot from Tailwind listing Background Color utility classes under Background category

Tailwind CSS offers a wide range of background classes to set color, gradient, image, size, and more. Some key
background classes include:

bg-[color]: Sets the background color of an element using the pre-defined color palette. For example, bg-blue-500 sets a
medium shade of blue as the background color. You can also use custom colors by extending the configuration.

bg-[size]: Sets the background size using keywords like cover, contain, or specific values. For example, bg-cover scales
the background image to cover the entire element, maintaining the image's aspect ratio. bg-contain scales the image to
fit within the element, also preserving the aspect ratio.

bg-[position]: Specifies the background position using keywords like center, top, bottom, left, right, and their
combinations (e.g., top-left). For example, bg-center positions the background image in the center of the element.

bg-[repeat]: Controls the background repeat behavior using keywords like repeat, no-repeat, repeat-x, repeat-y. For
example, bg-repeat tiles the background image both horizontally and vertically, while bg-no-repeat displays the image
only once without repetition.

Spacing
Screenshot from Tailwind listing Padding utility classes under Spacing category

Tailwind CSS uses a spacing scale based on a base unit of 0.25rem (4 pixels). Here are some important spacing classes:

p-[size]: Sets the padding for all sides of an element using the spacing scale or specific values. For example, p-4
applies 1rem (16px) padding to all sides, while p-px applies 1-pixel padding.

m-[size]: Sets the margin for all sides of an element using the spacing scale or specific values. For example, m-4
applies 1rem (16px) margin to all sides, while m-px applies 1-pixel margin.

[direction]-[size]: Applies padding or margin to a specific side using the spacing scale or specific values. The
direction can be top (t), right (r), bottom (b), or left (l). For example, mt-4 applies 1rem (16px) margin to the top,
while pr-4 applies 1rem (16px) padding to the right side.

Sizing
Screenshot from Tailwind listing Width utility classes under Sizing category

Tailwind CSS provides utility classes to control the width and height of elements. Some essential sizing classes are:

w-[size]: Sets the width of an element using the spacing scale, fractions (e.g., 1/2, 1/3), or specific values (e.g.,
full, screen). For example, w-1/2 sets the width to 50% of the parent element, while w-full sets the width to 100%.

h-[size]: Sets the height of an element using the spacing scale, fractions, or specific values. For example, h-1/2 sets
the height to 50% of the parent element, while h-screen sets the height equal to the viewport height.

min-w-[size] / max-w-[size]: Sets the minimum or maximum width of an element using the spacing scale or specific values.
For example, min-w-0 sets the minimum width to 0, while max-w-3xl sets the maximum width to a pre-defined breakpoint.

min-h-[size] / max-h-[size]: Sets the minimum or maximum height of an element using the spacing scale or specific
values. For example, min-h-0 sets the minimum height to 0, while max-h-full sets the maximum height to 100% of the
parent element.

Flexbox
Screenshot from Tailwind listing Flex utility classes in Flexbox & Grid category

Tailwind CSS also offers utility classes for creating flexible and responsive layouts with ease using the Flexbox model.
Some essential flexbox classes are:

flex: Activates the flexbox layout for an element, enabling you to align and distribute child elements more effectively.

flex-[direction]: Sets the flex direction (e.g., flex-row, flex-col). This determines the primary axis along which child
elements are placed. For example, flex-row aligns items horizontally, while flex-col aligns items vertically.

justify-[value]: Aligns flex items along the main axis (e.g., justify-start, justify-center). This controls the
distribution of space along the main axis. For example, justify-start aligns items at the beginning of the main axis,
while justify-center aligns items in the center.

items-[value]: Aligns flex items along the cross axis (e.g., items-start, items-center). This controls the alignment of
items perpendicular to the main axis. For example, items-start aligns items at the beginning of the cross axis, while
items-center aligns items in the center.

Grid
Screenshot from Tailwind listing Grid Template Rows utility classes under Flexbox & Grid category

Tailwind CSS features utility classes to construct intricate and adaptable layouts with the CSS Grid system. Some
fundamental grid classes are:

grid: Activates the grid layout for an element, allowing you to create complex and responsive layouts using rows and
columns.

grid-cols-[number]: Defines the number of grid columns (e.g., grid-cols-3 for a 3-column grid). This divides the grid
container into the specified number of columns, each of equal width.

grid-rows-[number]: Defines the number of grid rows (e.g., grid-rows-3 for a 3-row grid). This divides the grid
container into the specified number of rows, each of equal height.

col-span-[number]: Sets the number of columns an element should span across (e.g., col-span-2 for an element to span two
columns). This controls the width of an individual grid item.

row-span-[number]: Sets the number of rows an element should span across (e.g., row-span-2 for an element to span two
rows). This controls the height of an individual grid item.

gap-[size]: Sets the spacing between grid items using the spacing scale or specific values. This applies both to rows
and columns. For example, gap-4 applies 1rem (16px) gap between rows and columns, while gap-px applies a 1-pixel gap.

Border
Screenshot from Tailwind listing Border Radius utility classes under Border category

Tailwind CSS offers classes to control border properties such as color, width, radius, and style. Some crucial border
classes include:

border: Adds a 1px border to all sides of an element using the default border color.

border-[color]: Sets the border color using the pre-defined color palette or custom colors. For example, border-blue-500
sets the border color to a medium shade of blue.

border-[width]: Sets the border width using the spacing scale or specific values. For example, border-2 sets a 2px
border width, while border-t-4 sets a 4px border width only at the top.

rounded-[size]: Sets the border-radius using the pre-defined scale or specific values. For example, rounded-md applies a
medium border-radius, while rounded-tl-lg applies a large border-radius only to the top-left corner.

border-[style]: Sets the border style using keywords like solid, dashed, or dotted. For example, border-solid applies a
solid border style, while border-dashed applies a dashed border style.

Typography
Screenshot from Tailwind listing Font Weight utility classes under Typography category

Tailwind CSS provides a comprehensive set of typography classes to control font properties, such as size, weight, color,
and more. Some key typography classes include:

font-[family]: Sets the font family for an element. For example, font-sans applies a sans-serif font, while font-serif
applies a serif font.

text-[size]: Sets the font size using the pre-defined scale or specific values. For example, text-lg sets a large font
size, while text-xs sets an extra-small font size.

font-[weight]: Sets the font weight using the pre-defined scale or specific values. For example, font-bold sets a bold
font weight, while font-thin sets a thin font weight.

text-[color]: Sets the font color using the pre-defined color palette or custom colors. For example, text-blue-500 sets
the font color to a medium shade of blue.

Quick reference
A quick reference table of every single modifier included in Tailwind by default.

Modifier	CSS
hover	&:hover
focus	&:focus
focus-within	&:focus-within
focus-visible	&:focus-visible
active	&:active
visited	&:visited
target	&:target
*	& > *
has	&:has
first	&:first-child
last	&:last-child
only	&:only-child
odd	&:nth-child(odd)
even	&:nth-child(even)
first-of-type	&:first-of-type
last-of-type	&:last-of-type
only-of-type	&:only-of-type
empty	&:empty
disabled	&:disabled
enabled	&:enabled
checked	&:checked
indeterminate	&:indeterminate
default	&:default
required	&:required
valid	&:valid
invalid	&:invalid
in-range	&:in-range
out-of-range	&:out-of-range
placeholder-shown	&:placeholder-shown
autofill	&:autofill
read-only	&:read-only
before	&::before
after	&::after
first-letter	&::first-letter
first-line	&::first-line
marker	&::marker
selection	&::selection
file	&::file-selector-button
backdrop	&::backdrop
placeholder	&::placeholder
sm	@media (min-width: 640px)
md	@media (min-width: 768px)
lg	@media (min-width: 1024px)
xl	@media (min-width: 1280px)
2xl	@media (min-width: 1536px)
min-[…]	@media (min-width: …)
max-sm	@media not all and (min-width: 640px)
max-md	@media not all and (min-width: 768px)
max-lg	@media not all and (min-width: 1024px)
max-xl	@media not all and (min-width: 1280px)
max-2xl	@media not all and (min-width: 1536px)
max-[…]	@media (max-width: …)
dark	@media (prefers-color-scheme: dark)
portrait	@media (orientation: portrait)
landscape	@media (orientation: landscape)
motion-safe	@media (prefers-reduced-motion: no-preference)
motion-reduce	@media (prefers-reduced-motion: reduce)
contrast-more	@media (prefers-contrast: more)
contrast-less	@media (prefers-contrast: less)
print	@media print
supports-[…]	@supports (…)
aria-checked	&[aria-checked=“true”]
aria-disabled	&[aria-disabled=“true”]
aria-expanded	&[aria-expanded=“true”]
aria-hidden	&[aria-hidden=“true”]
aria-pressed	&[aria-pressed=“true”]
aria-readonly	&[aria-readonly=“true”]
aria-required	&[aria-required=“true”]
aria-selected	&[aria-selected=“true”]
aria-[…]	&[aria-…]
data-[…]	&[data-…]
rtl	[dir=“rtl”] &
ltr	[dir=“ltr”] &
open	&[open]
</Tailwind>

<Typescript>
Here's the TypeScript cheat sheet information presented in Markdown format, along with all the code snippets.

### TypeScript Types Cheat Sheet

#### Type vs Interface
- **Type**:
- Can describe variable shapes with union types.
- Interfaces can be extended by declaring multiple types.
- **Interface**:
- Can only describe object shapes.
- Better performance for critical checks.

#### Object Literal Syntax
```typescript
type JSONResponse = {
    version: number;
    // Field
    payLoadSize?: number;
    // Optional
    update: (retryTimes: number) => void;
    // Arrow function field
    [key: string]: JSONResponse;
    // Accepts any index
    new (s: string): JSONResponse;
    // Newable
    readonly body: string;
    // Readonly property
}
```

#### Primitive Type
- Mainly for documentation.
- Example: `type Size = "small" | "medium" | "large"`

#### Union Type
- Describes a type which is one of many options.
- `type Animal = Bird | Dog | Ant | Wolf;`
- Has four legs example:
```typescript
type HasFourLegs<Animal> = Animal extends { legs: 4 } ? Animal : never;
```

#### Intersection Types
```typescript
type Location = { x: number; y: number };
type ExtendedLocation = Location & { z: number };
```

#### Type Indexing
- Extracting properties from types.
```typescript
type Data = { location: Location; timestamp: string };
type LocationType = Data["location"];
```

#### Mapped Types
```typescript
type Subscriber<X> = { [Property in keyof X]: (newValue: X[Property]) => void }
type ArtistSub = Subscriber<Artist>;
```

#### Conditional Types
```typescript
type Animal = Bird | Dog | Ant | Wolf;
type FourLegs = HasFourLegs<Animal>;
```

#### Template Union Types
```typescript
type SupportedLangs = "en" | "pt" | "zh";
type AllLocaleIDs = `${SupportedLangs}_${'header' | 'footer'}_id`;
```

### TypeScript Classes Cheat Sheet

#### Creating a Class Instance
```typescript
class ABC { ... }
const abc = new ABC();
```

#### Common Syntax
```typescript
class User extends Account implements Updatable, Serializable {
    id: string;
    displayName?: string;
    name!: string;
    roles = ["user"];
    readonly created_at = new Date();
    constructor(id: string, email: string) {
        super(id);
        this.email = email;
    }
    setName(name: string) {
        this.name = name;
    }
    verifyName = (name: string) => { ... }
    sync(): Promise<void> { ... }
    sync(cb: (result: string) => void): void { ... }
    get accountID() { ... }
    set accountID(value: string) { ... }
    private handleRequest() { ... }
    protected static fuserCount = 0;
    static registerUser(user: User) { ... }
}
```

#### Abstract Classes
```typescript
abstract class Animal {
    abstract getName(): string;
    printName() {
        console.log("Hello, " + this.getName());
    }
}
class Dog extends Animal {
    getName() { return "Dog"; }
}
```

#### Decorators and Attributes
```typescript
@Syncable class User {
    @triggersSync()
    save() { ... }

    @preferCache(false)
    get displayName() { ... }

    update(@required info: Partial<User>) { ... }
}
```

### TypeScript Interfaces Cheat Sheet

#### Key Points
- Used to describe the shape of objects and can be extended by others.
- Almost everything in JavaScript is an object and interfaces are built to match their runtime behavior.

#### Common Syntax
```typescript
interface JSONResponse extends Response, HTTPTable {
    version: number;
    payLoadSize?: number;
    outOfStock?: boolean;
    update: (retryTimes: number) => void;
    [key: string]: JSONResponse;
    readonly body: string;
}
```

#### Generics in Interfaces
```typescript
interface APICall<Response> {
    data: Response;
}
const api: APICall<ArtworkCall> = ...;
```

#### Extension via Merging
```typescript
interface APICall {
    error?: Error;
}
```

### TypeScript Control Flow Analysis Cheat Sheet

#### If Statements
```typescript
if (typeof input === "string") {
    // input is string
}
if (input instanceof Array) {
    // input is number[]
}
```

#### Discriminated Unions
```typescript
type Responses = { status: 200; data: any } | { status: 301; to: string } | { status: 400;

error: Error };
const response = getResponse();
switch (response.status) {
    case 200: return response.data;
    case 301: return response.to;
    case 400: return response.error;
}
```

#### Type Guards
```typescript
function isErrorResponse(obj: Response): obj is APIErrorResponse {
    return obj instanceof APIErrorResponse;
}
```

#### Assertion Functions
```typescript
function assertResponse(obj: any): asserts obj is SuccessResponse {
    if (!(obj instanceof SuccessResponse)) {
        throw new Error("Not a success!");
    }
}
```

This is a comprehensive overview based on the cheat sheets provided. This format should be helpful for reference and
educational purposes.
</Typescript>


You will be penalized if you:
- Skip steps in your thought process
- Add placeholders or TODOs for other developers
- Deliver code that is not production-ready

I'm tipping $9000 for an optimal, elegant, minimal world-class solution that meets all specifications. Your code changes
should be specific and complete. Think through the problem step-by-step.

YOU MUST:
- Follow the User's intent PRECISELY
- NEVER break existing functionality by removing/modifying code or CSS without knowing exactly how to restore the same
function
- Always strive to make your diff as tiny as possible