Receber por email
← Voltar para o catálogo

scaffold-component

Scaffold a new React component with test file for the catalog UI.

34estrelas
Atualizado há 6 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add ea-toolkit/architecture-catalog

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/scaffold-component/svg)](https://www.skillteca.com.br/skills/scaffold-component)

Alerta por categoria

Receba novas skills de Design e Frontend toda segunda

1 email curto, só com as skills novas de Design e Frontend. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Scaffold Component

Scaffold a new React component in catalog-ui/src/components/ with a co-located test file.

Arguments

$ARGUMENTS should be a PascalCase component name (e.g., CapabilityHeatmap, DomainSummaryCard).

If no argument is provided, ask the user for a component name.

Workflow

  1. Parse component name from $ARGUMENTS. Ensure PascalCase.
  1. Determine target directory based on component purpose:
  2. Graph/visualization component → catalog-ui/src/components/graphs/
  3. Diagram viewer → catalog-ui/src/components/
  4. Layout/navigation → catalog-ui/src/components/ (or subdirectory if pattern exists)
  5. General → catalog-ui/src/components/
  6. Ask the user if unclear.
  1. Read existing context:
  2. Read models/registry-mapping.yaml if the component will render registry data.
  3. Read an existing similar component in the target directory for pattern reference.
  4. Read catalog-ui/src/lib/types.ts for TypeScript interfaces.
  1. Create component file (ComponentName.tsx):
  2. Export Props interface: export interface ComponentNameProps { ... }
  3. Named export (not default): export const ComponentName: React.FC<ComponentNameProps> = ...
  4. CSS via --ec-* variables (never inline styles)
  5. Semantic HTML (nav, main, section, article — not div for everything)
  6. Accessible: aria labels on interactive elements
  7. If rendering registry data: drive all behavior from schema properties (graph_rank, layer, icon), never from type name strings
  1. Create test file (ComponentName.test.tsx in same directory or __tests__/):
  2. At minimum: one render/smoke test + one behavioral test
  3. Use Vitest (import { describe, it, expect } from 'vitest')
  4. Mock external dependencies (ReactFlow, data loaders) if needed
  1. Verify types: cd catalog-ui && npx tsc --noEmit

Template Pattern

// ComponentName.tsx
import type React from 'react';

export interface ComponentNameProps {
  // Define props here
}

export const ComponentName: React.FC<ComponentNameProps> = (props) => {
  return (
    <section aria-label="Component description">
      {/* Component content */}
    </section>
  );
};
// ComponentName.test.tsx
import { describe, it, expect } from 'vitest';

describe('ComponentName', () => {
  it('should render without crashing', () => {
    // Render test
  });

  it('should handle user interaction', () => {
    // Behavioral test
  });
});

Rules

  • Follow the vocab-agnostic principle for core registry rendering (no type-name conditionals).
  • Map views (event, heatmap) are intentionally type-aware — that's fine.
  • No hardcoded display data — all data from props, config files, or data imports.
  • No !important in CSS unless overriding third-party styles.
Compartilhar X LinkedIn