<Contents>

1. [What is HOC in React?](#what-is-hoc-in-react)
2. [Practicing with a HOC in React](#practicing-with-a-hoc-in-react)
- [Writing our First HOC Wrapper for Auth](#writing-our-first-hoc-wrapper-for-auth)
- [First HOC Variation with Passing Props to the Downstream](#first-hoc-variation-with-passing-props-to-the-downstream)
- [Second HOC Variation with Passing 'Nothing'](#second-hoc-variation-with-passing-nothing)
- [HOC Implementation on our React Components](#hoc-implementation-on-our-react-components)

3. [Scaling up the HOC Implementations](#scaling-up-the-hoc-implementations)
4. [Execution Order of the HOCs](#execution-order-of-the-hocs)
5. [Interconnected React HOCs](#interconnected-react-hocs)
6. [Conclusion](#conclusion)

</Contents>

I always wondered that *why the official react dev has removed the part of HOCs from it's documentation* until I seek and found the answer in it's [legacy docs](https://legacy.reactjs.org/docs/higher-order-components.html):
> [id=warning] 'Higher-order components are not commonly used in modern React code' — official react dev

Now, we can only access the [legacy docs](https://legacy.reactjs.org/docs/higher-order-components.html) to view it but sadly with it's old but gold obsolete class syntax.

 [W3schools ](https://www.w3schools.com/react/react_hoc.asp)is another alternative(with only 1 example which is insufficient to grasp things) alongside the indie blogs. So far, I've seen that the given portion of the contents wasn't included, whether in typescript or in a concrete deep dive.

Just because of my curiosity, I've gone through and grasp every use case of React HOCs, every potential replacement for HOCs, every tricks to remove the unnecessary workarounds for the app that might be a good fit for HOCs. I assure you, you're going to have A LOT of takeaways by the end of this article and maybe refute the claim of react docs(see above) — who knows? 

## What is HOC in React?

Concretely, "**a higher-order component is a function that takes a component and returns a new component"** says the legacy docs. When we apply a HOC to a component, though, the original component is wrapped with a dedicated container component. 

The HOCs are commonly used for:

- Authentication
- Validation
- Redirection
- Database Queries/Actions

Pretty much everything on the server. But I'd like to encourage you to use it widely not only on the server side but the client side as well. Add it on your checklist I addressed about that later on as well.

## Practicing with a HOC in React

When it comes to using a HOC with typescript, everything slightly changes due to the nature of `.tsx` syntax. I want you to never forget the first rule I understood so far — ***We always need to consider of the given and taken props.***

### Writing our First HOC Wrapper for Auth 

The most basic way to digest underlying behavior of the HOCs passes throughout the very common usage scenario of the HOC which is the authorization. Suppose that we're working on this directory inside a latest version of Next.js/React app:

```javascript
app/
├── layout.tsx
├── page.tsx
├── profile
│ └── [userId] // dynamic slug 
│ └── page.tsx
└── post
 └── [postId] // dynamic slug 
 └── page.tsx 
.
.
```

Assuming we haven't utilized the HOC and have written our own validation logic for the auth manually. Thus, the `post/[postId]/page.tsx` component roughly would have looked like this:

```javascript
// post/[postId]/page.tsx

interface Props extends PageProps<"/post/[postId]"> {}
 
export default async function PostPage({ params }: Props) {
 const userSession = await getUserSession(); 
 if (!userSession.ok || !userSession.data) return forbidden();
   
  const { session, user } = userSession.data;
  if (!session || !user) return notFound();

 const postId = (await params).postId; 
 if(!validatePost(postId)) return notFound();
 
 return <Post postId={postId} />;
}
```

Messy.. Especially if you have abstracted stuffs in your codebase. 

Of course you can write a server function that handles all these stuff externally where it's simply being passed to each page component to do the same thing, it's also an alternative. 

In this scenario, *the primary goal of the HOCs would be preventing iterations over the same logic for other components* where`postId`is being consumed. It's quite overwhelming though to write the same logic. 
> [id=success] **Use it with caution**: If your app doesn't scale, meaning the logic above **does not** repeat itself across your app components, **the HOC might be an overhead rather than a solution**. Assess the overall amount of required fields by checking your codebase and detecting the components that shares the same logic. Make your decision only after that for a proper React HOC replacement. 

So instead, we can create a wrapper HOC function encapsulating the inner logic to not repeat ourselves by respecting the [DRY principle](https://en.wikipedia.org/wiki/Don't_repeat_yourself). 

### **First HOC Variation with Passing Props to the Downstream**

Below, we have a complete HOC to handle the auth logic when working with our React components and beyond that, we're passing the props to whatever the wrapped component is. 

```javascript
// src/hocs/withAuth.tsx
import "server-only"

export interface WithAuthProps {
 session: AuthSession;
 user: AuthUser;
}

export function withAuth(
 Component: (props: P & WithAuthProps) => Promise<React.ReactNode>,
) {
 return async (props: P): Promise<React.ReactNode> => {
 const res = await getUserSession();

 // internal failure runtime check
 if (!res.ok) throw new Error("Session lookup failed.");
 
 // return 403 HTTP code — new but experimental Next.js API 
 if (!res.data) forbidden();
 
 const { session, user } = res.data;

 if (!session || !user) forbidden(); // or notFound()
 
 return <Component {...props as P} session={session} user={user} />;
 }
}
```

Breaking the logic down:	

 `P extends object` ensures that **we only allow any kind of prop that is object** otherwise warn the user back at compile time about that. Since a React component doesn't work with primitives other than object, we will be justified with the extending method of the generic type. 

The wrapped component's signature forces **every consumer of `withAuth` to declare `session` and `user` as accepted props**. The typescript will automatically infer it's type at the call site which is a huge plus.

***

Don't let the auth HOC know about the resource(the part where we defined object in the type above) **unless you strictly need an abstracted dedicated layer**.
> [id=warning] **Takeaway:** `withAuth`has no business validating `postId`. Auth answers "is this actor allowed to make a request at all?" resource validation answers "does this specific resource exist or is it in a valid state?" Fusing them means every new component that needs auth *and* has its own validation rule (`validatePost`, `validateComment`, whatever comes next) forces us to either fork the HOC or bolt conditional logic onto it defeating the DRY goal we started with... We don't want that, do you want? I don't want.

### **Second HOC Variation with Passing 'Nothing'**

In this time we simply won't pass anything and keep the rest context as-is.

```javascript
// src/hocs/withAuth.tsx
import "server-only"

export function withAuth(
 Component: (props: P) => Promise<React.ReactNode>,
) {
 return async (props: P): Promise<React.ReactNode> => {
 const res = await getUserSession();

 // internal failure runtime check
 if (!res.ok) throw new Error("Session lookup failed.");
 
 // return 403 HTTP code — new but experimental Next.js API 
 if (!res.data) forbidden();
 
 const { session, user } = res.data;

 if (!session || !user) forbidden(); // or notFound()
 
 return <Component {...props} />; // return the component as-is
 }
}
```

I don't think that I need to break down things like I did for the first variation and it's pretty much the same steps except passing and inferring the props of wrapped component. 

Better to see how it's implemented over the components.

### HOC Implementation on our React Components

The most common pattern to use the HOC in our components (in my case it's a page comp.) is to **define it outside of the exported component:** 

```typescript
// implementing the first HOC variation

interface Props extends PageProps<"/post/[postId]"> {}

const GuardedPost = withAuth(
 async ({ postId, session, user }: Awaited<Props["params"]>) => 
 !(await validatePost(postId)) 
 ? notFound() 
 : <Post postId={postId} session={session} user={user} />;
);

export default async function PostPage({ params }: Props) {
 const { postId } = await params;
 return <GuardedPost postId={postId} />;
}
```

We could definitely move the validation logic right inside the `Post` component because now it looks annoying and awkward I know sorry about that 😅 

Let's clean it up and assume the post component is a server component where the `validatePost()` does it's job inside of the `<Post />` component:

```javascript
interface Props extends PageProps<"/post/[postId]"> {}

const GuardedPost = withAuth(Post);

export default async function PostPage({ params }: Props) {
 const { postId } = await params;
 return <GuardedPost postId={postId} />;
}
```

We can achieve that by simply extending the post props with the HOC type that we wrote earlier:

```javascript
interface PostProps extends WithAuthProps {
 postId: PostId,
} 
```

Apparently huge difference compared to the given very first example that doesn't scale.

## Scaling up the HOC Implementations

Now we're about the see extensive usage(one of my favorite one) of the HOCs. I told you that HOCs are highly scalable. To prove that lets add one more layer to our logic. 

I guess a role based access control(RBAC) logic is a perfect candidate to append in this stuff as we're working on the posts so we're going to need to check either it's an admin or editor.

Considering the second variation of the HOC that passes nothing to the wrapper component, similarly we can create one more HOC called `withRole` that doesn't depend on anything:

```javascript
// src/hocs/withRole.tsx
import "server-only"

export function withRole(
 Component: (props: P) => Promise<React.ReactNode>,
) {
 return async (props: P): Promise<React.ReactNode> => {
 const userRole = await getUserRole();
 
 // every user has to have a role therefore it's an internal error
 if (!userRole) throw new Error("User role lookup failed.");

 const isGranted = await checkUserRole();
 if (!isGranted) forbidden(); // or notFound()
 
 return <Component {...props} />; // return the component as-is
 }
}
```

No dependency, no undergoing props, pure component. The only point that has to be written with caution is the **first returned react node type** wrapped with `Promise`: 

```javascript
Component: (props: P) => Promise<React.ReactNode>
```
 
This type represents characteristics of our wrapped function. If it's a client component therefore we can turn it into:

```javascript
Component: (props: P) => React.ReactNode
```

If we don't know the returned component or basically doesn't care we can create a generic type allowing the returned node to be client or server like this: 

```javascript
// in types.ts
export type ServerRenderable = (props: P) => ReactNode | Promise<ReactNode>;

// then in src/hocs/withRole.tsx

Component: ServerRenderable
```

> [id='error'] **The second remains unchanged nevertheless** as it's belong the internal HOC component and running an async function.

Finally, the implementation of `withRole` inside our page component:

```javascript
interface Props extends PageProps<"/post/[postId]"> {}

const GuardedPost = withAuth(withRole(Post));

export default async function PostPage({ params }: Props) {
 const { postId } = await params;
 return <GuardedPost postId={postId} />;
}
```

It's ridiculously simple to attach it into React components. 

## Execution Order of the HOCs

**The execution order always starts from the outermost wrapper HOC and slightly moves to the right side of the line.** 

Speaking of the latest version of our HOC component, let's extend it with one more HOC to illustrate the communication better:

```javascript
interface Props extends PageProps<"/post/[postId]"> {}

const GuardedPost = withAuth(withRole(withAnalytics(Post)));

export default async function PostPage({ params }: Props) {
 const { postId } = await params;
 return <GuardedPost postId={postId} />;
}
```

In this case, `withAuth` runs first, `withRole` second, `withAnalytics` third and the `Post` last.

![React HOC Execution Order Diagram](https://ytpmpkgcjlcdidphswzv.supabase.co/storage/v1/object/public/banner/react-hoc-execution-order-174e3421.webp)


The order never changes always from outermost to innermost. We could even simplify it an make it more readable by adding **a composer.** Like this: 

```javascript
const Gated = compose(
 withAuth,
 withRole,
 withAnalytics
)(async () => {
 // render post
}); 
```

***

## Interconnected React HOCs

An additional detail that might be worth to share with you folks is that we worked on HOCs which doesn't share anything among themselves. Each remains standalone, unaware of whatever happens on the wrapped component, only responsible to validate and return. 

There's another scenario where the HOCs shares data to each other. In that case, we must remember what I have said the beginning:
> [id='success'] ***We always need to consider of the given and taken props.***

`withRole` and `withAuth` extended only `object` and passed the fetched variable arbitrarily to the wrapped component. Realistically, `withAuth` would not have needed a prop inherently but I can't say the same for `withRole`. In a real app, it should get a parameter say `userId` then derive something from it or use it directly in a DB function. 

In this particular scenario, we have to change parameters of `withRole` roughly something to this:

```javascript
export function withRole(requiredRole: Role) {
 return (Component: (props: P & WithAuthProps) => ReactNode | Promise<ReactNode>) => {
 return async function RoleGuarded(props: P & WithAuthProps): Promise<ReactNode> {
 const { userId } = props;
 const role = await getUserRole(userId);

 if (!role) throw new Error(`Role lookup failed for user: ${userId}`);
 if (role !== requiredRole) forbidden();

 return <Component {...props} />;
 };
 };
}
```

## Conclusion

HOCs aren't a pattern you reach for by default yet they're a pattern you *arrive* at, once the same auth check, role check, or tracking snippet starts showing up in one too many files. That repetition is the actual signal to look for, not "HOCs are best practice.". And folks, remember the outermost HOC always runs first. This was the {title} 

Thanks for reading 👋 

I got to sleep it's 4.32 PM.

In this article we're going to have a look at the HOC in practice, not only the Server-Side but also the Client-Side React patterns.

The Complete Guide to Higher-Order Components in Next.js React With Typescript

The hidden gem behind the React query is revealed. Take a gigantic dive into the traditional ways of data fetching vs newfangled ways where the term "query" is mentioned. 

Is React(tanstack) Query Too Biased? Deep dive: Real Life Data Fetching Practices — Chapter 1

Master advanced TypeScript patterns: Learn discriminated unions for precise type narrowing and generic types for building scalable, type-safe systems with practical RBAC examples and custom utility implementations.

TypeScript Discriminated Unions and Generics: Complete Guide with Examples

I always thought that using our own custom solutions over the ready ones is not necessary but genuine idea because we face with an unknown in other words **real challenge.** I used to write my articles using [Obsidian](https://obsidian.md/) and manually update the DB so far. 

It turns out actively using this app to write and manage my technical articles. Just like this one 😅

Check out the [Github repo](https://github.com/Masculinn/blog-editor) for the source code. 

<Contents>

1. [Introduction](#introduction)
2. [Motivation](#motivation)
3. [Architecture](#architecture)
4. [Installation](#installation)
- [1\. Requirements](#1-requirements)
- [2\. Database Configuration](#2-database-configuration)
- [3\. Environment Configuration](#3-environment-configuration)
- [4\. Database Types](#4-database-types)
- [5\. Running the App](#5-running-the-app)

5. [Tidy Up The Repo — important](#tidy-up-the-repo--important)
6. [Usage \& Writing Your First Article](#usage--writing-your-first-article)
- [Important Note for Unix\-Based OS Developers](#important-note-for-unix-based-os-developers)
- [Command Center \& Shortcuts](#command-center--shortcuts)

7. [Contributing](#contributing)
8. [Acknowledgements](#acknowledgements)

</Contents>

## Introduction 

The **open-source Ultimate Blog Editor App** brings together the Markdown editing experience of [Obsidian](https://obsidian.md/) and the publishing flexibility of [Substack](https://substack.com/) in a single workspace.

*The stack doesn't cost a penny.* [*Supabase* ](https://supabase.com/)*and* [*Netlify*](https://www.netlify.com/) *free plans are suitable. It won't let you down halfway through even at scale.* 

That said, it comes with amazing features listed down below:
 
- **Rich-Text Editing**
- **Blazing Fast Editing**
- **Markdown Editing Mode**
- **MDX Content Viewer**
- **Dynamic Error Display for Compiled MDX Source** 
- **Media Library** 
- **Image Optimization (converting primary formats to `.webp`)**
- **Extensive Autocomplete In English** 
- **Custom Content Components (including charts from `recharts`)**
- **Command Center**
- **50+ Predefined Eye Soothing Backgrounds**
- **Draft & Post Management**
- **Document Serialization and Compression**
- **URL-Based Document State**
- **Comprehensive Keyboard Shortcuts With Full Accessibility Support**
- **Dialogs, Sheets, Shared Controls**
- **Feedback and Cloud Syncing**
- **Backend Integration**

**This project is primarily tailored for my personal use**, but it is also intended to serve as a reference for others interested in the editor architecture and development of editor features. It's so easy to change the serialized custom components and allowing you to curate them as you wish. 

![App features collection](https://ytpmpkgcjlcdidphswzv.supabase.co/storage/v1/object/public/banner/blog-editor-thumb-98412b75.webp)


***


It serve as a starting point for building custom editor apps with its highly modular architecture and extensibility. Just like a puzzle box, it can be customized to fit your needs.

| tech | version |
| --- | --- |
| Next.js | ≥16 |
| React / React DOM | >19 |
| TypeScript | ≥5.0 |
| Lexical | ≥0.49.0 |
| Supabase JS | ≥2.112.3 |
| Tailwind CSS | ≥4.0.0 |
| shadcn | ≥4.19.0 |
| Base UI | ≥1.7.0 |
| next-mdx-remote-client | ≥2.1.12 |
| React Hook Form | ≥7.87.0 |
| Zod | ≥4.5.4 |


## Motivation

Of course, those who rely on others' solutions rather than coming up with their own in 2026 are not fools or timid. What I mean is that whatever [Substack](https://substack.com/) or [Obsidian](https://obsidian.md/) provides is maybe convenient enough for you. 

Therefore you might not end up with going further, it's totally up to you. 

*As far as I am concerned, these techs don't meet my expectations on their own, but would meet them if they were combined, if you're the one looking from the same window like me then you've come to the right place.*


## Architecture

The app follows a modular architecture that separates editing, document previews, and content management into dedicated feature areas. Shared UI components, an extensible Lexical editor, and centralized server actions keep the code organized and make it easier to maintain and expand. Respected to DRY principles heavily.

- **Admin entry point(mainland):** `app/(admin)/admin/page.tsx` provides the admin route, with access-control logic organized in `proxy.ts` and `lib/auth.ts`.
- **Feature modules:** `features/` separates the editor, document viewer, and management tools for drafts, posts, and the media library.
- **Extensible editor:** `components/editor/` organizes Lexical nodes, plugins, extensions, toolbars, and Markdown transformers. Charts and Contents have dedicated modules for editing, rendering, and conversion.
- **MDX rendering:** `components/mdx/` defines content components and processing plugins, while `lib/mdx/` handles serialization and related error handling.
- **Server and DB layer:** `app/actions/` groups content operations, supported by the server database client in `lib/db/` and generated database types in `types/`.
- **State and validation:** `store/document.store.ts` holds document state, `providers/tools-provider.tsx` supplies shared tool context, and `schema/` defines draft validation.
- **Shared interface:** `components/ui/`, reusable modals, and `hooks/` provide consistent controls, dialogs, keyboard shortcuts, and URL parameter handling.

The working tree is pretty straightforward and scalable with it's modular design: 

```javascript
src/
├── app/
│ ├── (admin)/admin/ # Entry point
│ └── actions/ # Server-side content operations
├── features/
│ ├── editor/ # Editor workspace
│ ├── document-viewer/ # Content preview
│ └── tools/ # Drafts, posts, and media management
├── components/
│ ├── editor/ # Lexical nodes, plugins, and extensions
│ ├── mdx/ # MDX rendering components
│ └── ui/ # Shared interface components
├── lib/ # Auth, database, and serialization
├── store/ # Document state
├── providers/ # Shared tool context
├── hooks/ # Reusable React hooks
├── hoc/ # Content and metadata wrappers
├── schema/ # Validation schemas
├── types/ # Application and database types
├── constants/ # Tool and editor configuration
├── utils/ # Supporting utilities
└── proxy.ts # Request interception 
```

## Installation

### 1. Requirements

You will need:
- Node.js >= 22
- npm

Clone the repository:
```javascript
git clone https://github.com/Masculinn/blog-editor.git
cd blog-editor
```

Install dependencies:
```javascript
npm install
```

> [id=warning] **⚠️ CAUTION: Before continuing further you must configure the DB layer. Do not attempt running the dev server unless all the database environments and tables are configured properly. See instructions below to be able to start the dev server.** 


***

### 2. Database Configuration

Visit [Supabase auth page ](https://supabase.com/dashboard/sign-up)to signup or if you have already an account simply login. Create a new organization and choose your own namespace. After that, create a table called 
`blog_posts` and paste the given [PostgreSQL ](https://www.postgresql.org/)snippet below into the SQL Editor section placed in the sidebar of your dashboard. 
 
This will create our very first table for our articles.

```javascript
create table public.blog_posts (
  id serial not null,
  title text not null default 'title'::text,
  content text not null,
  tags text[] not null,
  published_at timestamp with time zone null default now(),
  description text not null default 'I AM JOHN DOE BUT CANT PROVE IT'::text,
  banner_image text not null default 'MY_DEFAULT_IMAGE_URL'::text,
  level numeric not null default '1'::numeric,
  constraint blog_posts_pkey primary key (id),
  constraint blog_posts_level_check check ((level > (0)::numeric))
) TABLESPACE pg_default;
```

> After configuring the DB and ensuring everything is stable, you can curate the predefined tables however you want. 

Next, we need the secondary table for our article candidates that isn't actually ready to be considered under the category of posts. I call it **draft.** 

Paste the given snippet below to create **draft** table into the SQL Editor as well.

```javascript
create table public.drafts (
  id serial not null,
  title text not null default 'title'::text,
  content text null default 'The quick brown fox jumps over the lazy dog.'::text,
  tags text[] null,
  published_at timestamp with time zone null default now(),
  description text null,
  banner_image text null,
  level numeric not null default '1'::numeric,
  constraint drafts_pkey primary key (id),
  constraint drafts_level_check check ((level > (0)::numeric))
) TABLESPACE pg_default;
```
> These tables are almost identical. The only difference is the partially defined columns, which are in response to the separation of concerns principle.

Finally, we're one step away to be done on DB configuration which is creating a bucket called **banner**. To do that, move into the *storage page* via dashboard > sidebar and create a new bucket called **banner**.

![storage-tutorial](https://ytpmpkgcjlcdidphswzv.supabase.co/storage/v1/object/public/banner/screenshot-2026-09-07-000037-9c56f442.webp)

I'm currently using my bucket publicly because I treat my bucket as an external CDN point for my media elements in my site — idc how unsafe it is so if you think that things in it must remain private then you can leave the toggle state as-is like the one showed above.

### 3. Environment Configuration

Create a brand new env file called `.env` at the root of your project and get the corresponding values of your env keys from project settings of your Supabase organization.

```javascript
SUPABASE_URL=YOUR_PROJECT_URI
SUPABASE_SERVICE_ROLE_KEY=YOUR_SERVICE_ROLE_KEY

APP_TOKEN=YOUT_BASE64_APP_TOKEN
```

After obtaining your DB tokens, replace the placeholder above and only if you do consider to deploy the app to the production, set `APP_TOKEN` to `base64` formatted hash. [You can visit this ](https://it-tools.tech/token-generator)site to generate one in seconds. 

### 4. Database Types

The app uses the typegen for DB types for in particular for React actions. Everything in the `package.json` file is configured for you to invoke codegen but before doing so, you must login to your Supabase account via CLI

Run the CLI command to login your account in your IDE.

```javascript
npx supabase login 
```

This is going to open up a new window inside of your browser to SSO. Follow the instructions given in the CLI to login then run the following command to fetch the DB types

```javascript
npm run db:types
```

### 5. Running the App

Start the development server:
```javascript
npm run dev
```

The current development script starts Next.js on port `36805`:
```javascript
http://localhost:36805
```

That's pretty much everything so far to run the app on locally, it takes max 5 minutes from scratch, I think it's fair. 

## Usage & Writing Your First Article


#### Important Note for Unix-Based OS Developers

It's worth to mention that the **Unix**-based users like mac or linux OS a bit differs in particular scenarios such as key bindings. If you're the one, you may want to configure the app shortcuts in a way that the modifier key `meta` handles the shortcut over `Control` because initially it's defined to `Control` — yes, I'm a windows user.

Simply find the components in your IDE search with a match for the hook imported as:

```javascript
import { useKeyboardShortcut } from "@/hooks/use-keyboard-shortcut";
```

And configure like:

```javascript
  useKeyboardShortcut(
    ["Meta", "/"],
    () => {
     /* INTERNAL CALLBACK */
    },
  ); 
```

***

### Command Center & Shortcuts

> Consider `Ctrl` as `Meta` please Linux & Mac folks

Press `Ctrl + K` to toggle the Command Center, even while editing. Search for a tool, navigate with `↑` / `↓`, and press `Enter` to open its modal. Selecting a tool automatically closes the Command Center.


| Shortcut | Action |
| --- | --- |
| `Ctrl + K` | Toggle the Command Center |
| `↑` / `↓` | Navigate tools |
| `Enter` | Open the selected tool |
| `Esc` | Dismiss the active dialog |
Available tools: **View Posts**, **View Drafts**, **Create Draft**, **Media Library**, **Manage Drafts**, and **Manage Posts**.

| Shortcut | Purpose |
| --- | --- |
| `Ctrl + M` | Toggle between rich-text editing and Markdown mode. |
| `Ctrl + /` | Show or hide the document viewer. Requires a selected post or draft. |
| `Ctrl + S` | Save content changes to the selected draft or post while the document viewer is mounted. |
***

If you'd like to publish the posts powered by SSG render power in Next.js Pages router that maximizes your SEO by god knows how many times, you can [take a look at my blog app's Github Repo ](https://github.com/Masculinn/burakdev/blob/main/src/pages/blogs/%5Bslug%5D.tsx)to inspire by. 

## Contributing

Contributions are welcome! Open an issue to report a bug, suggest a feature, or discuss a significant change before starting.
1. Fork the repository and create a branch for your changes.
2. Install dependencies with `npm install`.
3. Start the development server with `npm run dev`.
4. Make your changes, keeping them focused and consistent with the existing architecture.
5. Run `npm run check` and `npm run build` before submitting.
6. Open a pull request describing the changes, any related issues, and how you tested 
7. them. Include screenshots for UI updates.

Keep credentials and environment files out of your commits.

## Acknowledgements

Huge thanks to [this repo ](https://github.com/htmujahid/shadcn-editor)and its hard-working contributors for allowing me to curate their Shadcn Editor! Lovely set of backgrounds are also scraped from [patterns craft](https://patterncraft.fun/) definitely worth to add in your checklist.

A writing and publishing workspace built with Lexical and Supabase, combining rich-text editing, Markdown mode, and on demand pre-compiled MDX previews.

justc0de_sessions