Skip to content

Add reusable UI components and refactor utilities for clarity#71

Open
pedrolucasvsr wants to merge 5 commits intomainfrom
feat/components
Open

Add reusable UI components and refactor utilities for clarity#71
pedrolucasvsr wants to merge 5 commits intomainfrom
feat/components

Conversation

@pedrolucasvsr
Copy link
Copy Markdown

Criação base do componentes reutilizáveis sem o design final

Introduce a set of reusable UI primitives and utilities: Button (with variants), Card (with variants), Container (with variants), SectionTitle (with variants), Navbar, Footer, FileExplorer/FileItem (with variants), ScrollIndicator (animated with framer-motion), and a central ui index export. Add a cn utility that composes clsx + tailwind-merge for safe Tailwind class merging. Update package.json to include class-variance-authority, clsx, framer-motion and tailwind-merge required by the new components.
Update UI components to use centralized cn util and add JSDoc-style component comments. Renamed lp-code/src/lib/utils/cn.ts -> lp-code/src/lib/cn.ts (with a brief docstring) and updated imports across Button, Card, Container, FileExplorer, FileItem, Footer, NavBar, ScrollIndicator, and SectionTitle. Removed scrollIndicator.variants.ts (deleted). Minor internal comments and small cleanup (forwardRef notes, animation/scroll comments) to improve clarity and maintainability.
@pedrolucasvsr pedrolucasvsr requested a review from oEnzoRibas March 7, 2026 13:29
@pedrolucasvsr pedrolucasvsr self-assigned this Mar 7, 2026
@pedrolucasvsr pedrolucasvsr linked an issue Mar 7, 2026 that may be closed by this pull request
@oEnzoRibas
Copy link
Copy Markdown
Member

oEnzoRibas commented Mar 7, 2026

Criação base do componentes reutilizáveis sem o design final

Recomendação: Coloque uma descrição mais detalhada do PR. Pode até usar o github Copilot.

image

Primeiro vem o título. Ele precisa resumir a mudança em uma frase curta e específica. Algo como “Add JWT authentication to login endpoint” comunica muito mais que “update backend”.

Depois entra o contexto ou problema. Aqui você explica por que o PR existe. Muitas vezes o código faz sentido apenas quando se entende o problema original: bug reportado, melhoria de performance, refatoração necessária, requisito novo, dívida técnica, etc.

Em seguida vem a descrição das mudanças. É a parte central. Você explica o que foi alterado no código: arquivos principais modificados, novas funcionalidades, refatorações, mudanças de arquitetura, endpoints criados ou removidos, alterações de dependências.

Depois aparece a justificativa técnica. Nem sempre é obrigatório, mas em mudanças mais complexas é importante explicar por que essa solução foi escolhida. Pode envolver trade-offs, decisões de arquitetura, bibliotecas escolhidas ou limitações do sistema.

Outro item importante é como testar. Aqui você explica passo a passo como alguém pode validar o PR: comandos para rodar

Copy link
Copy Markdown
Member

@oEnzoRibas oEnzoRibas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adiconar Testes com @testing-library/react para cada componente conforme exemplo feito como o component Button.

Ex: Button.test.tsx

import { render, screen } from "@testing-library/react"
import userEvent from "@testing-library/user-event"
import { describe, it, expect, vi } from "vitest"
import { Button } from "./Button"

describe("Button component",
() => {

    /**
     * Testa se o botão renderiza o texto corretamente
     * 
     *  */ 
    it("renders button text", () => {
        render(<Button>Click</Button>)

        const btn = screen.getByRole("button")

        expect(btn).toBeInTheDocument()
        expect(btn).toHaveTextContent("Click")
    })

    /**
     * Testa se a variante primária é aplicada por padrão
     */
    it("applies primary variant by default", () => {
    render(<Button>Click</Button>)

    const btn = screen.getByRole("button")

    expect(btn.className).toContain("bg-blue-600")
    })

    /**
     * Testa se a variante secundária é aplicada quando especificada
     */
    it("applies secondary variant", () => {
    render(<Button variant="secondary">Click</Button>)

    const btn = screen.getByRole("button")

    expect(btn.className).toContain("bg-gray-200")
    })

    /**
     * Testa se o evento onClick é disparado corretamente
     */
    it("fires onClick", async () => {
    const user = userEvent.setup()
    const handleClick = vi.fn()

    render(<Button onClick={handleClick}>Click</Button>)

    const btn = screen.getByRole("button")

    await user.click(btn)

    expect(handleClick).toHaveBeenCalledTimes(1)
    })

})

Também adicionar Documentação nos testes.

Para rodar os testes:

npx vitest

Add Vitest + React Testing Library unit tests for several UI components: Card, Container, FileExplorer, FileItem, Footer, NavBar, ScrollIndicator, and SectionTitle. Each test file checks basic rendering and common behaviors (children/prop rendering, role queries, presence of expected text, and container class application) to improve coverage and catch regressions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Componentes Reutilizáveis

2 participants