Let's get started. Configure MakerKit and Firebase, and run the application for the first time!

Getting Started


MakerKit is **the Next.js boilerplate project for SaaS** built for getting you started on the right foot.

MakerKit is a fully SSR-rendered Next.js application that uses Firebase for authentication, database (with Firestore), and storage.

MakerKit is ideal for any SaaS application or other dynamic websites such as walled Online Publications.

It particularly shines when you wish to provide uniform navigation between your marketing site, documentation, and application.

## What does the boilerplate provide?

### Tech Stack

We built MakerKit with some of the best technologies available today, such as
Next.js, Tailwind, and Firebase:

- **Scalable Next.js** structure template, perfect for the most ambitious
projects
- Beautiful **Tailwind 3** CSS theme - with dark-mode!
- **Full Firebase** setup with local emulators
- **Reusable UI components** as building blocks (which you can easily swap
with your own or your favorite library) based on [Headless UI](https://headlessui.dev)
- **SSR-compatible Authentication flow**, including 3rd-party providers (Google,
Facebook, Twitter, GitHub, etc.)

### Template Features

MakerKit is fully functioning from the beginning and comes with the
following features:

- **Payments** with Stripe, and support for **subscriptions**
- **Onboarding flow**, which allows your users to set up their accounts and
create their organization
- **Organizations**: users can create and edit organizations. An organization is a group of users. You can rename the `Organization` entity according to your domain (for example, teams, projects, etc.)
- **Team Members**: users can invite other users to join their organization and assign them a role
- **MDX-powered Blog and Documentation** generators - already
**SEO-optimized** for you

### Marketing

Marketing matters! But don't get hung up on the technicalities. MakerKit provides:

- **Newsletter Sign-up form** for *ConvertKit*, but easy to adapt to more
providers
- **Google Analytics** script baked-in
- **Email Templates** you can write with React

### Debugging and Testing

Never waste time again chasing bugs.

Assuming you have created a Sentry account, MakerKit can catch exceptions (and possible bugs) and  report them to Sentry whenever they happen, in both client and server-side code:

- **Error Tracking** set up with Sentry
- Comprehensive **E2E Tests** suite with Cypress, which you can use and learn
from

### After you buy

You're not going to be left alone. We offer help and support:

- **Resources, examples, and guides** for building a SaaS using *MakerKit*
(Coming Soon)
- Access to the team for feedback, requests, and general support. **We're here to support you build your SaaS**.

This documentation introduces each of the points above and guide you through
so that you can easily adjust MakerKit to your application's domain.

MakerKit has plenty of resources for using both Next.js and Firebase - and if you're stuck,
you can always reach out to us for help.


Introduction to MakerKit: a SaaS starter built with Next.js and Firebase

Introduction to MakerKit: a SaaS boilerplate for Next.js and Firebase


MakerKit is built primarily with Next.js, Firebase, and Tailwind CSS.

Under the hood, there are many more libraries and architectural
decisions you should know.

### A Scalable Next.js Application
The codebase is entirely built with [Next.js](https://nextjs.org) (version 12),
a popular React meta-framework built by the fine folks at [Vercel](https://vercel.com).

The front-end is therefore fully built with React, leveraging React Hooks
and the best practices available today.

### Built on top of Firebase

[Firebase](https://firebase.com) is one of the most popular *PaaS* out there,
with a very generous free tier and fairly affordable pricing for growing
applications.

MakerKit uses Firebase for Authentication, Firestore for storing your data,
Storage for storing files, and AppCheck to protect your endpoints against
possible attacks.

### Theme built with Tailwind 3

The bulk of the application's theme, built with [Tailwind 3](https://tailwindcss.com/), is
stored in three CSS files rather than HTML.

It may sound like a bad practice, but we approached this way to help you find and edit
the theme's CSS in one single place.

We designed the theme in both light and dark themes, so you can choose to use both according to your user's OS settings, or you can manage it using a local cookie.

### Default Components built with Headless UI

Some components, such as `Dropdown`, `Popover` and `Modal`, have been
extended using [Headless UI](https://headlessui.dev), an accessible library
built by the Tailwind Team.

MakerKit uses Tailwindf CSS for styling all the other components too.

### Fully and Strictly Typed with Typescript

We wrote every single line of code with *strictly-typed
Typescript* both on the client and server-side.

### Validation with Zod

The API endpoints are **validated and protected with [Zod](https://github.com/colinhacks/zod)**, which also helps with strong-typing.

### Tested with Cypress

We ship MakerKit with [Cypress](https://www.cypress.io/), likely the most
popular E2E testing framework.

We made lots of examples and utilities to change the tests as you develop
your application.

### Linted with EsLint and formatted with Prettier

We lint the codebase with **a very strict EsLint configuration**, but
we distribute it with less strict params so that it won't be in your way
as you're experimenting with the starter.

We will show you how to add stricter parameters if that's your thing, but we do not recommend jumping head-in with it. It's much better to activate the stricter configuration once you have already shipped the product and are looking to stabilize it.

Furthermore, the codebase is **formatted with Prettier** automatically.

### i18n by default with next-i18n

We configured the application to be translated by default thanks to the
[next-i18n](http://next-i18next.com) package.

Using translation files can help you if you want to **translate your apps in multiple
languages**, but it also allows you to find the text strings you
want to replace.

In this way, you do not need to change strings in the codebase, but they're
**neatly organized in JSON files**.

### Logging with Pino

MakerKit uses [Pino](https://github.com/pinojs/pino), a lightweight logging library.

API errors are logged with just enough information to help you debug
your API routes.


MakerKit uses Next.js, Firebase, Firestore, Tailwind CSS, Zod, Pino, Headless UI, Typescript and Cypress to build wonderful SaaS applications

The technologies that make up a MakerKit application


If you have bought a license for MakerKit, you have access to all the repositories built by the MakerKit team.

To get started with the Next.js + Firebase SSR project, clone the repository with the following command:

```
git clone --depth=1 https://github.com/makerkit/mk-next-fire-ssr
```

The command above clone the repository in the folder `mk-next-fire-ssr` which
you can rename it with the name of your project.

Now, run the following command for installing the NodeJS dependencies:

```
cd mk-next-fire-ssr
npm i
```

While the application code is fully working, we now need to set up your Firebase
project.

So let's jump on to the next step!


Learn how to clone the MakerKit repository

Clone the MakerKit SaaS boilerplate repository


It's time to set up Firebase. You should be all set if you have already installed NodeJS on your machine. If not, please install [NodeJS](https://nodejs.org) before continuing.

If any of the following commands do not work, please install the Firebase tools package globally:

```
npm i firebase-tools -g
```

Now, run this command to set up your Firebase project:

```
firebase init
```

Now, select all the products you would like to set up. If you're not sure yet, I recommend the following ones:
- Emulators
- Cloud Firestore
- Cloud Storage
- Remote Config

#### Create or select a Project

If you have already created a project using the Firebase Console, continue by
using "Use an existing project"; otherwise, you can create one right away by
selecting "Create a new project".

If you're more comfortable creating a new project using the Firebase Console,
 [create a new project from here](https://console.firebase.google.com/).

#### Emulators

The CLI should prompt you to choose the emulators to download and the ports for each.
Next, select the emulators you need based on the products selected during the first step.

Remember to update your environment variables in the file `.env` if you choose any non-default option.
Otherwise, you don't need to make any changes because this starter already uses the Firebase default ports.

Once completed, you should have the following new files in your project:
- .firebaserc
- firebase.json
- firestore.rules
- firestore.indexes.json

## Firebase Project Set-up

If you have created a Firebase project, you should be able to access this
project using the [Firebase Console](https://console.firebase.google.com/).

We assume you're building a web app: let's create a new web project.

<Video src='/assets/images/docs/create-web-app-firebase.mp4' />

### Copying the Firebase configuration in the environment file

After the previous step, you should be seeing the Firebase configuration
object.

We need to add this to your `.env` file, which will automatically
populate the project configuration file `~/.configuration`.

```
NEXT_PUBLIC_FIREBASE_API_KEY=
NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=
NEXT_PUBLIC_FIREBASE_PROJECT_ID=
NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET=
NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID=
NEXT_PUBLIC_FIREBASE_APP_ID=
NEXT_PUBLIC_FIREBASE_MEASUREMENT_ID=
```

<Alert type='warn'>
Next.js bundles the environment variables prefixed with "NEXT_PUBLIC" with
your client-side code. It means that you should use these for non-secret values that need to be
exposed.
</Alert>

### Getting the service account

You can find the service account by clicking on `Settings->Service Accounts`.
You should copy the text highlighted in the video below:

<Video src='/assets/images/docs/find-service-account.mp4' />

Afterward, you need to populate the relative environment variable:

```bash
FIREBASE_CLIENT_EMAIL=
```

You could safely add it using the file of your staging account. If it's
 your production environment, please add it using the Vercel console instead (or any other service you use to
 deploy the project).

### Generating the Private Key

The private key is fundamental to running your app with Admin permissions on the
server-side. From the same page, click on "Generate Private key".

You should see the modal below:

<Image
  width={'1368'}
  height={'1018'}
  src={'/assets/images/docs/generate-private-key.webp'}
  alt={'Generate Firebase Private Key'}
/>

Once you open the generated JSON file, copy the `private_key` property and place it in your CI or your environment file as long as you do not commit the environment file.

The environment variable to populate is `FIREBASE_PRIVATE_KEY`:

```
FIREBASE_PRIVATE_KEY=
```

<Alert type='warn'>
Do not commit the file if you add the private key to your local environment file
</Alert>

## Firestore

Now it's time to set up Firestore DB. From the main panel on the left-hand side of the Firebase Console, click on `Firestore Database`.

Once you click on the `Create Database` CTA, you will se a modal like in the
image below:

<Image
  width={'1810'}
  height={'1132'}
  src={'/assets/images/docs/create-firestore-db.webp'}
  alt={'Create Firestore DB'}
/>

Don't overthink what to choose: we use the default MakerKit Firestore
rules which use the production configuration by default.

### Location
The next step is to choose the Firestore Database's location.

Which option to choose here depends entirely on **where you think most of
your users come from**.

<Image
  width={'1724'}
  height={'1034'}
  src={'/assets/images/docs/firestore-location.webp'}
  alt={'Choose Firestore Location'}
/>

Be careful to the Firebase notice:

<Alert type='warn'>
After you've set this location, you cannot change it later. Also, this location setting will be the location for your default Cloud Storage bucket.
</Alert>

If you're not sure, think it through. You do not need this step to start
working on your app with the Emulators, so feel free to come back to this
later when you have made a decision.

## App Check

App Check is a Firebase service that helps you to protect your web app from
bots.

<Alert type='info'>
Coming Soon
</Alert>


Learn how to set up your Firebase project with a MakerKit application

Setting up a Firebase project for you MakerKit application


We store the global configuration of a MakerKit application in `/configuration
.ts`.

Within any application file, we can use the path `~/configuration` to
import it from any other file.

<Alert type='info'>
You do not need any changes to start developing your application. Feel free
to complete the configuration once you want to deploy the app for the first
time.
</Alert>

The configuration has the following structure:

```typescript
export default {
  site: {
    title: '',
    description: '',
    themeColor: '',
    siteUrl: '',
    siteName: '',
    twitterHandle: '',
    language: 'en',
  },
  paths: {
    signIn: '/auth/sign-in',
    signUp: '/auth/sign-up',
    onboarding: `/onboarding`,
    appHome: '/dashboard',
    api: {
      checkout: `/api/stripe/checkout`,
      billingPortal: `/api/stripe/portal`,
    }
  },
  firebase: {
    apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
    authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
    projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
    storageBucket: process.env.NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET,
    messagingSenderId: process.env.NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID,
    appId: process.env.NEXT_PUBLIC_FIREBASE_APP_ID,
    measurementId: process.env.NEXT_PUBLIC_FIREBASE_MEASUREMENT_ID,
  },
  navigation: {
    style: NavigationStyle.TopHeader,
  },
  email: {
    host: '',
    port: 0,
    user: '',
    password: '',
  },
  autoBanners: true,
  emulatorHost: process.env.NEXT_PUBLIC_EMULATOR_HOST,
  emulator: process.env.NEXT_PUBLIC_EMULATOR === 'true',
  production: process.env.NEXT_PUBLIC_NODE_ENV === 'production',
  plans: [
    {
      name: 'Basic',
      description: 'Describe your basic plan',
      price: '$249/year',
      stripePriceId: '<STRIPE_PRICE_ID>',
    },
    {
      name: 'Pro',
      description: 'Describe your pro plan',
      price: '$999/year',
      stripePriceId: '<STRIPE_PRICE_ID>',
    },
  ],
};
```

These values are used throughout the application, instead of being hardcoded into the codebase.

As you may have noticed, some of these values are taken from Node's
environment. We will use an additional file name `.env`, which is used by
`Next` to read the configuration.

This file is not to be committed (at least not
the "secret" variable). You should define those variables within your
favorite CI/CD.

The `.env` template (`.env.template`) is the following:

```
# FIREBASE PUBLIC
NEXT_PUBLIC_EMULATOR=
NEXT_PUBLIC_FIREBASE_API_KEY=
NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=
NEXT_PUBLIC_FIREBASE_PROJECT_ID=
NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET=
NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID=
NEXT_PUBLIC_FIREBASE_APP_ID=
NEXT_PUBLIC_FIREBASE_MEASUREMENT_ID=
NEXT_PUBLIC_FIREBASE_EMULATOR_HOST=
NEXT_PUBLIC_FIRESTORE_EMULATOR_PORT=8080
NEXT_PUBLIC_FIREBASE_AUTH_EMULATOR_PORT=9099
NEXT_PUBLIC_FIREBASE_STORAGE_EMULATOR_PORT=9199
NEXT_PUBLIC_SITE_URL=

# FIREBASE SECRET
GCLOUD_PROJECT=
FIREBASE_CLIENT_EMAIL=
FIRESTORE_EMULATOR_HOST=localhost:8080
FIREBASE_AUTH_EMULATOR_HOST=localhost:9099
FIREBASE_STORAGE_EMULATOR_HOST=localhost:9199
FIREBASE_PUBSUB_EMULATOR_HOST=localhost:8085

FIREBASE_PRIVATE_KEY=

# STRIPE PUBLIC
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=

# STRIPE SECRET
STRIPE_SECRET_KEY=
STRIPE_WEBHOOK_SECRET=
```

Let's see the configuration in detail:

## Site

In this section, we define some overall details about the website. We use most of these configuration properties in public pages, blog posts, and documentation.

#### Title

This property is the default title of the website. We use it in conjunction with the page's name. For example, the title of the blog will be `Blog - { site.name }`.

#### Description

This title is the default description of the website. For blog posts, we override it with each entry's excerpt.

#### Theme Color

We use the property `themeColor` to define the primary color displayed by browsers. For example, in a PWA, it is the background color of the window's header.

#### Site URL

This `siteUrl` property should be your website's URL, including the protocol, such as https://yourwonderfulwebsite.com

#### Site Name

TBD

#### Twitter Handle

This is your or your company's Twitter handle you can use to link your blog posts to.

## Paths

Some of the paths are repeated many times throughout the codebase. For example: where should the user be redirected to after login?

These paths help you set up the default behavior when the user signs in, out, etc.

Of course, while we could store these in the codebase, it's the quickest way to get started with the boilerplate without changing any line of code.

## Firebase

The `firebase` object is Firebase's configuration which you can retrieve from the Firebase console. You could copy it and paste it in, as it's all is required.

If you use multiple environments (for example, `staging` and `production`), I recommend creating two `.env` files and starting your application using the correct one.

We will show later how to do set-up multiple environments effectively.

## Email

This setting allows you to define your email provider's SMTP authentication details to send emails in your application.

While in development, you can leave this as-is: MakerKit uses the `nodemailer` test account.

## Plans

Here you can store the plans that your application offers. They should match
the plans that you are going to create in the Stripe Dashboard.


Learn how to define the global configuration of a MakerKit application with Next.js and Firebase

Define the global configuration of your MakerKit SaaS application with Next.js and Firebase


After installing the modules and the emulators, we can finally run the
application.

We need to execute two commands:

- **Next.js Server** - the first command is for running the Next.js server
- **Firebase Emulators** - the second command is for running the Firebase
emulators

#### Running the Firebase Emulators

First, let's run the emulators. The command below runs the emulators for
the following products: Authentication, Firestore, and Storage.

```
npm run firebase:emulators:start
```

Additionally, it imports the default emulator's data from the folder `.
/firebase-seed`, which we set up upfront to run the Cypress tests.

#### Running the Next.js Server

And now, the Next server:

```
next run dev
```

If everything went well, your server should be running at [http://localhost:3000](http://localhost:3000)

## Saving the Firebase Emulator's data

After shutting the emulators down, the Firebase emulator clears all the records
and the users added during the session while the emulators are running.

Fortunately, we can save and restore as many dumps as we want. For example, this can be useful for saving and loading particular scenarios for testing.

To save the current snapshot, run the following command while the emulators are up and running:

```
npm run firebase:emulators:export
```

By default, MakerKit imports and exports to `./firebase-seed`, but you can change this to any other path.

### Always Save on exit

We don't particularly recommend this, but if you want to keep persisting data as you exit the emulators,
you can decorate the `firebase:emulators:start` with the following options:

```
firebase emulators:start --export-on-exit=./your-directory
```

Saving your emulators' state can be handy, but keep in mind that for testing reasons,
it's always best to create a snapshot of your data and use the same one so that your tests won't break if the data changes.

Of course, change `./your-directory` to your preferred path.


How to run a Next.js and Firebase MakerKit application


MakerKit's primary goals are:

- **Solid Foundations** - providing you with the necessary code to get up and
running
with a Saas with minimal configuration
- **Extendable and Adaptable** - the ability change and extend the codebase as
efficiently as possible

While it's relatively simple to provide a functioning codebase, it's not always easy to make it:
- **Simple** - a clean codebase quickly understandable by anyone
- **Easy to change** - a codebase that can be easily changed to a
particular domain

Once you get started on your project, you can begin unpicking and replacing the existing code to adapt it to your application's domain. At the same time, MakerKit may have pushed an update that fixed a bug or added a new cool feature.

The two projects will diverge, and quite inevitably, end up in a conflicting state.

Thankfully, Git makes it easy to merge conflicts. But it's still a hassle.

### Framework Architecture

To reduce the number of possible conflicts, MakerKit ships with a particular folder structure:

```
- src
  - lib
  - components
  - pages
    - api
  - core
```

These folders represent four separate layers. MakerKit is an Onion:

<Image
  width={'2103'}
  height={'1221'}
  src={'/assets/images/docs/architecture.png'}
  alt={"MakerKit's architecture"}
/>

### Core
Let's talk about the lower level: the `core`. This layer is a collection of building blocks, utilities, and API that make up MakerKit.

This part of the boilerplate is configurable and makes no assumptions about your domain.

You are still welcome to change this code to suit your needs, but you can expect most updates from upstream to change code in this directory.

### Lib and Components

The mid-level is in two separate folders (to avoid excessive nesting):

- `lib`: here is where we write most domain-related business logic (hooks, contexts, queries, mutations, etc.)
- `components`: here is where we write the domain-related components (ex. Profile Page, Create Project form, etc.)

MakerKit comes with some business logic (it would be nearly impossible otherwise to build a genuinely functioning SaaS). You should customize the existing logic for your application, and it is likely where you will add most of your code.

This layer can still be updated by upstream, but you should not expect too many changes unless it's additions for new features or bug fixes.

### Pages

Finally, the `pages` layer is the outer layer of the application.

It's entirely dependent on your application, and you should not expect updates from upstream unless for fixing blatantly buggy code.



Learn how MakerKit allows you to build a Next.js application with a scalable and production-grade architecture and folder structure

Architecture and Folder Structure for your Next.js SaaS application


MakerKit's data model is voluntarily as simple as possible, with a limited
set of assumptions.

MakerKit is not supposed to be a finite product but a solid foundation on which it is quick
to get started and build your SaaS product.

## Users

Users are, of course, foundational to any application.

If a user signed in using Firebase Authentication, it merely means we have verified their credentials, but not that they have an account.

We have to create an additional collection to store a user's data, such as:
- settings
- the memberships they belong to
- any other information which is not possible to update using their Authentication record (profile photo, name, email, and sign-in providers)

We only store the user's organizations as an object on the `users` collections by default.

The Firestore model looks like something similar:

```
- users
  - [userId]:
    - ... user data
```

We store the relationships between users and organizations within the
`Organizations` collection.

## Organizations

`Organizations` are groups of users.

If the name doesn't suit your domain, don't worry: you can always change the terminology using the localization files.

A user can belong to one or many organizations: each organization lists its members in an object, similar to what we do with `users`.

The below is what the `Organizations` schema looks like:

```
- organizations
  - [organizationId]
      - name
      - timezone
      - members
        - [memberId]
          - role
          - user // this is a Firestore reference
  }
```

Of course, we can assign a `name` to every organization and a `timezone` property (before you realize you're going to need it).

We define each membership by the user ID. Each membership contains the following information:

- the user role
- the user reference to `/users/[userId]`

Thus, we store the role in both collections to reduce the number of reads when we query the project members: we need to keep them in sync.

### User Roles

By default, MakerKit defines three roles: Owner (can be only one), Admin, and Member.

This enum is hierarchical and associated with a number:

```tsx
enum MembershipRole {
  Member,    // 0
  Admin,     // 1
  Owner      // 2
}
```

By default, an Admin can do anything a member can do, and an Owner can do anything an Admin can.

### Invites

To create an invite to join an organization, we use a new collection
`invites` placed below an `organization` document: for example,
`/organizations/1/invites/1`.

The invite's interface is also very simple:

```tsx
interface MembershipInvite {
  code: string;
  email: string;
  role: MembershipRole;
  expiresAt: number;

  organization: {
    id: string;
    name: string;
  };
}
```

- the `email` property represents the email of the user invited. The application supports users signing up with a different email: you have to change this if you wish to disallow it
- the `role` is the assigned role, which cannot be `Owner`
- the `code` property is the unique identifier from which the user can access
the invite through a link
- the `expiresAt` property is the Unix timestamp when the invite will
expire. By default, it's going to be one week
- the `organization` object duplicates some valuable data from its
parent (which saves us from rereading the document)


Learn how MakerKit defines the model of your SaaS application with Next.js and Firebase

The MakerKit Data Model for your SaaS project built with Next.js and Firebase

Learn how MakerKit authenticates your users, and how to set-up Firebase Auth

Authentication


MakerKit uses Firebase to manage authentication within your application.

By default, every kit comes with the following built-in authentication methods:
- **Email/Password** - we added, by default, the traditional way of signing in
- **Social** - we also added by default both Google and Facebook sign-in methods

You're free to add (or remove) ant of the methods supported by Firebase's
Authentication: we will see how.

This documentation will help you with:
 - **Setup** - setting up your Firebase project
 - **SSR** - using SSR to persist your users' authentication, adding new
providers
 - **Customization** - an overview of how MakerKit works so that you can adapt
it to your own application's needs

## SSR

We set up MakerKit to persist the user's session on all the website's pages using SSR.

SSR allows for seamless integration between the pages of your website. For example, your pricing page could prompt your users to upgrade to the new plan rather than what it shows to non-subscribers of your service.

Many websites use persistent sessions in different ways:

- personalized content
- pre-filled forms
- and a lot more

While it sounds great, there is a downside: by server-side rendering the page (SSR), we lose the possibility to statically generate the page (SSG), which is faster.

#### Should you use SSR or SSG?

Ultimately, it comes down to what your needs and preferences are.

MakerKit does not use SSR by default but adding it is very simple.


MakerKit uses Firebase Authentication to allow access to your Next.js application using oAuth providers and email/password.

Setting up Firebase and Next.js authentication with MakerKit


If you have completed the previous steps, you should have already created a Firebase Project and initialized the repository.

At this point, we can start setting up the authentication providers from the Firebase admin console.

While using the emulator, this step is not needed; feel free to skip this part in the beginning.

## Getting Started with Firebase Auth

From the Firebase console, navigate to the `Authentication` menu item using
the left-hand side panel.

<Image
  width={'1838'}
  height={'798'}
  src={'/assets/images/docs/auth-setup.webp'}
  alt={'Firebase Auth Getting Started'}
/>

After clicking on "Getting Started" you should see all the available providers that you can choose:

<Video src='/assets/images/docs/activate-sign-up.mp4' />

Please do activate all the ones you're planning on using.

We have already configured MakerKit to work with:
 - Email/Password authentication
 - Google oAuth
 - Facebook oAuth


Learn how to set up Firebase Auth in your MakerKit application

Setting up Firebase Auth with Next.js


If you use SSR, the flow is slightly different from what you may be
used.

Typically, Firebase allows signing users in on the client-side. If you use SSR,
we need a way to authenticate the user on the server-side.

To do so, we use Firebase Auth's session cookies: we create the cookie when
the user signs in and then destroy it when the user signs out.

### Step 1: User signs in using the client SDK

The user can sign in (or up) using the Firebase Auth client SDK from the client side.

### Step 2: Creating a Session Cookie

After being authenticated (signing in or up), the application requests to create and store a session cookie.

The cookie is stored as an HTTP-only cookie and will be sent to the server,
so we can authenticate users right when we render the page.

When needed, we can perform the necessary redirects and security checks server-side.

### Step 3: Page Rendering

The application renders a session-aware page if you have opted to use SSR on every page. Otherwise, the Firebase SDK should reflect the current session once the page has been rendered.

### Step 4: User signs out

The client SDK starts a sign-out request when the user decides to sign out.

When Firestore Auth destroys the current user session, the event is intercepted by a listener and then calls the API endpoint to destroy the session cookie.


Learn how MakerKit handles the authentication flow with Firebase Auth and Next.js

Firebase and Next.js authentication flow


By default, the kit uses Google and Firebase as the two third-party providers to allow users to access the application.

With that said, you could decide to add other providers that Firebase provides or even custom ones.

## Customizing the Third Party providers

If you want to customize the 3rd party providers or the design of the button, you should update the `OAuthProviders` component.

This component uses a custom hook called `useSignInWithProvider` provided by the framework.

A button is built with the component `AuthProviderButton`. Here is an example:

```tsx
<AuthProviderButton
  image={'/assets/images/google.png'}
  alt={'Sign in with Google'}
  onClick={onSignIn}
>
  Sign in with Google
</AuthProviderButton>
```

Let's make together a component that:
- uses a provider from Firebase
- allows for SSR by creating a session cookie using the built-in API routes

Let's make a custom `OAuthProviders` which uses `Github` instead of the default providers:

```tsx
import { GithubAuthProvider } from 'firebase/auth';

function OAuthProviders() {
  const [signInWithProvider, signInState] = useSignInWithProvider();
  const [sessionRequest, sessionRequestState] = useCreateSession();
  const createCsrfToken = useCsrfToken();

  useEffect(() => {
    // only run when user signed in
    if (!signInState.success) {
      return;
    }

    // only run one request at a time
    if (
      sessionRequestState.loading ||
      sessionRequestState.error ||
      sessionRequestState.success
    ) {
      return;
    }

    void (async () => {
      const user = signInState.data?.user;
      const idToken = await user?.getIdToken();

      if (!idToken) {
        return;
      }

      const csrfToken = createCsrfToken();

      // we can create the session and store a cookie to make SSR work
      // additionally, we also pass a CSRF token
      await sessionRequest({ idToken, csrfToken });

      onSuccess();
    })();
  }, [
    onSuccess,
    sessionRequest,
    signInState,
    sessionRequestState,
    createCsrfToken,
  ]);

  return (
    <div>
      <AuthProviderButton
        image={'/assets/images/github.png'}
        alt={'Sign in with Github'}
        onClick={onSignIn}
        onSignIn={() => signInWithProvider(new GithubAuthProvider())}
      >
          Sign in with Github
      </AuthProviderButton>

      <If condition={sessionRequestState.error || state.error}>
        {(e) => {
          const error = getFirebaseErrorCode(e);

          return <AuthErrorMessage error={error} />;
        }}
      </If>
    </div>
  );
};
```

Et voilá! We now have a Github sign-in/up flow with this component alone.


Learn how to setup Third-Paerty providers with Firebase Auth in your MakerKit application

Set up Third party authentication providers with Next.js and Firebase


MakerKit uses SSR throughout the website. If you choose to use SSR, you can persist the user's authentication on every page.

Whether SSR on every page is something your website may need or not is up to your needs, but MakerKit makes this process very easy.

Let's assume the following is your Next.js Index page, and we want to show the user's Profile avatar if they signed in. You will need to fetch the user's data from the `getServerSideProps` function and return it as `props` to the current page.

The MakerKit default template does it for you, but you need to remember that you need to add the following snippet to every page you want the authentication persisted.

```tsx
import { withUserProps } from '~/app/with-user-props';

function Index({ user }) {
    // display user in your components
}

export function getServerSideProps(ctx: GetServerSidePropsContext) {
  return withUserProps(ctx);
}
```

MakerKit also provides a `UserContext` context, which you can inject with `useContext` in any of your components. Assuming you have a component `AvatarComponent` in which you want to display your user's avatar:

```tsx
function ProfileAvatar() {
    const { user } = useContext(UserContext);

    return (
        <img src={user.profileURL} alt='Profile Photo' />
    )
}
```

Alternatively, you can use the hook `useUserSession`:

```tsx
function ProfileAvatar() {
    const {auth} = useUserSession();

    return (
        <img src={auth.profileURL} alt='Profile Photo' />
    )
}
```


Learn how to use SSR with Firebase Authentication and Next.js

Using SSR with Firebase and Next.js authentication


MakerKit provides various utilities that allow you to restrict access to
certain pages or API according to factors such as: sign-in state, role,
membership plan, etc.

## Protecting Next.js Pages

To protect against access to certain pages, we can use the function
`withAppProps`. This function is a server-side props handler which will take
care of checking the following conditions:

- if the user is signed in - otherwise will be redirected back to the sign
in page (this is customizable)
- if the user is onboarded - otherwise will be redirected back to the
onboarding
- if the page they are trying to access requires a certain membership plan

Assuming you want to protect the `Dashboard` page, it will be as easy as:

```tsx
import { withAppProps } from '~/lib/props/with-app-props';

export async function getServerSideProps(
  ctx: GetServerSidePropsContext
) {
  return await withAppProps(ctx);
}
```

It's likely that you will want to add additional logic, or additional props
to be sent to the page. In this case, you can partially evaluate
`withAppProps` and extend the props with other information:

```tsx
import { withAppProps } from '~/lib/props/with-app-props';

export async function getServerSideProps(
  ctx: GetServerSidePropsContext
) {
  const { props: appProps } =
    await withAppProps(ctx);

  const data = await getDataFromDb();

  return {
    props: {
      ...appProps,
      data,
    }
  };
}
```
This handler takes the following parameters:

```tsx
const DEFAULT_OPTIONS = {
  redirectPath: configuration.paths.signIn,
  locale: 'en',
  localeNamespaces: <string[]>[],
  requirePlans: <string[]>[],
}
```

- `redirectPath`: by default, we redirect the user to the signIn page when
they're not authenticated
- `redirectPath`: by default, we use the `en` locale
- `localeNamespaces`: additional namespaces you want to add to the route
- `requirePlans`: a list of Stripe price IDs that you ma want to require to
access this page. If you require more complex logic, it's best to handle it
separately


Page Guards allow you to protect certain routes from unauthorized access. This docs explain how MakerKit makes the process of protecting your Next.js pages easy and quick.

Protect your Next.js application's pages with Guards


unaunri
API Guards are similar to Page Guards, except they belong to the server and
will protect our API endpoints.

As an example, let's take MakerKit's implementation for handling user
invites. We want to check that:
- the user is authenticated
- the endpoint method being called is correct

```tsx
import { withAuthedUser } from '~/core/middleware/with-authed-user';

export default function inviteHandler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  const handler = withMiddleware(
    withMethodsGuard(SUPPORTED_METHODS),
    withAuthedUser,
    inviteMembersToOrganizationHandler
  );

  return withExceptionFilter(req, res)(handler);
}
```

As you can see above, we're using various guards: `withMethodsGuard` and
`withAuthedUser`.

These two guards will make sure that the request will get rejected if the
user isn't authenticated or if the user submitted a request using a
disallowed HTTP method.

You can also simplify the above if you only want to check if the user is
signed-in:

```tsx
export default function myAPIHandler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  await withAuthedUser(req, res);

  // do something with res
}
```


MakerKit uses API Guards allow to protect your Next.js API endpoints from unauthorized users, bad input, etc.

Protect your Next.js application's API with Guards

Learn how to configure and write your product's Blog and Documentation

Blog and Docs


MakerKit has both Blogs and a Documentation site built-in so that you can
start working on your content even before you launch your product.

We placed the sections together because, naturally, Blog and Docs share a good amount of code.

We can write the Blog posts and the documentation pages using [MDX
files](https://mdxjs.com/).

Thanks to MDX, we can augment the built-in components with richer styling and more complex components.


MakerKit allows you to easily add blog posts and a documentation website yo your Next.js application

Add Blog posts and a Documentation website to your Next.js application


We can add your website's blog posts within the `_posts` folder.

## Collections

Before writing a blog post, we have to define the post's collection. We use collections to organize our blog posts by their category.

For example, your blog could have collections such as changelog,
announcements, tutorials, etc.

MakerKit generates every collection with their page, listing all the articles
associated with it.

To change a collection page, please change the file `src/pages/blog/[collection].ts`.

### Adding collections

Let's see how we can define a `collection` in Typescript:

```tsx
interface Collection {
  name: string;

  // image
  logo?: string;
  emoji?: string;
}
````

As you can see, the only required property to create a collection is a name. You can also attach an image or a simple emoji for each collection.

A collection can be simply the following file:

```json
{
  "name":"Changelog"
}
```

## Writing a Blog Post
The interface of a blog post is the following:

```tsx
interface Post {
  title: string;
  excerpt: string;

  date: string;
  live: boolean;
  tags?: string[];

  coverImage?: string;

  ogImage?: {
    url: string;
  };

  author?: {
    name: string;
    picture: string;
    url: string;
  };

  canonical?: string;
}
```

These values can be defined in MDX files using the `frontmatter`, for example:

```yaml
---
title: An Awesome Post title
except: "Write here a short description for your blog post"
collection: changelog.json
date: '2022-01-05'
live: true
coverImage: '/assets/images/posts/announcement.webp'
tags:
  - changelog
  - coolstuff
---
```

#### Title
The property `title` is the title of the blog post.

NB: it does not correspond to the URL. The URL
segment, instead, is defined by the name of the file.

#### Excerpt
Write a short description for your blog post. This description will also
populate the relative meta tags.

#### Collection
The property `collection` is the path to the collection associated with the blog post.

NB: the `.json` extension needs to be part of the name.

#### Live
You can choose to publish or not a blog post by setting this property to `false`.

### Cover Image
The property `coverImage` is the path to the post's image.

If `coverImage` is undefined, and the configuration property `autoBanners` is set to `true` then **a banner is
automatically generated** for your blog posts.

### Tags
A list of tags you can attach to the post.

For each tag, MakerKit generates a page with every blog post associated, which you can update at `src/pages/blog/tags/[tag.tsx]`.


Learn how to add blog posts in your MakerKit application

Add Blog posts to your Next.js application


We place the MakerKit's documentation pages within the `_docs` folder.

## Topics
The pages are defined hierarchically so that you can define your
documentation in the following way:

```
- _docs
  - [topic]
    - [topic.json]
    - [page].mdx
```

The documentation you're reading, for example, is defined as follows.

The MakerKit kit has a folder called `_docs`: in this folder, we have a list of
sub-folders for each topic we are describing.

Each folder has a metadata file named `meta.json`:

```json
{
  "title": "Blog and Docs",
  "position": 2,
  "description": "Learn how to configure and write your product's Blog and Documentation"
}
```

The `position` property defines the order of the topics. In
the case above, the topic `Blog and Docs` will be the third topic in the list.

## Pages

Within each topic, we define the collection pages defined as MDX files.
They share the same components as the blog posts' files.

A page is defined as follows:

```yaml
---
title: Blog
position: 1
---
```

The `position` property defines the order in which the page is listed within
the topic.


Learn how to add documentation pages in your Next.js application

Add a Documentation website to your Next.js application

Learn about Makerkit's Organizations' model and members invites

Organizations


<Alert type={'info'}>Coming Soon</Alert>


MakerKit's Organizations

Learn how to configure Stripe, and start collecting payments from your customers

Payments


MakerKit offers support for subscriptions and payments using [Stripe](https://stripe.com).

To get started with [Stripe Checkout](https://stripe.com/docs/payments/checkout), you will need to create an account using the [Stripe website](https://stripe.com).

If you want, you can get your business details sorted right away. If you
want to continue with the set-up, you can skip it for now and get back to it later.

## Configuration

Visit the [Stripe Checkout Tutorial](https://stripe.com/docs/checkout/quickstart?client=next) where we can copy the
configuration for our development environment.

If you click on the file `.env` of the code editor on the right-hand side,
you will be able to see the variables needed:

- `NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY`
- `STRIPE_SECRET_KEY`
- `STRIPE_WEBHOOK_SECRET`

Copy these values to your local `.env` file.

## Creating your SaaS plans in Stripe

Stripe allows us to create our plans using the UI in the Stripe Dashboard.

To get started, let's add a couple of testing plans that you can use while
developing your application.

Visit [the Stripe Dashboard](https://dashboard.stripe.com/test/products/prod_KpXDAnvbPkXkgp) and add a new product (for example, a one-time purchase or a SaaS subscription).

You can add multiple "prices": for example, if you're defining a
subscription, you could use two plans, "Basic" and "Pro".

They are the default plans in MakerKit, so it's good to start with these for
playing around with Stripe: you can change them later on.

Now that we have created the plans, we need to set the plan IDs in your
configuration. Open the file `~/configuration.ts` and set the
`stripePriceId` property with IDs of your plans:

```tsx
{
  name: 'Basic',
  description: 'Unlimited applications and 2-hour onboarding session',
  price: '$249/year',
  stripePriceId: '<YOUR_PRICE_ID_GOES_HERE>',
}
```

### Install The Stripe CLI

The Stripe CLI is required to help us test our integration.
Please [follow this guide to install the CLI on your system](https://stripe.com/docs/stripe-cli).

### Connect CLI with your account

To connect the Stripe CLI with your account, run the following command:

```
npm run stripe:listen
```

The CLI should prompt you to connect your account. If you signed in already, visit the link and follow the instructions.

If you followed the instructions, get back to the terminal, and then copy
the webhook secret to your `STRIPE_WEBHOOK_SECRET` environment variables in the
`.env` file.

Restart the next.js server to apply the changes.

## Billing Portal

MakerKit uses the [Stripe Billing Portal](https://dashboard.stripe.com/test/settings/billing/portal) to let your users manage their invoices and subscriptions.

The portal becomes accessible once the organization subscribes to a plan, which creates a `customerId` property, making it possible for the organization to access the portal.

### Enabling the Billing Portal in test mode

Please visit the [Stripe Billing Page](https://dashboard.stripe.com/test/settings/billing/portal) to enable the Billing Portal.

Choose the settings that best apply to your product and save your changes.

The only required fields to get started are `Terms of Service` and
`Privacy` URLs. You can add any URL at this stage. **However, remember to update these pages when you go live**.


Learn how to configure Stripe with your MakerKit application

Set up Stripe Payments for Next.js and Firebase SaaS applications

Learn the MakerKit best practices for building and shipping your app

Development

Learn how to use, edit or replace MakerKit's UI components

UI Components


MakerKit comes with a few pre-built components by default. You are free to
swap the components with your own, or with your favourite UI library.

Many components, such as `Dropdown`, `Popover` and `Modal` have been taken
from the wonderful [Headless UI](https://headlessui.dev) built by the
Tailwind team.




MakerKit's UI React Component

Route Shell Component


The component's styles have largely been placed in a single file `components.css`
which you can find at `src/styles/components.css`.

Ok, let us explain why.

Even though we are trying to MakerKit look fantastic from the get-go,
chances are you will be changing the design heavily.

To make it as easy as
possible, we think that by placing the styles in a single place, you'll be
able to go through each style faster than if you had to chase many files in
the codebase.

Each class has been defined styled using Tailwind. For example, the styles
of the `Alert` component is defined as follows:

```css
@tailwind components;

@layer components {
    .Alert {
        @apply
            py-4 border-l-8
            px-4 rounded-lg
            font-semibold text-sm
            flex items-center justify-between;
    }

    /* ... other components */
}
```


Styling MakerKit's Components with Tailwind CSS


### Container

A simple component used as a responsive main container.

```tsx
import Container from '~/core/ui/Container';

function MyPage({ value, children }) {
  return (
    <Container>
      { children }
    </Container>
  );
}
```

### If

The `If` component is useful to conditionally render the children components
based on a condition:

```tsx
import If from '~/core/ui/If';

function Component({ value, children }) {
  return (
    // this `children` tree will only render if `value` is truthy
    <If condition={value}>
      { children }
    </If>
  );
}
```

It's also possibly to pass a `fallback` parameter to conditionally render a
fallback component if `condition` is falsy.

```tsx
import If from '~/core/ui/If';

function Component({ loading, children }) {
  return (
    <If
      condition={!loading}
      fallback={<span>Loading...</span>}
    >
      { children }
    </If>
  );
}
```

### ClientOnly

The `ClientOnly` component is useful to only render the children components
if the component is being rendered in a browser environment:

```tsx
import ClientOnly from '~/core/components/ClientOnly';

function Component({ children }) {
  return (
    <ClientOnly>
      { children }
    </ClientOnly>
  );
}
```

### LazyRender

The `LazyRender` component is useful to render the component's children tree
only when visible (or when being intersected according to your configuration).

Very useful for SEO and performance improvements.

```tsx
import LazyRender from '~/core/components/LazyRender';

function Component({ children }) {
  return (
    <LazyRender>
      { children }
    </LazyRender>
  );
}
```

You can supply an additional parameter `rootMargin`, which is the
`Intersection Observer` [parameter that controls the configuration of the
intersection](https://developer.mozilla.org/en-US/docs/Web/API/IntersectionObserver/rootMargin).


MakerKit's React Components Utilities


The Alert component accepts the following parameters:

```tsx
interface Props {
  type: 'success' | 'error' | 'warn' | 'info';
  useCloseButton?: boolean;
  className?: string;
}
```

### Types

#### Info

<div className='flex flex-col my-4'>
  <Alert type='info'>
    <span>Info Alert</span>
  </Alert>
</div>

```tsx
<Alert type='info'>
  Info Alert
</Alert>
```

#### Success

<div className='flex my-4 flex-col'>
  <Alert type='success'>
    <span>Success Alert</span>
  </Alert>
</div>

```tsx
<Alert type='success'>
  Success Alert
</Alert>
```

#### Warn

<div className='flex my-4 flex-col'>
  <Alert type='warn' useCloseButton={true}>
    <span>Warn Alert</span>
  </Alert>
</div>

```tsx
<Alert type='warn' useCloseButton={true}>
  Warn Alert
</Alert>
```

#### Error

<div className='flex my-4 flex-col'>
  <Alert type='error' useCloseButton={true}>
    <span>Error Alert</span>
  </Alert>
</div>

```tsx
<Alert type='error' useCloseButton={true}>
  Error Alert
</Alert>
```


Alert Component

The Badge component accepts the following parameters:

```tsx
type Color = `normal` | 'custom';
type Size = `normal` | `small`;

interface Props {
  color?: Color;
  size?: Size;
  className?: string;
}
```

### Basic Badge

<div className='flex my-4'>
  <Badge>
    <span>Label</span>
  </Badge>
</div>

```tsx
<Badge>
  Label
</Badge>
```

### Badge Sizes

<div className='my-4 flex space-x-4 items-center'>
  <div>
    <Badge size={'small'}>
      <span>Small Badge</span>
    </Badge>
  </div>

  <div>
    <Badge size={'normal'}>
      <span>Normal Badge</span>
    </Badge>
  </div>
</div>

```tsx
<div className='my-4 flex space-x-4 items-center'>
  <div>
    <Badge size={'small'}>
      Small Badge
    </Badge>
  </div>

  <div>
    <Badge size={'normal'}>
      Normal Badge
    </Badge>
  </div>
</div>
```


Badge Component


The Button component accepts the following parameters:

```tsx
type Color =
  | 'primary'
  | 'secondary'
  | 'transparent'
  | 'danger'
  | 'custom';

type Size = 'normal' | 'small' | 'large' | 'custom';
type Style = `normal` | `outline` | `flat`;

interface Props {
  block?: boolean;
  color?: Color;
  size?: Size;
  style?: Style;
  loading?: boolean;
  href?: string;
}
```

### Button Types

<div className={`my-4 flex flex-col md:flex-row md:items-center space-y-2
 md:space-y-0 space-x-4`}>
  <Button color={'primary'}>
    Click Here
  </Button>

  <Button color={'secondary'}>
    Click Here
  </Button>

  <Button color={'danger'}>
    Click Here
  </Button>

  <Button color={'transparent'}>
    Click Here
  </Button>
</div>

```tsx
<Button color={'primary'}>
  Click Here
</Button>

<Button color={'secondary'}>
  Click Here
</Button>

<Button color={'danger'}>
  Click Here
</Button>

<Button color={'transparent'}>
  Click Here
</Button>
```

### Button Sizes

<div
  className='my-4 flex flex-col md:flex-row items-start md:items-center
  space-y-2
 md:space-y-0 space-x-4'
>
  <div>
    <Button color={'primary'} size={'small'}>
      Small Button
    </Button>
  </div>

  <div>
    <Button color={'primary'} size={'normal'}>
      Normal Button
    </Button>
  </div>

  <div>
    <Button color={'primary'} size={'large'}>
      Large Button
    </Button>
  </div>
</div>

```tsx
<div>
  <Button color={'primary'} size={'small'}>
    Small Button
  </Button>
</div>

<div>
  <Button color={'primary'} size={'normal'}>
    Normal Button
  </Button>
</div>

<div>
  <Button color={'primary'} size={'large'}>
    Large Button
  </Button>
</div>
```

### Loading State button

<div className='my-4'>
  <Button color={'primary'} loading={true}>
    Click Here
  </Button>
</div>

```tsx
<Button color={'primary'} loading={true}>
  Click Here
</Button>
```

### Button Link

The `Button` component with a `href` attribute will wrap a Next.js `Link`
component and can be used as a normal link styled as a button.

<div className='my-4'>
  <Button color={'primary'} href={'/docs/components-button'}>
    Go to Page
  </Button>
</div>

```tsx
<Button color={'primary'} href={'/docs/components-button'}>
  Go to Page
</Button>
```

### Full Width Button

You can add the `block` attribute to let the button grow as much as its parent.

<div className='my-4 w-60'>
  <Button block color={'danger'}>
    Are you sure you want to continue?
  </Button>
</div>

```tsx
<Button block color={'danger'}>
  Are you sure you want to continue?
</Button>
```


Button Component


The `TextField` is a wrapper around the native `input` HTML element.
Therefore, the component accepts the parameters accepted by
`HTMLInputElement`, and a further `innerRef` parameter to pass a React `ref`
to the inner input:

```tsx
type Props = React.InputHTMLAttributes<unknown> & {
  innerRef?: LegacyRef<HTMLInputElement>;
};
```

## Usage

<div className={'flex flex-col space-y-4'}>
  <TextField>
    <TextField.Label>
      Email Address
      <TextField.Input placeholder={'your@email.com'} />
    </TextField.Label>
  </TextField>

  <TextField>
    <TextField.Label>
      Password
      <TextField.Input type={'password'} placeholder={'**************'} />
      <TextField.Hint>Yo! Make it strong :)</TextField.Hint>
    </TextField.Label>
  </TextField>
</div>

```tsx
<div className={'flex flex-col space-y-4'}>
  <TextField>
    <TextField.Label>
      Email Address

      <TextField.Input placeholder={'your@email.com'} />
    </TextField.Input>
  </TextField>

  <TextField>
    <TextField.Label>
      Password

      <TextField.Input
        type={'password'}
        placeholder={'**************'}
      />

      <TextField.Hint>Yo! Make it strong :)</TextField.Hint>
    </TextField.Label>
  </TextField>
</div>
```


Text Field Component


The Heading component accepts the following parameters:

```tsx
type HeadingType = 1 | 2 | 3 | 4 | 5 | 6;

interface Props {
  type: HeadingType;
}
```

### Usage

<Heading type={1}>Heading 1</Heading>
<Heading type={2}>Heading 2</Heading>
<Heading type={3}>Heading 3</Heading>
<Heading type={4}>Heading 4</Heading>
<Heading type={5}>Heading 5</Heading>
<Heading type={6}>Heading 6</Heading>

```tsx
<Heading type={1}>Heading 1</Heading>
<Heading type={2}>Heading 2</Heading>
<Heading type={3}>Heading 3</Heading>
<Heading type={4}>Heading 4</Heading>
<Heading type={5}>Heading 5</Heading>
<Heading type={6}>Heading 6</Heading>
```


Heading Component


This Image Upload Input component is a wrapper around `input[file]` which
improves the UX of uploading file images.

The component accepts the following props:

```tsx
type Props = Omit<React.InputHTMLAttributes<unknown>, 'value'> & {
  innerRef?: LegacyRef<HTMLInputElement>;
  image?: string | null;
  onClear?: () => void;
};
```

## Usage

```tsx
function Form() {
  const onClear = () => console.log(`The user cleared the existing image`);
  const existingImage = `/a/url/to/an/image.png`;

  return (
    <form>
      <ImageUploadInput
        onClear={onClear}
        name={'photoUrl'}
        image={existingImage}
      >
        Upload Image
      </ImageUploadInput>
    </form>
  );
}
```

### Demo

Select an image:

<div>
  <label className={'w-full md:w-[250px]'}>
    <ImageUploadInput>
      <span>Select an Image</span>
    </ImageUploadInput>
  </label>
</div>


Image Upload Input Component

Learn how to prepare your application for shipping to production

Going to Production


<Alert type='info'>
Coming Soon
</Alert>



Shopping to Production a MakerKit application

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx} = arguments[0];
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, {})
  })) : _createMdxContent();
  function _createMdxContent() {
    return _jsx(_Fragment, {});
  }
}
return {
  default: MDXContent
};
