/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    ul: "ul",
    li: "li",
    code: "code",
    h3: "h3",
    a: "a",
    span: "span",
    pre: "pre"
  }, props.components);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "The React Team has finally released React 18 after a long and \"suspensful\" time."
    }), "\n", _jsx(_components.p, {
      children: "Developers have long awaited this feature-packed release, which takes Suspense and Concurrent Rendering out of beta, and are now stable for developers to use."
    }), "\n", _jsx(_components.p, {
      children: "Fortunately, the API has remained relatively stable, except for two main changes:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsxs(_components.li, {
        children: ["the ", _jsx(_components.code, {
          children: "React.FC"
        }), " interface has changed, and the ", _jsx(_components.code, {
          children: "children"
        }), " property is no longer part of it; this means that we had to apply a different interface to most components"]
      }), "\n", _jsxs(_components.li, {
        children: ["the hook ", _jsx(_components.code, {
          children: "useEffect"
        }), " now runs twice to spot memory leaks"]
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "Makerkit is now compatible with the changes above, and you can use it with React 18 for developing your next SaaS."
    }), "\n", _jsxs(_components.h3, {
      id: "introducing-reactfcc",
      children: [_jsx(_components.a, {
        "aria-hidden": "true",
        tabIndex: "-1",
        href: "#introducing-reactfcc",
        children: _jsx(_components.span, {
          className: "icon icon-link"
        })
      }), "Introducing React.FCC"]
    }), "\n", _jsxs(_components.p, {
      children: ["As someone who quite liked the ", _jsx(_components.code, {
        children: "React.FC"
      }), " interface, I was slightly bummed by the decision to change it."]
    }), "\n", _jsxs(_components.p, {
      children: ["As a result, I introduced a new interface, which reflects the old ", _jsx(_components.code, {
        children: "React.FC"
      }), ":"]
    }), "\n", _jsx(_components.pre, {
      children: _jsxs(_components.code, {
        className: "hljs language-tsx",
        children: [_jsx(_components.span, {
          className: "hljs-keyword",
          children: "declare"
        }), " ", _jsx(_components.span, {
          className: "hljs-variable hljs-language",
          children: "module"
        }), " ", _jsx(_components.span, {
          className: "hljs-string",
          children: "'react'"
        }), " {\n  ", _jsx(_components.span, {
          className: "hljs-keyword",
          children: "type"
        }), " ", _jsx(_components.span, {
          className: "hljs-variable hljs-constant",
          children: "FCC"
        }), "<", _jsx(_components.span, {
          className: "hljs-title hljs-class",
          children: "Props"
        }), " = ", _jsx(_components.span, {
          className: "hljs-title hljs-class",
          children: "Record"
        }), "<", _jsx(_components.span, {
          className: "hljs-built_in",
          children: "string"
        }), ", unknown>> = ", _jsx(_components.span, {
          className: "hljs-title hljs-class",
          children: "React"
        }), ".", _jsx(_components.span, {
          className: "hljs-property",
          children: "FC"
        }), "<", _jsx(_components.span, {
          className: "hljs-title hljs-class",
          children: "React"
        }), ".", _jsx(_components.span, {
          className: "hljs-property",
          children: "PropsWithChildren"
        }), "<", _jsx(_components.span, {
          className: "hljs-title hljs-class",
          children: "Props"
        }), ">>;\n}\n\n", _jsx(_components.span, {
          className: "hljs-keyword",
          children: "const"
        }), " ", _jsx(_components.span, {
          className: "hljs-title hljs-class",
          children: "MyComponentWithChildren"
        }), ": ", _jsx(_components.span, {
          className: "hljs-title hljs-class",
          children: "React"
        }), ".", _jsx(_components.span, {
          className: "hljs-property",
          children: "FCC"
        }), "<{\n    ", _jsx(_components.span, {
          className: "hljs-attr",
          children: "body"
        }), ": ", _jsx(_components.span, {
          className: "hljs-built_in",
          children: "string"
        }), ";\n}> = ", _jsxs(_components.span, {
          className: "hljs-function",
          children: ["(", _jsx(_components.span, {
            className: "hljs-params",
            children: "{ body, children }"
          }), ") =>"]
        }), " {\n    ", _jsx(_components.span, {
          className: "hljs-comment",
          children: "//..."
        }), "\n};\n"]
      })
    }), "\n", _jsx(_components.p, {
      children: "It can be read as React Functional Component with Children."
    }), "\n", _jsxs(_components.h3, {
      id: "what-about-suspense",
      children: [_jsx(_components.a, {
        "aria-hidden": "true",
        tabIndex: "-1",
        href: "#what-about-suspense",
        children: _jsx(_components.span, {
          className: "icon icon-link"
        })
      }), "What about Suspense?"]
    }), "\n", _jsx(_components.p, {
      children: "While Suspense is now stable, Makerkit hasn't yet adopted it, but it's very\nhigh on our list before our final version is out."
    }), "\n", _jsxs(_components.h3, {
      id: "packages-update",
      children: [_jsx(_components.a, {
        "aria-hidden": "true",
        tabIndex: "-1",
        href: "#packages-update",
        children: _jsx(_components.span, {
          className: "icon icon-link"
        })
      }), "Packages Update"]
    }), "\n", _jsx(_components.p, {
      children: "Nearly all the packages got a version bump:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "Pino was updated to the recently released version 8"
      }), "\n", _jsx(_components.li, {
        children: "Stripe as update to version 9.6.0"
      }), "\n", _jsx(_components.li, {
        children: "Cypress was updated to version 10"
      }), "\n", _jsx(_components.li, {
        children: "Many, many minor bumps to all the packages"
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "We're working hard towards a stable release. Stay tuned :)"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


Changelog


I'm excited to announce that Makerkit is adding support for Multi-Factor Authentication (MFA) the Supabase kits. This is a sneak peek to our coming feature.

## What is MFA?

Multi-Factor Authentication (MFA) is a method of authentication that requires more than one piece of evidence to verify the user's identity. It is a way to add an extra layer of security for your users' accounts.

## Should you add MFA to your app?

If you're building an app that requires a high level of security, then you should definitely consider adding MFA to your app. For example, if you're building an app that requires users to manage their finances, then you should definitely add MFA to your app.

Your users will feel more secure knowing that their accounts are protected by MFA, and it can be a potential differentiator for your app. I don't see a reason not to offer this functionality to your users.

## How does MFA work?

Supabase allows us to use TOPT (Time-based One-time Password) to generate a one-time password (OTP) that the user can use to login to their account using their second authentication factor.

## Supabase MFA in Practice

### Step 1. Users will enroll an authentication factor (e.g. Google Authenticator)

The first step for your users is to enroll a new authentication factor using an Authenticator app (such as Google Authenticator or Authy).

1. The first thing they are required to do is to specify a name for their new authentication factor: Supabase supports up to 10 factors (more than enough for sure!). This name will be used to identify the authentication factor in the Authenticator app, and will help users remember which factor they are using.
2. Then, they're required to scan the QR code with the authenticator app. This will generate a secret key that will be used to generate the OTP.
3. After confirming the one-time code generated by the authenticator app, the user will be able to use their new authentication factor to login to their account.

<Video src="/assets/images/posts/mfa-setup.mp4" />

### Step 2. Users will login to their account using their email and password

After logging in, we will check if users have enrolled any MFA factor. According to Supabase, this rarely uses the network and it's a very fast check. After logging in using the first authentication factor, the users' assurance level is `aal1`.

If users are required to use MFA, then we will redirect them to the MFA page. This page will prompt them to select a factor: for example, a factor enrolled using a work smartphone. If only one factor is enrolled, then it will be automatically selected.

Then, they will be required to enter the OTP generated by the authenticator app for that factor. If the OTP is correct, then the user will be logged in to their account. Their assurance level is upgraded to `aal2`.

<Video src="/assets/images/posts/mfa-verify.mp4" />

## Conclusion

I'm excited to add this feature to our kits. I think it's a great way to add an extra layer of security to your app. I hope you enjoyed this sneak peek to our coming feature. If you have any questions, feel free to reach out on our Discord server.

Announcing support for Multi-Factor Authentication (MFA) with Supabase


As you may have seen, we are working on a new SaaS kit based on Supabase and Next.js 13 using React Server Components and the new app directory. We are excited to share a behind-the-scenes look at how we built the kit.

## A quick recap: what is a SaaS kit?

Makerkit's kits are a collection of templates that you can use to build your own SaaS products. 

The goal of the kits is to provide the building blocks that you need to build your own SaaS product and to help you get started quickly, such as a landing page, authentication, Stripe payments, emails, multi-tenancy architecture based on organizations, user invites, and more.

The kits are built using the latest technologies and are designed to be easy to customize and extend to fit your needs.

## The Supabase and Next.js RSC SaaS kit

The Supabase and Next.js RSC SaaS kit is a new kit that we are working on. It is based on Supabase, Next.js 13 React Server Components and the new app directory.

### A rewrite of the Supabase and Remix SaaS kit

It's mostly a rewrite of the Supabase and Remix SaaS kit so the two kits are very similar. While competing, the two frameworks are extremely similar, and the migration was mostly a matter of changing the framework-specific code.

In short, both frameworks are great and you can't go wrong with either one. It's important to remember that while Remix is production-ready, (at the time of writing) the Next.js app directory is still in beta.

### The Next.js app directory is in beta

Therefore, this kit is going to be a beta kit as well until the Next.js app directory is out of beta.

## Enter React Server Components

The most striking difference that you will find in the new kit is the use of React Server Components. 

The new Next.js app directory leverages React Server Components by default: Server components are rendered on the server and then sent to the client as a serialized stream. 

What the above means is that the client can render the component **without having to download the JavaScript bundle**: as you can imagine, this allows Next.js to deliver a much faster initial page load.

### Did you notice performance gains?

Generally speaking, yes. 

But the performance gains don't come for free: your components need to be written in a way that allows them to be rendered on the server, which means they will mostly be data-fetching and rendering components, and no interactivity. 

Interactive components (client components) will be rendered using SSR and hydrate on the client just like you're used to the traditional Next.js `/pages` directory.

When you're able to write your components in a way that allows them to be rendered on the server, combined with carefully written `laoding.tsx` loading handlers, you can **take advantage of the performance gains** that server components unlock and provide a **much smoother user experience** than possible today.

## The new Next.js app directory

The new Makerkit app directory will look like the following tree:

```
- app
  - (app)
    - components
    - dashboard
      - page.tsx
    - settings
      - organization
        - page.tsx
      - profile
        - page.tsx
      - subscription
        - page.tsx
    - layout.tsx
    - loading.tsx
  - (site)
    - about
      - page.tsx
    - faq
      - page.tsx
    - pricing
      - page.tsx
    - layout.tsx
    - loading.tsx
    - page.tsx
  - api
    - organizations
      - route.ts
    - stripe
      - checkout
        - route.ts
  - auth
    - components
    - password-reset
      - page.tsx
    - sign-in
      - page.tsx
    - sign-up
      - page.tsx
    - layout.tsx
    - loading.tsx
  - invite
    - [code]
    - components
    - layout.tsx
  - onboarding
    - page.tsx
  - components.css
  - globals.css
  - layout.tsx
  - loading.tsx
```

If you're not familiar with the Next.js app directory, here is a quick overview:

- pages are defined using the special filename `page.tsx`
- layouts are defined using the special filename `layout.tsx`
- loading handlers are defined using the special filename `loading.tsx`
- directories will create a new route, for example, `app/dashboard` will create the route `/app/dashboard`
- directories using parenthesis are "pathless", .e.g. `(app)` will not create the route `/app`, but will start from the root of the app directory, for example, `(app)/dashboard` will create the route `/dashboard`. The same goes for `(site)`

### Pathless directories

Pathless directories are useful for defining routes that are not part of your app: for example, the `(site)` directory is used to define the routes for your landing page, pricing page, and more. Instead, the `app` directory is used to define the routes for your app, i.e. the ones behind authentication.

### Data-Fetching Layouts

What makes these particularly useful is the fact we can define data-fetching layouts that can fetch the data that is common to the pages in the directory: for example, it may not be useful to fetch the current organization in the `site` pages, but it is useful to fetch the current organization in the `app` pages.

Or, for example, we want to ensure that logged-in users can't access the `auth` pages, but we don't want to do the same for the `app` pages. By using layouts in such a way that we can control both data-fetching and authentication, we can write our pages in a way that is more declarative and easier to reason about.

## Co-locating components

Another interesting feature of the Next.js app directory is the ability to co-locate components with your pages. As you can see, we define the directory `components` close to where they're used, such as near the `auth` pages. 

In this way, we can easily see which components are used by which pages, and we can easily move them around if we need to.

Given we have `shared` components, we can also define a `components` directory at the root of the app directory, which will be shared across all pages.

## The good parts of the Next.js app directory

The Next.js app directory is a great way to organize your Next.js app. In fact, I quite enjoyed the experience of using it. 

### Layouts

Layouts allow us to define components that wrap your pages and provide a consistent look and feel across your app.

Additionally, layouts also help you to fetch data that is common to all pages in your app, such as the current user, the current organization, and more.

#### Data loading

We can use Layouts for fetching data that is common to all pages in its directory. For example, we can fetch the current user in the `auth` directory, and we can fetch the current organization in the `app` directory, and so on.

In Makerkit, we define "data loaders" such as `loadAppData` and `loadAuthData` that are used to fetch the data that is common to all pages in the `app` and `auth` directories, respectively.

These also perform some validation such as ensuring that the user is authenticated and that the user is part of the organization, and so on. In such cases, we define a `redirect` property that tells the layouts not to proceed and redirect somewhere instead.

Let's see the loader for the authentication pages:

```tsx
import getSupabaseServerClient from '~/core/supabase/server-client';
import configuration from '~/configuration';

const loadAuthPageData = async () => {
  try {
    const client = getSupabaseServerClient();

    const {
      data: { session },
    } = await client.auth.getSession();

    if (session) {
      return {
        redirect: true,
        destination: configuration.paths.appHome,
      };
    }

    return {};
  } catch (e) {
    return {};
  }
};

export default loadAuthPageData;
```

Now, let's use the loader above in the `auth` layout:

```tsx
import { use } from 'react';
import { redirect } from 'next/navigation';

import loadAuthPageData from '~/lib/server/loaders/load-auth-page-data';
import Logo from '~/core/ui/Logo';
import I18nProvider from '~/i18n/I18nProvider';

function AuthLayout({ children }: React.PropsWithChildren) {
  const data = use(loadAuthPageData());

  if ('redirect' in data && data.destination) {
    return redirect(data.destination);
  }

  return (
    <I18nProvider>
      <div
        className={
          'flex h-screen flex-col items-center justify-center space-y-4 md:space-y-8 lg:bg-gray-50 dark:lg:bg-black-700'
        }
      >
        <div>
          <Logo />

          {children}
        </div>
      </div>
    </I18nProvider>
  );
}

export default AuthLayout;
```

As you can see, we:
1. fetch the data
2. if the data contains a `redirect` property, we redirect to the destination (for example, when the user is already logged in)
3. otherwise, we render the children (such as the sign-in page, etc.)

The other layouts will work in a very similar way.

### The new Next.js Route handlers

Next.js has also released an alternative way to define API routes, using the new Route handlers. This new API is still experimental and will replace the "old" `pages/api` API handlers.

Let's take a quick look at the new API handlers. We have added a new directory called `api` that contains the API handlers. To define a route, we create a directory within `api` and create a file called `route.ts`.

For example, we create a route handler for the `/api/stripe/checkout` route:

```tsx filename=app/api/stripe/checkout/route.ts
export async function POST(
  req: Request
) {
  const payload = await req.text();

  /// handle webhook here

  return NextResponse.json({
    success: true,
  });
}
```

As you can see we can define the method handlers by simply exporting the method name using its uppercase form. For example, we can define a `GET` handler by exporting a `GET` function.

```tsx
export async function GET(
  req: Request
) {
  const data = await getData();

  return NextResponse.json(data);
}
```

While I have created a folder named `api` which looks a lot like the `pages/api` directory, it is important to notice that you can co-locate API handlers with your pages, for example, you can create a `checkout` directory in the `app` directory and create a `route.ts` file there and execute a request against the `/app/checkout` route.

In my opinion, it can still be useful to define API handlers in a separate directory, such as the `api` directory, as it allows you to define API handlers that are not part of your app, such as the `stripe` API handlers. This is just my preference at this time, and it can likely change in the future.

## Difficulties with the Next.js app directory

While everything has been generally smooth, there have been a few difficulties with the Next.js app directory.

### i18n

At this time, the biggest difficulty with the Next.js app directory has been i18n using `i18next`. I have been able to get it working, but it has been a bit of a struggle. 

The examples online are either lacking or simply don't work, and I have had to spend a lot of time trying to figure out how to get them working.

### Mutations

Next.js is still working on mutations, which will likely allow us to define mutations in the same way we define API handlers, and automatically refresh the loaders when the mutations are executed, similar to how Remix works.

To work it around for the time being, mutations are executed using fetch requests wrapped with `useMutation` from `swr`, and manually calling `router.refresh` when the mutation succeeds. Ideally, we will be able to remove the `router.refresh` call once mutations are supported.

## Conclusion

The Next.js Supabase SaaS kit is slated to be released in March, and I am very excited about it. Do you have any questions about the kit? Let me know! 

If you want, sign up for the newsletter to be notified when the kit is released.

Ciao!

A sneak peek at the Supabase and Next.js RSC SaaS kit


Originally, Makerkit was built using Headless UI, a set of headless components built by the Tailwind team.

It was a great choice for a project like Makerkit, as it allowed us to build a UI library that was completely customizable, and that could be used in any project.

However, as Makerkit grew, we started to notice some limitations with Headless UI, highlighted by the fact many members of the community were asking for more components or to use Radix UI instead.

As a result, we decided to migrate Makerkit to Radix UI, a set of React UI components built the Modulz team, now at Work OS.

## Why Radix UI?

[Radix UI](https://radix-ui.com) is a rich headless UI library that comes with many primitive components by default, with a strong focus on accessibility and usability. Additionally, it plays well with Tailwind CSS, which is a big plus for us.

Many of the components we added are an adaption of the [Shadcn UI kit](https://ui.shadcn.com/): a set of React UI components that are pre-styled with Tailwind CSS. If are planning on adding more components, I recommend you check it out.

## What's new?

The new components added are:

- Dialog
- Dropdown
- Tooltip

As a result, we also removed some libraries such as Tippy, since no longer needed.

## Preview

Below is a quick preview of some of the components we added to the Makerkit kits.

### Select

Here is a preview of the new Select component - as shown in the Makerkit's Organizations selector:

<Video src="/assets/images/posts/radix-select-example.mp4" />

### Tooltip

We've removed Tippy in favor of the Tooltip component from Radix UI:

<Video src="/assets/images/posts/radix-tooltip-example.mp4" />

### Dialog

The new Radix dialog behaves similarly to the previous one, but it's more customizable and has a better look and feel:

<Video src="/assets/images/posts/radix-dialog-example.mp4" />

### Other components

Now that we're using Radix UI, you can easily add more components to the library.

Install the library that you need and use the primitives using Radix UI, then follow the same conventions for decorating the primitives with Tailwind CSS.

## Credits: Shad CN UI Template

A big thanks to [Shad CN](https://twitter.com/shadcn) for creating the [UI Template](https://ui.shadcn.com/) that we used as a base for the new components and adapted to the Makerkit look-and-feel.

My recommendation to clients wanting to build new components using Radix UI is to check out the UI Template, as it's a great starting point for decorating the Radix primitives using Tailwind CSS and re-exporting them.

Makerkit ❤️ Radix UI


I am super happy to announce the new design for the Makerkit subscriptions pages. This includes both a new dynamic pricing table and a much-improved subscription management page.

In this blog post, I want to introduce the new design and explain why we made the changes shipped today.

## The new pricing table

The new pricing table introduces the ability to have multiple plans with multiple variations. For example, you could have 3 different plans (Basic, Pro and Enterprise), each with a monthly or an annual price.

<Image src='/assets/images/posts/pricing-table.webp' width="2832" height="1884" />

The dynamic variant switcher will automatically show the prices for the selected variant.

### Configuring the plans

Below is how to configure the new Makerkit's configuration for Stripe:

```ts
stripe: {
  products: [
    {
      name: 'Basic',
      description: 'Description of your Basic plan',
      badge: `Up to 20 users`,
      features: [
        'Basic Reporting',
        'Up to 20 users',
        '1GB for each user',
        'Chat Support',
      ],
      plans: [
        {
          name: 'Monthly',
          price: '$9',
          stripePriceId: 'basic-plan-mth',
          trialPeriodDays: 0,
        },
        {
          name: 'Yearly',
          price: '$90',
          stripePriceId: 'basic-plan-yr',
          trialPeriodDays: 0,
        },
      ],
    },
    {
      name: 'Pro',
      badge: `Most Popular`,
      recommended: true,
      description: 'Description of your Pro plan',
      features: [
        'Advanced Reporting',
        'Up to 50 users',
        '5GB for each user',
        'Chat and Phone Support',
      ],
      plans: [
        {
          name: 'Monthly',
          price: '$29',
          stripePriceId: 'pro-plan-mth',
          trialPeriodDays: 0,
        },
        {
          name: 'Yearly',
          price: '$200',
          stripePriceId: 'pro-plan-yr',
          trialPeriodDays: 0,
        },
      ],
    },
    {
      name: 'Premium',
      description: 'Description of your Premium plan',
      badge: ``,
      features: [
        'Advanced Reporting',
        'Unlimited users',
        '50GB for each user',
        'Account Manager',
      ],
      plans: [
        {
          name: '',
          price: 'Contact us',
          stripePriceId: '',
          trialPeriodDays: 0,
          label: `Contact us`,
          href: `/contact`,
        },
      ],
    },
  ],
}
```

There are various options available, such as:

1. Adding a custom label using the `label` property in each plan. Useful, for example, if you want to add a "Contact us" button instead of a "Checkout" button.
2. Adding a custom link using the `href` property in each plan. Useful, for example, if you want to link to a contact form instead of a checkout page.

## The new subscription management page

The new subscription management page is a much-improved version of the previous one. 

It now includes a much better overview of the current subscription. Thanks to granular labels and descriptions, you can now show the exact state of the subscription.

Furthermore, we simplified the plan selector by reusing the same pricing table used on the pricing page.

### Plan selector

The old plan selector has been removed. Instead, we now use the pricing table from the pricing page. This makes it easier to understand the different plans and variants when picking a plan from within the subscription management page.

<Image src='/assets/images/posts/plan-selector.webp' width="2832" height="2024" />

### Subscription Status

The subscription status has been improved to show the exact state of the subscription. This includes the current plan, the current status, the next billing date, and whether the subscription is set to be renewed automatically.

Furthermore, unless the subscription is active, users will now see a badge in the top-right corner of the page to indicate the current status of their subscription.

<Image src='/assets/images/posts/subscription-status.webp' width="2844" height="2024" />


## Conclusion

I am super excited about the new design for the Makerkit subscription pages. I hope you like it as much as I do. 

If you have any questions or feedback, please let me know!


Changelog: New Stripe Subscriptions Pages


## A quick retrospective on 2022

2022 has been particularly busy: I released two kits based on Next.js/Remix and Firebase, and am about to release a third based on Remix and Supabase. Additionally, I wrote over 60 blog posts for this website and dozens of documentation pages for the kits.

While it started out as a side project mostly for fun, Makerkit is now used by over 60 customers, many of which I support directly: **I cannot thank you enough for your support and feedback**.

## A plan for 2023

Next year, I have fairly big plans for Makerkit. 

From a product perspective, I plan to focus on the following:

1. **Upgrading the Next.js kit to the app directory**: this is a big change, but will make the kit even better and faster
2. **More kits**: I plan to release a kit based on Next.js/Remix and Supabase. After having completed the combos Next.js/Remix/Firebase/Supabase, I want to release kits for other technologies, such as **React Native** and a **Shopify App Kit**.
3. **Shopify Storefront**: Once Shopify Hydrogen is ready, I'd like to release an eCommerce template for storefronts. Since I'm familiar with Remix these days, I'm hoping it to be super fun.
4. **More blog posts**: I plan to write more blog posts about the kits, and the technologies I use. I feel like the greatest value I can provide is by sharing my knowledge and experience with others, which alongside the kit, can help you build your own products.
5. **More documentation**: I plan to write more documentation for the kits. Too many kits often assume that you know how to use the technologies they're built on, which is not always the case. I want to make sure that the kits are accessible to everyone, and that you can build your own products with them.

## Courses?

I've been thinking about releasing a few courses on Makerkit or building a SaaS in general, but I'm not sure where to start. 

I'd love to hear your thoughts on this.

## A micro SaaS?

Of course, I'd also love to release a few micro SaaS so that I can validate the kits and ensure I dogfood every template I build: this is the only way I can ensure that the kits are the best possible products they can be.

## And you?

What about you? What are your plans for 2023? 

Send me a message on Twitter or Discord, I'd love to hear from you! 😊

Planning Makerkit's 2023


We are excited to announce the Makerkit UI Storybook. This is a collection of all the components that make up the Makerkit UI. You can use this to see how the components work and to get inspiration for your own projects.

## What is Storybook?

Storybook is an open source tool for developing UI components in isolation, which can improve component reuse, testability, and development speed. It allows you to browse a component library, view the different states of each component, and interactively develop and test components.

## Where can I find the Makerkit UI Storybook?

You can find the Makerkit UI Storybook at [https://ui.makerkit.dev](https://ui.makerkit.dev).

It still early days for the Makerkit UI, so I am
working hard on writing more documentation and examples so to help you use
the Makerkit components in your projects.

If you have any suggestions for components you would like to see, please let us know in the Makerkit Discord.

## What will you be working on next?

My goals for the Makerkit UI are to:
- providing a more consistent and accessible UI for all the kits
- document all the components and how to use them in a better way, and I do
think the Storybook will greatly help with this
- break more components into many smaller components, so that they can be
used in more places and be more flexible
- ultimately, adding more components to the Makerkit UI, so to be a
standalone UI kit

## Conclusion

I hope the Makerkit UI Storybook can be helpful in its current state already.
If you have any questions or suggestions, please let us know in the Makerkit Discord.

Ciao!


Introducing the Makerkit UI Storybook


The React Team has finally released React 18 after a long and "suspensful" time.

Developers have long awaited this feature-packed release, which takes Suspense and Concurrent Rendering out of beta, and are now stable for developers to use.

Fortunately, the API has remained relatively stable, except for two main changes:

- the `React.FC` interface has changed, and the `children` property is no longer part of it; this means that we had to apply a different interface to most components
- the hook `useEffect` now runs twice to spot memory leaks

Makerkit is now compatible with the changes above, and you can use it with React 18 for developing your next SaaS.

### Introducing React.FCC

As someone who quite liked the `React.FC` interface, I was slightly bummed by the decision to change it.

As a result, I introduced a new interface, which reflects the old `React.FC`:

```tsx
declare module 'react' {
  type FCC<Props = Record<string, unknown>> = React.FC<React.PropsWithChildren<Props>>;
}

const MyComponentWithChildren: React.FCC<{
    body: string;
}> = ({ body, children }) => {
    //...
};
```

It can be read as React Functional Component with Children.

### What about Suspense?

While Suspense is now stable, Makerkit hasn't yet adopted it, but it's very
high on our list before our final version is out.

### Packages Update

Nearly all the packages got a version bump:
 - Pino was updated to the recently released version 8
 - Stripe as update to version 9.6.0
 - Cypress was updated to version 10
 - Many, many minor bumps to all the packages

We're working hard towards a stable release. Stay tuned :)


Makerkit upgraded to React 18

React 18 has been released, and with it many exciting features.

Introducing React.FCC

What about Suspense?

Packages Update

Stay informed with our latest resources for building a SaaS

Read more about
Changelog

Announcing support for Multi-Factor Authentication (MFA) with Supabase

A sneak peek at the Supabase and Next.js RSC SaaS kit

Makerkit ❤️ Radix UI

Changelog: New Stripe Subscriptions Pages

Planning Makerkit's 2023

Introducing the Makerkit UI Storybook

Makerkit upgraded to React 18

React 18 has been released, and with it many exciting features.

Introducing React.FCC

What about Suspense?

Packages Update

Stay informed with our latest resources for building a SaaS

Read more about Changelog

Announcing support for Multi-Factor Authentication (MFA) with Supabase

A sneak peek at the Supabase and Next.js RSC SaaS kit

Makerkit ❤️ Radix UI

Changelog: New Stripe Subscriptions Pages

Planning Makerkit's 2023

Introducing the Makerkit UI Storybook

Read more about
Changelog