blob: fc6fa582b70019de9baa20358201683d21a2964c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
Components
==========
Component Groups
----------------
.. list-table::
:header-rows: 1
:widths: 26 52
* - Area
- Files
* - Layout
- ``src/components/section.tsx``, ``src/components/sections``
* - Navigation
- ``src/components/active-link.tsx``, header menu and navbar files
* - Posts and tags
- ``src/components/posts/post-card.tsx``, ``src/components/tags``
* - Forms
- ``src/components/newsletter-form.tsx``, ``src/components/ui/form.tsx``
* - Auth
- ``src/components/auth/user-button.tsx``, ``user-avatar.tsx``
* - Rich text
- ``src/components/rich-text``
* - Base UI
- ``src/components/ui``
Component Rules
---------------
Use existing primitives first
Before creating a new component, check ``src/components/ui`` and existing
page components for a matching pattern.
Keep data access out of presentational components
Shared components should receive normalized props. Server components and
``src/lib`` helpers should handle data fetching.
Preserve accessibility names
Icon-only buttons and links need explicit labels. Existing tests cover some
components; extend tests when adding new interactive behavior.
Keep variants local and typed
Use existing ``class-variance-authority`` patterns for variant-heavy
controls instead of ad hoc class switches.
Testing
-------
Component tests live beside components using ``*.test.tsx`` or ``*.test.ts``.
Prefer focused tests that assert user-visible behavior, accessibility labels,
and variant output instead of implementation details.
|
