BetaUnder active development — content may be incomplete or change without notice.

Naming Conventions

Consistent naming keeps your block library scalable, predictable, and easy to navigate. As your project grows, following these conventions helps avoid conflicts and makes blocks easier to reuse.

Block Files

When you add a block in Blok0, it includes only two essential files:

FilePurpose
config.tsDefines the Payload CMS block configuration (admin fields)
component.tsxReact component used to render the block

Blok0 may include additional files like previews.tsx or documentation.mdx internally, but you do not need to copy them into your project.

Folder Structure

To keep your blocks organized, group them by category:

src/blocks/
├── heros/
│   ├── hero-1/
│   │   ├── config.ts
│   │   └── component.tsx
│   └── hero-2/
│       ├── config.ts
│       └── component.tsx
├── features/
│   └── feature-1/
│       ├── config.ts
│       └── component.tsx

Rules

  • Block folder name: kebab-case → hero-1, feature-2
  • Category folder name: plural + kebab-case → heros, features, faqs

This structure ensures clarity and scales cleanly as more blocks are added.

Code Naming

Blok0 uses consistent naming patterns so you can infer names without checking documentation.

ElementPatternExample
Config export[Name]Config (PascalCase)Hero1Config
Config slug[name]Config (camelCase)hero1Config
Interface name[Name]Type (PascalCase)Hero1Type
Component[Name]Component (PascalCase)Hero1Component

Notes

  • Slug (hero1Config) → used internally by Payload (blockType)
  • Interface (Hero1Type) → TypeScript type definition
  • Component name → React convention (PascalCase)

Example

For a block named Hero 1:

// config.ts
export const Hero1Config: Block = {
  slug: 'hero1Config',
  interfaceName: 'Hero1Type',
  // ...
}
// component.tsx
export default function Hero1Component(props: Hero1Type) {
  return <div>{/* ... */}</div>
}

Block Numbering

Blocks in the same category are separate implementations, not variants.

  • hero-1 ≠ hero-2
  • Each has its own layout, fields, and component

Why numbers?

Using numbers instead of descriptive names:

  • Avoids long, subjective naming (hero-horizontal-large-image)
  • Keeps naming short and consistent
  • Sorts naturally

Variations

Visual variations (e.g., with/without image, different CTAs) are handled within a block, not by creating new block names.

Third-Party Block Prefixes (Planned)

Blok0 will support third-party block sources using prefixes:

  • ace-hero-1 → Aceternity UI
  • mui-cta-1 → Magic UI

Benefits

  • Prevents naming conflicts
  • Clearly shows block origin
  • Keeps ecosystem organized

Summary

Blok0 naming is built around:

  • Consistency → predictable patterns
  • Scalability → works as your library grows
  • Clarity → easy to identify and use blocks

Stick to these conventions, and your block system will stay clean and maintainable.