nextworks 0.1.0-alpha.2 → 0.1.0-alpha.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +29 -3
- package/dist/cli_manifests/auth_manifest.json +3 -1
- package/dist/cli_manifests/blocks_manifest.json +6 -6
- package/dist/cli_manifests/data_manifest.json +3 -2
- package/dist/cli_manifests/forms_manifest.json +5 -3
- package/dist/commands/blocks.d.ts +1 -0
- package/dist/commands/blocks.d.ts.map +1 -1
- package/dist/commands/blocks.js +77 -10
- package/dist/commands/blocks.js.map +1 -1
- package/dist/index.js +2 -0
- package/dist/index.js.map +1 -1
- package/dist/kits/auth-core/.nextworks/docs/AUTH_CORE_README.md +117 -0
- package/dist/kits/auth-core/.nextworks/docs/AUTH_QUICKSTART.md +244 -0
- package/dist/kits/blocks/.nextworks/docs/BLOCKS_QUICKSTART.md +193 -0
- package/dist/kits/blocks/.nextworks/docs/BLOCKS_README.md +65 -0
- package/dist/kits/blocks/.nextworks/docs/THEME_GUIDE.md +223 -0
- package/dist/kits/data/.nextworks/docs/DATA_QUICKSTART.md +112 -0
- package/dist/kits/data/.nextworks/docs/DATA_README.md +117 -0
- package/dist/kits/forms/.nextworks/docs/FORMS_QUICKSTART.md +84 -0
- package/dist/kits/forms/.nextworks/docs/FORMS_README.md +60 -0
- package/package.json +1 -1
|
@@ -0,0 +1,223 @@
|
|
|
1
|
+
# Theme System Guide
|
|
2
|
+
|
|
3
|
+
This file is shipped with the Nextworks Blocks kit and lives under `.nextworks/docs/THEME_GUIDE.md` in your project.
|
|
4
|
+
|
|
5
|
+
The content below is the canonical theme guide for projects using Nextworks Blocks.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
|
|
11
|
+
This project now includes a comprehensive theming system that allows you to easily switch between different color schemes and have all components automatically adapt.
|
|
12
|
+
|
|
13
|
+
## How to Use
|
|
14
|
+
|
|
15
|
+
### 1. Basic Setup
|
|
16
|
+
|
|
17
|
+
Your app is already configured with the enhanced theme provider in `app/layout.tsx`. The default theme is set to "monochrome".
|
|
18
|
+
|
|
19
|
+
### 2. Available Themes
|
|
20
|
+
|
|
21
|
+
- **Monochrome** - Clean black and white theme
|
|
22
|
+
- **Blue** - Professional blue color scheme
|
|
23
|
+
- **Green** - Fresh green color scheme
|
|
24
|
+
- **Purple** - Modern purple color scheme
|
|
25
|
+
- **Orange** - Vibrant orange color scheme
|
|
26
|
+
- **Default** - Standard shadCN theme
|
|
27
|
+
|
|
28
|
+
### 3. Using Theme-Aware Components
|
|
29
|
+
|
|
30
|
+
#### Navbar2 Component
|
|
31
|
+
|
|
32
|
+
```tsx
|
|
33
|
+
import { Navbar2 } from "@/components/sections/Navbar2";
|
|
34
|
+
|
|
35
|
+
<Navbar2
|
|
36
|
+
brand="My App"
|
|
37
|
+
brandNode={<YourLogoComponent />}
|
|
38
|
+
menuItems={[
|
|
39
|
+
{ label: "Home", href: "/" },
|
|
40
|
+
{ label: "About", href: "/about" },
|
|
41
|
+
]}
|
|
42
|
+
ctaButton={{ label: "Get Started", href: "/signup" }}
|
|
43
|
+
showThemeSelector={true}
|
|
44
|
+
/>;
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
#### Theme Selector
|
|
48
|
+
|
|
49
|
+
The `ThemeSelector` component is automatically included in Navbar2 and allows users to:
|
|
50
|
+
|
|
51
|
+
- Switch between theme variants (monochrome, blue, green, etc.)
|
|
52
|
+
- Toggle between light/dark modes
|
|
53
|
+
- Use system preference
|
|
54
|
+
|
|
55
|
+
### 4. Converting Existing Components
|
|
56
|
+
|
|
57
|
+
To make your existing components theme-aware, replace hardcoded colors with semantic classes:
|
|
58
|
+
|
|
59
|
+
#### Before (Hardcoded Colors):
|
|
60
|
+
|
|
61
|
+
```tsx
|
|
62
|
+
className = "bg-gray-50 dark:bg-gray-800 text-gray-800 dark:text-white";
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
#### After (Theme-Aware):
|
|
66
|
+
|
|
67
|
+
```tsx
|
|
68
|
+
className = "bg-background text-foreground";
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
#### Common Replacements:
|
|
72
|
+
|
|
73
|
+
- `text-gray-800 dark:text-white` → `text-foreground`
|
|
74
|
+
- `bg-gray-50 dark:bg-gray-800` → `bg-background`
|
|
75
|
+
- `border-gray-200 dark:border-gray-700` → `border-border`
|
|
76
|
+
- `hover:bg-gray-100 dark:hover:bg-gray-700` → `hover:bg-accent`
|
|
77
|
+
- `text-blue-600 dark:text-blue-500` → `text-primary`
|
|
78
|
+
|
|
79
|
+
### 5. Semantic Color Classes
|
|
80
|
+
|
|
81
|
+
Use these semantic classes for consistent theming:
|
|
82
|
+
|
|
83
|
+
- `text-primary` - Primary brand color
|
|
84
|
+
- `text-secondary` - Secondary text color
|
|
85
|
+
- `text-muted-foreground` - Muted text color
|
|
86
|
+
- `bg-background` - Main background color
|
|
87
|
+
- `bg-card` - Card background color
|
|
88
|
+
- `bg-accent` - Accent background color
|
|
89
|
+
- `border-border` - Border color
|
|
90
|
+
- `ring-ring` - Focus ring color
|
|
91
|
+
|
|
92
|
+
### 6. Creating Custom Themes
|
|
93
|
+
|
|
94
|
+
To create a custom theme, modify `lib/themes.ts`:
|
|
95
|
+
|
|
96
|
+
```ts
|
|
97
|
+
export const themes: Record<ThemeVariant, ThemeConfig> = {
|
|
98
|
+
// ... existing themes
|
|
99
|
+
myCustomTheme: {
|
|
100
|
+
name: "My Custom Theme",
|
|
101
|
+
colors: {
|
|
102
|
+
primary: "oklch(0.5 0.2 120)", // Custom green
|
|
103
|
+
primaryForeground: "oklch(0.98 0 0)",
|
|
104
|
+
// ... other colors
|
|
105
|
+
},
|
|
106
|
+
},
|
|
107
|
+
};
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
### 7. Example Usage
|
|
111
|
+
|
|
112
|
+
See the templates under `app/templates/*` and `lib/themes.ts` for concrete examples of how themes are wired up.
|
|
113
|
+
|
|
114
|
+
## Benefits
|
|
115
|
+
|
|
116
|
+
1. **Consistent Design**: All components automatically use the same color scheme
|
|
117
|
+
2. **Easy Customization**: Change the entire app's look by switching themes
|
|
118
|
+
3. **Accessibility**: Proper contrast ratios maintained across all themes
|
|
119
|
+
4. **Developer Experience**: No need to manually style each component
|
|
120
|
+
5. **User Choice**: Users can choose their preferred theme and light/dark mode
|
|
121
|
+
|
|
122
|
+
---
|
|
123
|
+
|
|
124
|
+
## Mixing tokens and local overrides
|
|
125
|
+
|
|
126
|
+
Sometimes you want the speed and consistency of the Color Theme (tokens), but still make template-specific tweaks. This project supports three patterns:
|
|
127
|
+
|
|
128
|
+
- Token-first: use semantic classes/variants everywhere (default behavior)
|
|
129
|
+
- Hybrid: keep tokens for most things and override specific slots/elements
|
|
130
|
+
- Full control: bypass tokens with unstyled primitives and fully custom classes
|
|
131
|
+
|
|
132
|
+
### 1) Prefer additive overrides first
|
|
133
|
+
|
|
134
|
+
- Keep variant/size from tokens and add className for small tweaks.
|
|
135
|
+
- Use component slot props for targeted overrides rather than global changes.
|
|
136
|
+
|
|
137
|
+
Example: override only mobile link hover background in the shared Navbar from a preset, leaving everything else token-based.
|
|
138
|
+
|
|
139
|
+
```tsx
|
|
140
|
+
// app/templates/productlaunch/components/Navbar.tsx
|
|
141
|
+
mobileLinks: {
|
|
142
|
+
className: "hover:bg-purple-50 dark:hover:bg-purple-900/20",
|
|
143
|
+
},
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
### 2) Override focus ring colors locally
|
|
147
|
+
|
|
148
|
+
Links in Navbar apply a token focus ring (`focus:ring-ring`). You can override it per preset by placing your ring utilities in `links.className` (these are merged last):
|
|
149
|
+
|
|
150
|
+
```tsx
|
|
151
|
+
// app/templates/productlaunch/components/Navbar.tsx
|
|
152
|
+
links: {
|
|
153
|
+
className:
|
|
154
|
+
"text-sm font-medium font-inter text-gray-800 dark:text-white hover:text-purple-700 dark:hover:text-purple-500 " +
|
|
155
|
+
"focus:ring-purple-500 dark:focus:ring-purple-400",
|
|
156
|
+
},
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
### 3) ThemeToggle with local styling
|
|
160
|
+
|
|
161
|
+
`ThemeToggle` accepts `buttonProps` that forward to the internal `Button`. For small tweaks, keep token variants and just add classes. For full control, use `unstyled: true` to bypass tokens:
|
|
162
|
+
|
|
163
|
+
```tsx
|
|
164
|
+
// app/templates/productlaunch/components/Navbar.tsx
|
|
165
|
+
themeToggle: {
|
|
166
|
+
buttonProps: {
|
|
167
|
+
unstyled: true,
|
|
168
|
+
className:
|
|
169
|
+
"size-9 p-0 flex items-center justify-center rounded-md border border-gray-200 " +
|
|
170
|
+
"bg-white text-gray-700 hover:bg-purple-50 hover:text-purple-700 " +
|
|
171
|
+
"dark:border-gray-800 dark:bg-gray-900 dark:text-gray-100 dark:hover:bg-purple-900/20 " +
|
|
172
|
+
"transition-colors focus:outline-none focus:ring-2 focus:ring-purple-500 dark:focus:ring-purple-400",
|
|
173
|
+
},
|
|
174
|
+
moonClassName: "text-gray-700 dark:text-gray-100",
|
|
175
|
+
sunClassName: "text-gray-700 dark:text-gray-100",
|
|
176
|
+
},
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
### 4) Unstyled escape hatch for primitives
|
|
180
|
+
|
|
181
|
+
Shared primitives like `Button` support an `unstyled` prop to bypass tokenized CVA classes and allow complete consumer control:
|
|
182
|
+
|
|
183
|
+
```tsx
|
|
184
|
+
// components/ui/button.tsx
|
|
185
|
+
<Button unstyled className="rounded-md bg-purple-600 px-3 py-2 text-white ...">
|
|
186
|
+
Click me
|
|
187
|
+
</Button>
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
Use this when a section must not be influenced by the global Color Theme.
|
|
191
|
+
|
|
192
|
+
### 5) Navbar accent via CSS variables (recommended for presets)
|
|
193
|
+
|
|
194
|
+
Set a small set of CSS variables on the Navbar root in your preset, and internal elements (ThemeToggle, mobile links, focus rings) will read them automatically with fallbacks to tokens.
|
|
195
|
+
|
|
196
|
+
Suggested variables:
|
|
197
|
+
|
|
198
|
+
- `--navbar-accent`: icon/text accent color
|
|
199
|
+
- `--navbar-hover-bg`: hover background color for toggle and mobile links
|
|
200
|
+
- `--navbar-toggle-bg`: default background for the theme toggle button
|
|
201
|
+
- `--navbar-ring`: focus ring color
|
|
202
|
+
- `--navbar-border`: border color for theme toggle and similar controls
|
|
203
|
+
|
|
204
|
+
Example in a preset:
|
|
205
|
+
|
|
206
|
+
```tsx
|
|
207
|
+
// app/templates/productlaunch/components/Navbar.tsx
|
|
208
|
+
nav: {
|
|
209
|
+
className:
|
|
210
|
+
"bg-white dark:bg-gray-900 text-gray-800 dark:text-white border-b border-gray-200 dark:border-gray-800 " +
|
|
211
|
+
"[--navbar-accent:theme(colors.purple.600)] dark:[--navbar-accent:theme(colors.purple.400)] " +
|
|
212
|
+
"[--navbar-hover-bg:theme(colors.purple.50)] dark:[--navbar-hover-bg:color-mix(in oklab,oklch(0.17 0.05 324) 20%, transparent)] " +
|
|
213
|
+
"[--navbar-ring:theme(colors.purple.500)] dark:[--navbar-ring:theme(colors.purple.400)]",
|
|
214
|
+
},
|
|
215
|
+
```
|
|
216
|
+
|
|
217
|
+
After setting these, you generally don’t need to pass `themeToggle` overrides; the toggle and links will align to your preset accent automatically.
|
|
218
|
+
|
|
219
|
+
Notes:
|
|
220
|
+
|
|
221
|
+
- Consumer `className` is merged last, so your overrides win when conflicts exist.
|
|
222
|
+
- Always include `dark:` variants when you override hover/focus to maintain dark mode parity.
|
|
223
|
+
- Scope overrides narrowly (slots/elements) to avoid surprising global changes.
|
|
@@ -0,0 +1,112 @@
|
|
|
1
|
+
# nextworks — Data kit quickstart
|
|
2
|
+
|
|
3
|
+
This document explains how to use the Data (crud) kit in the nextworks starter project.
|
|
4
|
+
|
|
5
|
+
Prerequisites
|
|
6
|
+
|
|
7
|
+
- A running PostgreSQL database and `DATABASE_URL` set in `.env`.
|
|
8
|
+
- Auth kit installed and configured (NextAuth + Prisma). The Data kit relies on NextAuth session for access control.
|
|
9
|
+
- In the monorepo, this is already wired up.
|
|
10
|
+
- In your own app via the CLI, the recommended alpha setup is to install Blocks (with sections + templates) + Auth Core + Forms first, then Data:
|
|
11
|
+
|
|
12
|
+
```bash
|
|
13
|
+
npx nextworks add blocks --sections --templates
|
|
14
|
+
npx nextworks add auth-core
|
|
15
|
+
npx nextworks add forms
|
|
16
|
+
npx nextworks add data
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
then follow the Prisma and `.env` steps below.
|
|
20
|
+
|
|
21
|
+
- Forms kit (optional but recommended) for form primitives.
|
|
22
|
+
|
|
23
|
+
Setup
|
|
24
|
+
|
|
25
|
+
1. Install dependencies and generate Prisma client:
|
|
26
|
+
|
|
27
|
+
npm install
|
|
28
|
+
npx prisma generate
|
|
29
|
+
|
|
30
|
+
2. Run migrations (creates User/Post tables):
|
|
31
|
+
|
|
32
|
+
Make sure you have merged the Auth + Data models into your `prisma/schema.prisma` before running migrations.
|
|
33
|
+
|
|
34
|
+
npx prisma migrate dev
|
|
35
|
+
|
|
36
|
+
3. Seed a demo admin user and posts locally (optional):
|
|
37
|
+
|
|
38
|
+
# Set env vars or use defaults
|
|
39
|
+
|
|
40
|
+
SEED_ADMIN_EMAIL=admin@example.com SEED_ADMIN_PASSWORD=password123 node ./scripts/seed-demo.mjs
|
|
41
|
+
|
|
42
|
+
4. Run the dev server:
|
|
43
|
+
|
|
44
|
+
npm run dev
|
|
45
|
+
|
|
46
|
+
Usage & testing
|
|
47
|
+
|
|
48
|
+
- Sign in at /auth/login using the seeded admin credentials (admin@example.com / password123).
|
|
49
|
+
- Visit /admin/posts to create/edit/delete posts. The UI supports pagination, search (title contains), and sort by createdAt.
|
|
50
|
+
- Visit /admin/users to view users (admin-only).
|
|
51
|
+
|
|
52
|
+
Notes
|
|
53
|
+
|
|
54
|
+
- Server-side RBAC: all modifying APIs (POST/PUT/DELETE) require a valid session, and user-level checks ensure only authors or admins can modify posts. The users list API requires admin access.
|
|
55
|
+
- Published flag: posts have a `published` boolean in Prisma. The admin UI exposes the published checkbox when creating or editing posts.
|
|
56
|
+
|
|
57
|
+
Troubleshooting
|
|
58
|
+
|
|
59
|
+
- If users list returns 403, ensure your signed-in user has role = 'admin'. You can promote a user with Prisma Studio or by running:
|
|
60
|
+
|
|
61
|
+
npx prisma db executeRaw "UPDATE \"User\" SET role = 'admin' WHERE email = 'admin@example.com';"
|
|
62
|
+
|
|
63
|
+
- If migrations fail, try:
|
|
64
|
+
|
|
65
|
+
npx prisma migrate reset
|
|
66
|
+
|
|
67
|
+
Files & kit manifest
|
|
68
|
+
|
|
69
|
+
If you plan to package a Data kit, here are the primary files, API routes and components used by the Data example flows. This manifest is intended to help packaging and documentation — adjust paths if you extract the kit into another project.
|
|
70
|
+
|
|
71
|
+
Files
|
|
72
|
+
|
|
73
|
+
- app/api/posts/route.ts
|
|
74
|
+
- app/api/posts/[id]/route.ts
|
|
75
|
+
- app/api/users/route.ts
|
|
76
|
+
- app/api/users/[id]/route.ts
|
|
77
|
+
- app/api/users/check-unique/route.ts
|
|
78
|
+
- app/api/users/check-email/route.ts
|
|
79
|
+
- app/api/seed-demo/route.ts
|
|
80
|
+
- app/api/signup/route.ts
|
|
81
|
+
- components/admin/admin-header.tsx
|
|
82
|
+
- components/admin/posts-manager.tsx
|
|
83
|
+
- components/admin/users-manager.tsx
|
|
84
|
+
- app/(protected)/admin/users/page.tsx
|
|
85
|
+
- app/(protected)/admin/posts/page.tsx
|
|
86
|
+
- app/examples/demo/create-post-form.tsx
|
|
87
|
+
- app/examples/demo/page.tsx
|
|
88
|
+
- lib/prisma.ts
|
|
89
|
+
- lib/server/result.ts
|
|
90
|
+
- lib/utils.ts
|
|
91
|
+
- lib/validation/forms.ts
|
|
92
|
+
- scripts/seed-demo.mjs
|
|
93
|
+
|
|
94
|
+
API routes (list)
|
|
95
|
+
|
|
96
|
+
- /api/posts (GET/POST) -> app/api/posts/route.ts
|
|
97
|
+
- /api/posts/:id (GET/PUT/DELETE) -> app/api/posts/[id]/route.ts
|
|
98
|
+
- /api/users (GET/POST) -> app/api/users/route.ts
|
|
99
|
+
- /api/users/:id (GET/PUT/DELETE) -> app/api/users/[id]/route.ts
|
|
100
|
+
- /api/users/check-unique -> app/api/users/check-unique/route.ts
|
|
101
|
+
- /api/users/check-email -> app/api/users/check-email/route.ts
|
|
102
|
+
- /api/seed-demo -> app/api/seed-demo/route.ts
|
|
103
|
+
- /api/signup -> app/api/signup/route.ts
|
|
104
|
+
|
|
105
|
+
Notes
|
|
106
|
+
|
|
107
|
+
- The Data kit relies on NextAuth sessions for access control — see lib/auth-helpers.ts and lib/auth.ts for server-side helpers and RBAC checks.
|
|
108
|
+
- The API routes return ApiResult envelope objects (see lib/server/result.ts) and the client uses lib/forms/map-errors.ts to map server validation errors into react-hook-form where appropriate.
|
|
109
|
+
|
|
110
|
+
Feedback
|
|
111
|
+
|
|
112
|
+
- File issues in the repo; note that CLI packaging for the Data kit is not yet implemented — this quickstart is for the repository as-is.
|
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
Data kit (cli/kits/data)
|
|
2
|
+
|
|
3
|
+
This kit provides a standalone example Data layer with Posts + Users CRUD: API routes, admin UI, Prisma helpers and a seed script. The kit is designed to be installed via the `nextworks` CLI:
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
npx nextworks add data
|
|
7
|
+
```
|
|
8
|
+
|
|
9
|
+
and is packaged with its own kit dependencies metadata.
|
|
10
|
+
|
|
11
|
+
> **Alpha note**
|
|
12
|
+
>
|
|
13
|
+
> In this early alpha, the Data kit is tested and supported on top of **Blocks** (with sections + templates), **Auth Core**, and **Forms**. For the smoothest experience, run:
|
|
14
|
+
>
|
|
15
|
+
> ```bash
|
|
16
|
+
> npx nextworks add blocks --sections --templates
|
|
17
|
+
> npx nextworks add auth-core
|
|
18
|
+
> npx nextworks add forms
|
|
19
|
+
> npx nextworks add data
|
|
20
|
+
> ```
|
|
21
|
+
>
|
|
22
|
+
> Using Data without Blocks/Auth/Forms may work but is not yet a supported path and can require manual Prisma/schema and UI tweaks.
|
|
23
|
+
|
|
24
|
+
What the kit includes
|
|
25
|
+
|
|
26
|
+
- API routes:
|
|
27
|
+
- app/api/posts/route.ts
|
|
28
|
+
- app/api/posts/[id]/route.ts
|
|
29
|
+
- app/api/users/route.ts
|
|
30
|
+
- app/api/users/[id]/route.ts
|
|
31
|
+
- app/api/users/check-unique/route.ts
|
|
32
|
+
- app/api/users/check-email/route.ts
|
|
33
|
+
- app/api/seed-demo/route.ts
|
|
34
|
+
- Admin UI components (now standalone in the kit):
|
|
35
|
+
- components/admin/posts-manager.tsx
|
|
36
|
+
- components/admin/users-manager.tsx
|
|
37
|
+
- Protected admin pages:
|
|
38
|
+
- app/(protected)/admin/posts/page.tsx
|
|
39
|
+
- app/(protected)/admin/users/page.tsx
|
|
40
|
+
- Example/demo pages and helpers:
|
|
41
|
+
- app/examples/demo/create-post-form.tsx
|
|
42
|
+
- app/examples/demo/page.tsx
|
|
43
|
+
- app/examples/demo/README.md
|
|
44
|
+
- Prisma helpers and utilities:
|
|
45
|
+
- lib/prisma.ts
|
|
46
|
+
- lib/server/result.ts (ApiResult helpers)
|
|
47
|
+
- lib/utils.ts
|
|
48
|
+
- Seed script: scripts/seed-demo.mjs
|
|
49
|
+
- Kit metadata: package-deps.json (declares @prisma/client and zod; prisma is a devDependency)
|
|
50
|
+
|
|
51
|
+
Database requirements
|
|
52
|
+
|
|
53
|
+
- The data kit is designed and tested with **PostgreSQL**, using a Postgres database hosted on [Neon](https://neon.tech/) during development.
|
|
54
|
+
- Any Prisma‑supported provider _may_ work, but **Postgres is the recommended and currently tested path**.
|
|
55
|
+
|
|
56
|
+
Quick start with Postgres (recommended):
|
|
57
|
+
|
|
58
|
+
1. Create a Postgres database (for example on Neon).
|
|
59
|
+
2. Copy the connection string into your `.env` as:
|
|
60
|
+
|
|
61
|
+
```bash
|
|
62
|
+
DATABASE_URL="postgres://..."
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
3. Merge the Data/Auth Prisma models into your project's `prisma/schema.prisma` (see `prisma/auth-models.prisma` referenced by the manifest).
|
|
66
|
+
4. Run:
|
|
67
|
+
|
|
68
|
+
```bash
|
|
69
|
+
npx prisma generate
|
|
70
|
+
npx prisma migrate dev -n init_data
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
If you choose a different database provider, update the `provider` field in your Prisma schema and carefully review indexes/constraints before running migrations.
|
|
74
|
+
|
|
75
|
+
Notes and important behavior
|
|
76
|
+
|
|
77
|
+
- Kit dependencies:
|
|
78
|
+
- Data depends on Auth (for RBAC/session) and Forms (for form primitives/validation). The CLI currently auto-installs `auth-core` and `forms` when you run `nextworks add data` to ensure the required pieces are present. If you prefer an interactive prompt instead of auto-install, the CLI can be adjusted to prompt (ask the maintainers).
|
|
79
|
+
- The kit's package-deps.json lists runtime and dev dependencies that the CLI will merge into the project's package.json; after installation you must run npm install in the project.
|
|
80
|
+
|
|
81
|
+
- Standalone admin components:
|
|
82
|
+
- The admin UI components have been copied into the kit so the Data kit is self-contained. They may still import shared UI primitives (for example from a Blocks or shared ui package) — ensure the consumer project has those UI packages or the CLI installs the required kits.
|
|
83
|
+
|
|
84
|
+
- Auth overlap:
|
|
85
|
+
- The Data kit references the signup API route (app/api/signup/route.ts) in its manifest but does not duplicate the signup implementation — signup is provided by the Auth kit.
|
|
86
|
+
|
|
87
|
+
- Prisma schema & migrations:
|
|
88
|
+
- The kit manifest references prisma/schema.prisma, prisma/migrations/\* and prisma/auth-models.prisma snippets, but the kit does not ship a full migrations directory. You must merge the provided model snippets into your project's prisma/schema.prisma, then run:
|
|
89
|
+
1. npx prisma generate
|
|
90
|
+
2. npx prisma migrate dev
|
|
91
|
+
|
|
92
|
+
Post-install checklist
|
|
93
|
+
|
|
94
|
+
1. Run `npm install` in your project to install dependencies merged by the kit.
|
|
95
|
+
2. Merge the Data/Auth Prisma models into your project's `prisma/schema.prisma` (see `prisma/auth-models.prisma` referenced by the manifest) and run:
|
|
96
|
+
- `npx prisma generate`
|
|
97
|
+
- `npx prisma migrate dev`
|
|
98
|
+
3. Populate demo data if desired:
|
|
99
|
+
- Either run the kit seed script locally: `node scripts/seed-demo.mjs`
|
|
100
|
+
- Or call the included API seed endpoint (POST to `/api/seed-demo`) if you prefer an HTTP-driven seed.
|
|
101
|
+
|
|
102
|
+
CLI behavior and packaging (for maintainers)
|
|
103
|
+
|
|
104
|
+
- Command: the CLI exposes the command `nextworks add data` which copies the files listed in `cli/cli_manifests/data_manifest.json` into your project and merges `package-deps.json` entries.
|
|
105
|
+
- Auto-install: when running the command the CLI ensures Forms and Auth are installed first (auto-installs them if missing).
|
|
106
|
+
- Manifest: keep cli_manifests/data_manifest.json and the files in this kit folder in sync — the CLI uses the manifest to know which files to copy.
|
|
107
|
+
- Packaging: the kit includes package-deps.json and is included in the CLI distribution tarball (dist/kits/data). When the CLI package is built/packed it will include the standalone Data kit files.
|
|
108
|
+
|
|
109
|
+
Caveats & tips
|
|
110
|
+
|
|
111
|
+
- The kit is intended as example/demo code — consumers should review and adapt for production use (security, RBAC rules, validation, etc.).
|
|
112
|
+
- If you want the CLI to prompt before installing Auth/Forms instead of auto-installing, open an issue or request the interactive behavior; it can be added.
|
|
113
|
+
- If you want a timestamped or additional tarball build, the CLI packing step can be re-run to produce another artifact.
|
|
114
|
+
|
|
115
|
+
CLI manifest
|
|
116
|
+
|
|
117
|
+
- In the Nextworks repo, the CLI copies files listed in `cli/cli_manifests/data_manifest.json`. Keep that manifest and this kit folder in sync when editing the repo.
|
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
# Forms Quickstart — Example page
|
|
2
|
+
|
|
3
|
+
This short doc points to the minimal example that demonstrates how to use the Forms primitives with Select, Checkbox and Switch components. It also documents the ApiResult pattern for mapping server field errors into react-hook-form and points to the per-field async validation helper used in the signup form.
|
|
4
|
+
|
|
5
|
+
> To add these examples and primitives to your own app via the CLI, the recommended alpha setup is to install Blocks with sections and templates first, then Forms:
|
|
6
|
+
>
|
|
7
|
+
> ```bash
|
|
8
|
+
> npx nextworks add blocks --sections --templates
|
|
9
|
+
> npx nextworks add forms
|
|
10
|
+
> ```
|
|
11
|
+
>
|
|
12
|
+
> The CLI will copy the Forms primitives and example pages into your `components/ui/form/*`, `components/hooks/`, `lib/validation/*`, and `app/examples/forms/*` directories.
|
|
13
|
+
|
|
14
|
+
Where to find the example
|
|
15
|
+
|
|
16
|
+
- Example page: /examples/forms/basic
|
|
17
|
+
- Full path in repo: app/examples/forms/basic/page.tsx
|
|
18
|
+
|
|
19
|
+
What the example shows
|
|
20
|
+
|
|
21
|
+
- react-hook-form + zodResolver integration using the project's Form primitives
|
|
22
|
+
- Usage of Select, Checkbox and Switch UI components with FormField (which uses RHF Controller under the hood)
|
|
23
|
+
- A minimal submit handler (client-side) you can copy/replace with your API call
|
|
24
|
+
|
|
25
|
+
How to try it locally
|
|
26
|
+
|
|
27
|
+
1. Start the dev server:
|
|
28
|
+
npm run dev
|
|
29
|
+
2. Open your browser and visit:
|
|
30
|
+
http://localhost:3000/examples/forms/basic
|
|
31
|
+
|
|
32
|
+
Note: Some examples that hit the server (such as the wizard/server-action flows) assume you have a Prisma schema and database configured in your app, often via Auth Core/Data. If you haven’t set that up yet, expect those examples to need additional setup.
|
|
33
|
+
|
|
34
|
+
Tip: If you change the Prisma schema, run:
|
|
35
|
+
npx prisma generate
|
|
36
|
+
npx prisma migrate dev
|
|
37
|
+
|
|
38
|
+
Copy/paste tips for your app
|
|
39
|
+
|
|
40
|
+
- Import Form primitives and controls from:
|
|
41
|
+
- components/ui/form/\* (Form, FormField, FormItem, FormLabel, FormControl, FormMessage)
|
|
42
|
+
- components/ui/select.tsx, components/ui/checkbox.tsx, components/ui/switch.tsx
|
|
43
|
+
- The example shows how to forward checkbox/switch changes to RHF by using f.onChange(e.target.checked) and setting checked={!!f.value}.
|
|
44
|
+
|
|
45
|
+
If you want the example to submit to your API, replace the onSubmit handler's console/alert with a fetch() call or server action.
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
Kit manifest & files (for packaging)
|
|
50
|
+
|
|
51
|
+
If you plan to package a Forms kit (CLI or manual copy), here are the primary files used by the examples and primitives. This manifest is for documentation and packaging reference.
|
|
52
|
+
|
|
53
|
+
Files
|
|
54
|
+
|
|
55
|
+
- components/ui/form/form.tsx
|
|
56
|
+
- components/ui/form/form-field.tsx
|
|
57
|
+
- components/ui/form/form-item.tsx
|
|
58
|
+
- components/ui/form/form-control.tsx
|
|
59
|
+
- components/ui/form/form-description.tsx
|
|
60
|
+
- components/ui/form/form-label.tsx
|
|
61
|
+
- components/ui/form/form-message.tsx
|
|
62
|
+
- components/ui/select.tsx
|
|
63
|
+
- components/ui/checkbox.tsx
|
|
64
|
+
- components/ui/switch.tsx
|
|
65
|
+
- components/hooks/useCheckUnique.ts
|
|
66
|
+
- lib/validation/forms.ts
|
|
67
|
+
- lib/validation/wizard.ts
|
|
68
|
+
- lib/forms/map-errors.ts
|
|
69
|
+
- app/examples/forms/basic/page.tsx
|
|
70
|
+
- app/examples/forms/server-action/page.tsx
|
|
71
|
+
- app/examples/forms/server-action/form-client.tsx
|
|
72
|
+
- app/examples/forms/wizard/wizard-client.tsx
|
|
73
|
+
- app/examples/forms/wizard/page.tsx
|
|
74
|
+
|
|
75
|
+
API routes (used by examples)
|
|
76
|
+
|
|
77
|
+
- app/api/wizard/route.ts
|
|
78
|
+
|
|
79
|
+
Notes
|
|
80
|
+
|
|
81
|
+
- The Forms primitives are UI-only and do not require Prisma or NextAuth to function. The server-action example and the mapping helper demonstrate how to validate server-side and map errors back to react-hook-form.
|
|
82
|
+
- If you are packaging the kit, consider copying only components/ui/form/\* and the select/checkbox/switch files, plus the example pages if you want to keep the demo pages.
|
|
83
|
+
|
|
84
|
+
If you want, I can create docs/FORMS_MANIFEST.json in the repo with the above manifest for the CLI packaging step.
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
Forms kit (cli/kits/forms)
|
|
2
|
+
|
|
3
|
+
This folder contains the files that the `nextworks` CLI copies into a target Next.js project when you run:
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
npx nextworks add forms
|
|
7
|
+
```
|
|
8
|
+
|
|
9
|
+
What the kit includes
|
|
10
|
+
|
|
11
|
+
- Form primitives built on React Hook Form + Zod: components/ui/form/\*
|
|
12
|
+
- Select / Checkbox / Switch primitives wired for form usage
|
|
13
|
+
- Shared validation schemas: lib/validation/forms.ts and lib/validation/wizard.ts
|
|
14
|
+
- Form error mapping helper: lib/forms/map-errors.ts
|
|
15
|
+
- Example pages:
|
|
16
|
+
- Basic form: app/examples/forms/basic/page.tsx
|
|
17
|
+
- Server action form: app/examples/forms/server-action/page.tsx and form-client.tsx
|
|
18
|
+
- Wizard example: app/examples/forms/wizard/page.tsx and wizard-client.tsx
|
|
19
|
+
- Wizard API route: app/api/wizard/route.ts
|
|
20
|
+
|
|
21
|
+
Notes
|
|
22
|
+
|
|
23
|
+
- The forms primitives are UI-only and do not require Prisma or NextAuth.
|
|
24
|
+
- The wizard example assumes a basic app/api/wizard/route.ts endpoint; adjust it as needed for your project.
|
|
25
|
+
- Keep this kit folder in sync with cli_manifests/forms_manifest.json.
|
|
26
|
+
|
|
27
|
+
> **Alpha note**
|
|
28
|
+
>
|
|
29
|
+
> In this early alpha, Forms is tested on top of a **Blocks** install that includes sections and templates. For the smoothest experience, install Blocks first:
|
|
30
|
+
>
|
|
31
|
+
> ```bash
|
|
32
|
+
> npx nextworks add blocks --sections --templates
|
|
33
|
+
> npx nextworks add forms
|
|
34
|
+
> ```
|
|
35
|
+
>
|
|
36
|
+
> Using Forms without Blocks may work but can require manual tweaks (for example around shared UI primitives).
|
|
37
|
+
|
|
38
|
+
Post-install steps (recommended)
|
|
39
|
+
|
|
40
|
+
1. Install dependencies (the CLI will merge `package-deps.json` into your `package.json`):
|
|
41
|
+
|
|
42
|
+
```bash
|
|
43
|
+
npm install
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
2. Ensure you have React Hook Form and Zod installed (if not already present). The CLI will attempt to add these via `package-deps.json`.
|
|
47
|
+
|
|
48
|
+
3. Start your dev server and explore the examples:
|
|
49
|
+
|
|
50
|
+
```bash
|
|
51
|
+
npm run dev
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
- /examples/forms/basic
|
|
55
|
+
- /examples/forms/server-action
|
|
56
|
+
- /examples/forms/wizard
|
|
57
|
+
|
|
58
|
+
CLI behavior (for maintainers)
|
|
59
|
+
|
|
60
|
+
- In the Nextworks repo, the CLI copies the files listed in `cli/cli_manifests/forms_manifest.json`. Keep that manifest and this kit folder in sync when editing the repo.
|