Creative Tim UI

repository·main·Indexed 11 days ago

https://github.com/creativetimofficial/ui

A component library built on top of shadcn/ui, providing pre-built, customizable React components and blocks for modern web applications. It features a dedicated CLI for installing components as source code, a system for managing active themes via ActiveThemeProvider and useThemeConfig, and specialized blocks for Application UI, Marketing, Ecommerce, and Web 3.0.

Tokens
19.9K
Snippets
75
Records
99
Agent score
95%

What's inside Creative Tim UI

  1. Explore Creative Tim UI Blocks

    main

    Creative Tim UI provides ready-to-use, customizable blocks organized by use case. These can be added to your project to quickly build complex sections.

    Available categories include:

    • Application UI: Modals, Account, Billing
    • Marketing: Testimonial Sections, Contact Sections, Footers, FAQs, Blog
    • Ecommerce UI: Product listings, shopping carts, and checkout flows
    • Web 3.0: Sections for decentralized applications and blockchain projects
  2. Capabilities of the Creative Tim UI Skill

    main

    Once the creative-tim-ui skill is installed, your AI agent gains the following capabilities:

    • Block Discovery & Installation: The agent can discover and install any of the 390+ available blocks using the command npx @creative-tim/ui@latest add <block>.
    • Design Adherence: The agent follows Creative Tim's design philosophy (minimalism, the 95% rule, and deliberate restraint) and applies correct design rules including brand colors, typography scales, and Tailwind v4 constraints.
    • PRO Access: The agent can set up access to PRO blocks using the CREATIVE_TIM_UI_API_KEY environment variable.
    • Primitive Composition: The agent knows how to correctly compose shadcn/ui primitives without attempting to reimplement them.
  3. What is the Creative Tim UI Registry?

    main
    The Creative Tim UI registry is a centralized catalog system designed for CLI-based component installation, following the shadcn/ui pattern. Instead of installing components as immutable external npm dependencies, the registry delivers component source code directly into your project. This allows for full customization, as the components become part of your own codebase.
  4. How the Registry works during installation

    main

    When you execute an installation command via the CLI, the following lifecycle occurs:

    1. Fetches Component Metadata: The CLI retrieves the component definition from a registry JSON endpoint.
    2. Downloads Dependencies: It identifies and installs any required npm packages (such as Radix UI).
    3. Copies Source Files: The actual component files are placed directly into your local codebase.
    4. Manages Imports: The CLI automatically configures path aliases and imports to ensure the component works immediately.
  5. Apply the 95% Rule to UI development

    main

    Focus on solving the most common use cases (the 95%) exceptionally well rather than over-engineering for rare specializations (the 5%). Common elements include buttons, tables, cards, sidebars, charts, forms, modals, and notifications.

    Avoid complex abstractions for simple problems. A developer should be able to modify a component (like changing a label) without unwrapping multiple layers of abstraction. Use direct, obvious, and complete implementations for common tasks.

    // WRONG — solves a hypothetical future problem with excessive abstraction
    <DataTable
      columns={columns}
      data={data}
      sortable
      filterable
      paginated
      exportable
      selectable
      onRowClick={handleRowClick}
      onSelectionChange={handleSelection}
      renderCustomCell={(cell) => <CustomCell {...cell} />}
    />
    
    // RIGHT — solves the actual problem using direct, composable primitives
    <Table>
      <TableHeader>...</TableHeader>
      <TableBody>
        {items.map((item) => (
          <TableRow key={item.id}>
            <TableCell>{item.name}</TableCell>
            <TableCell>{item.status}</TableCell>
          </TableRow>
        ))}
      </TableBody>
    </Table>
  6. Ensure Hydration Safety in SSR

    main

    To prevent hydration mismatches in Next.js or other SSR frameworks, follow these rules when using Creative Tim UI components:

    • Avoid Dynamic Values in Initial State: Never use new Date(), Date.now(), or toLocaleTimeString() inside useState initializers.
    • Pattern: Use static or hardcoded strings for the initial state to ensure the server and client render the same content. Transition to live, dynamic values inside a useEffect hook or a setInterval after the component has mounted.
  7. Creative Tim UI Design Rules and Brand Identity

    main

    When customizing or generating blocks, adhere to these core design principles to maintain brand consistency:

    Brand Colors

    • Primary Accent: Use orange-500 or orange-600.
    • Avoid: Never use violet, purple, or indigo as accent colors (these are associated with default AI generation).
    • Neutral Surfaces: Use slate, gray, or zinc.
    • Status Colors: emerald (success), amber (warning), red (error), blue (info).

    Typography

    • Body Content: Use text-sm for labels, descriptions, table cells, and list items.
    • Small Text (text-xs): Reserved for avatar initials, font-mono timestamps, badge pills, sidebar group headers (with uppercase + tracking-wider), and tiny action buttons.
    • Constraint: Never use arbitrary font sizes like text-[10px] or text-[11px].

    Tailwind v4 Constraints

    • No Arbitrary Values: Use the numeric scale for spacing and sizing (e.g., h-8, w-12, gap-3, p-4). Avoid h-[32px].
    • Standard Fractions: Use max-w-sm, max-w-2xl, or w-1/2 instead of max-w-[85%].
    • Responsive Breakpoints: Use standard prefixes (sm:, md:, lg:, xl:) instead of arbitrary media queries.

    Component Patterns

    • Grouping: Prefer Card > CardHeader + CardContent.
    • KPI/Stat Cards: Use CardContent className="px-4 py-0" (specifically py-0 instead of the default py-6).
    • Overflow: Use ScrollArea for lists that may overflow.
    • Sidebar: Use w-64, border-r, and bg-muted/30.
    • Styles: Avoid inline style={{}} objects; always use Tailwind classes.
  8. Follow Surface and Border conventions

    main

    To maintain visual hierarchy and theme compatibility, follow these conventions for backgrounds, borders, and text:

    • Sidebar / subtle backgrounds: Use bg-muted/30.
    • Card backgrounds: Use the default bg-background (the Card component handles this automatically).
    • Borders: Always use the border theme token. Never use hardcoded colors like border-gray-200.
    • Text: Use text-foreground for primary text and text-muted-foreground for secondary text or captions.
  9. Apply the "Light" Principle to component design

    main

    A component or block is considered "done" when there is nothing left to remove. Minimize cognitive and technical weight by avoiding unnecessary additions.

    Guidelines for "Light" design:

    • Do not use feature flags or configuration props for things that can be changed directly in code.
    • Avoid helper components that are only used once.
    • Do not add animations unless they are necessary to communicate state.
    • Avoid extra wrapper divs that do not serve a functional purpose.
    • Do not use icons that merely repeat information already provided by text.
    • Do not include empty, loading, or error states unless the block is actively fetching data.
    // WRONG — wrapping for the sake of wrapping
    <SectionWrapper>
      <ContentContainer>
        <InnerContent>
          <Card>...</Card>
        </InnerContent>
      </ContentContainer>
    </SectionWrapper>
    
    // RIGHT — as flat as the problem allows
    <Card>...</Card>
  10. How Creative Tim UI components integrate into your project

    main

    Unlike traditional UI libraries that are installed as locked dependencies in node_modules, Creative Tim UI components are integrated directly into your project as source code.

    This architecture provides several advantages:

    • Complete Control: Since the code lives in your codebase, you can modify, extend, or refactor the component logic and styles directly.
    • Customization: You are not limited by the props provided by a package; you can change the underlying implementation to match your specific design or functional requirements.
    • No Dependency Lock-in: You avoid the constraints of external package versions for the UI elements you use.