5.3 KiB
Frontend Workflow
- Prefer vinext for frontend development. With a local backend, start the API separately and use
./dev/start-weborpnpm -C web devfor the frontend only; the Dev Containerstart-webalias also starts only the frontend. For a remote backend, use rootpnpm devto start vinext and the API proxy. The local API and proxy both default to port 5001, so do not start both on that port. Switch to the Next.js development server (pnpm -C web dev:next) only when testing Next.js-specific functionality or investigating behavior that differs from Next.js. - Read
docs/test.mdonly for frontend test work anddocs/lint.mdonly when running or changing static checks. - Use the repo-local
how-to-write-componentskill when implementation requires component ownership, state, data-flow, effect, or interaction-boundary decisions. Do not load it for test-only, copy-only, or styling-only changes. - Use
frontend-code-reviewonly for explicit frontend review or audit requests, including test reviews. Usefrontend-testingwhen writing or changing Vitest or React Testing Library tests.
Package Contracts
Web owns application-specific requirements and consumes shared architecture guidance from skills and primitive contracts from Dify UI. Link to those owners instead of redefining their rules here.
- For truncated text disclosure and native
titledecisions, follow Truncated Text Disclosure. - Before adding or keeping a toast, follow Toasts. A toast is only for a result the user cannot see where they acted.
- When adding or changing page layouts, navigation, or landmark elements, follow Page landmarks and inspect the composed page, including parent layouts.
- User-facing strings must use
web/i18n/locales/en-US/keys. When adding or renaming a key, update every supported locale with the correct localized value. - For new backend calls and migrated surfaces, use generated
consoleQuery/consoleClientAPIs from@/service/console. Do not add handwritten REST helpers or DTO mirrors, mock-backed app state, or direct edits to generated contracts. - Prefer
@langgenius/dify-ui/*primitives, data attributes, and design tokens. Use the Dify UI package index to find a primitive; read the relevant contract directly when it is already known. Preserve a visible focus indicator on the final focusable element. - Reuse the Web
SearchInputcomposite when its search, clear, and IME contract matches the feature; otherwise follow the canonical Input Group contract. - Give save and submit flows a real form boundary with visible labels and accessible errors. Use Dify UI
Formwhen its structured submission and validation contract is the owner; otherwise use a native form. Follow the canonical form contract. - Follow the canonical Button contract and IconButton contract for action semantics, loading, accessible names, and primitive composition. Do not add a Web wrapper that hides those contracts.
- Follow Keyboard commands for hotkey ownership, targets, event consumption, typed bindings, and keycap display. Keep widget and editor keyboard semantics in their local owners.
- Follow Accessible names and descriptions when choosing or changing visible labels, ARIA naming, descriptions, or visually hidden text. Web owns localization and feature-specific status announcements; do not redefine the Dify UI naming contract locally.
- Before switching UI by viewport width, read Responsive layout: one component tree, CSS for appearance, width in JavaScript only for behaviour.
- Follow the Dify UI overlay contract for primitive selection, portals, focus, and layering. Use
@langgenius/dify-ui/infotipfor an info glyph that opens explanatory content. Do not introduce a generic Web wrapper that recreates Dify UI overlay behavior. - For custom SVG icons, follow
../packages/iconify-collections/README.md; do not add generated React icons underapp/components/base/icons/src/. docs/test.mdis the single source of truth for Web automated-test policy. Skills may route and execute that policy but must not redefine it.
This is NOT the Next.js you know
This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in node_modules/next/dist/docs/ (resolved from this file's directory; in monorepos the next package may not be visible from the repo root) before writing any code. Heed deprecation notices.
This block is written and re-added by next dev — verify at node_modules/next/dist/server/lib/generate-agent-files.js. Removing it from a diff only re-creates the uncommitted change; committing it with your work keeps the tree clean.