feat(wikibase-schema-editor): build basic editor container#82
feat(wikibase-schema-editor): build basic editor container#82
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis set of changes implements the full WikibaseSchemaEditor component, adding logic for schema editing, drag-and-drop, validation, and UI structure. It introduces a comprehensive test suite for the component, updates documentation to standardize testing practices (using Bun Test), and enforces variable naming conventions. Several files undergo variable renaming for clarity and code consistency, and global constant declarations are cleaned up. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant WikibaseSchemaEditor
participant schemaStore
participant dragDropStore
participant validationStore
participant useSchemaApi
User->>WikibaseSchemaEditor: Mounts component (with projectId/schemaId)
WikibaseSchemaEditor->>useSchemaApi: loadSchema(projectId, schemaId)
useSchemaApi-->>WikibaseSchemaEditor: Returns schema data
WikibaseSchemaEditor->>schemaStore: Initialize schema state
WikibaseSchemaEditor->>dragDropStore: Setup drag/drop targets
WikibaseSchemaEditor->>validationStore: Validate schema
User->>WikibaseSchemaEditor: Clicks "Add Item"
WikibaseSchemaEditor->>schemaStore: Start item configuration
User->>WikibaseSchemaEditor: Clicks "Save"
WikibaseSchemaEditor->>useSchemaApi: createSchema/updateSchema
useSchemaApi-->>WikibaseSchemaEditor: Returns success/error
WikibaseSchemaEditor->>validationStore: Validate schema
Possibly related PRs
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (4)
frontend/src/components/WikibaseSchemaEditor.vue (4)
39-48: Consider optimizing object emptiness checks.For better performance when checking if objects are empty, consider using more efficient approaches.
const hasItem = computed(() => { - // An item exists if we have a valid Wikibase ItemId, any configuration, or are actively configuring return ( schemaStore.itemId !== null || - Object.keys(schemaStore.labels).length > 0 || - Object.keys(schemaStore.descriptions).length > 0 || + !isEmptyObject(schemaStore.labels) || + !isEmptyObject(schemaStore.descriptions) || schemaStore.statements.length > 0 || isConfiguringItem.value ) }) + +// Helper function +const isEmptyObject = (obj: object) => { + for (const _ in obj) return false + return true +}
93-120: Consider making the language configurable for internationalization.All drag-drop targets are hard-coded to English ('en'). This limits the component's internationalization capabilities.
Consider accepting a language prop or using a user preference:
-const initializeDragDropTargets = () => { +const initializeDragDropTargets = (language = 'en') => { // Set up available drop targets for drag-and-drop operations const targets = [ { type: 'label' as const, - path: 'item.terms.labels.en', + path: `item.terms.labels.${language}`, acceptedTypes: ['string' as const], - language: 'en', + language, isRequired: false, }, // ... update other targets similarly ]
319-357: Extract complex template logic to computed properties.The inline logic for formatting labels and descriptions is complex and repeated. Consider extracting to computed properties for better maintainability.
Add these computed properties in the script section:
const formattedLabels = computed(() => { const entries = Object.entries(schemaStore.labels) return entries.length > 0 ? entries.map(([lang, mapping]) => `${mapping.columnName} (${lang})`).join(', ') : null }) const formattedDescriptions = computed(() => { const entries = Object.entries(schemaStore.descriptions) return entries.length > 0 ? entries.map(([lang, mapping]) => `${mapping.columnName} (${lang})`).join(', ') : null })Then simplify the template:
- <span - v-if="Object.keys(schemaStore.labels).length > 0" - class="ml-2 text-gray-700" - > - {{ - Object.entries(schemaStore.labels) - .map(([lang, mapping]) => `${mapping.columnName} (${lang})`) - .join(', ') - }} - </span> + <span + v-if="formattedLabels" + class="ml-2 text-gray-700" + > + {{ formattedLabels }} + </span>
30-33: Consider Vue 3 performance optimizations.Based on Vue 3 best practices, consider using performance optimization techniques for better efficiency.
For frequently accessed but rarely changed data:
// Reactive state -const isInitialized = ref(false) -const isConfiguringItem = ref(false) +const isInitialized = shallowRef(false) +const isConfiguringItem = shallowRef(false)For the drag-drop targets that don't need deep reactivity:
- dragDropStore.setAvailableTargets(targets) + dragDropStore.setAvailableTargets(markRaw(targets))
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
.kiro/specs/wikibase-schema-editor/tasks.md(1 hunks).kiro/steering/code-conventions.md(1 hunks).kiro/steering/tech.md(3 hunks)frontend/src/components/WikibaseSchemaEditor.vue(1 hunks)frontend/src/components/__tests__/WikibaseSchemaEditor.test.ts(1 hunks)frontend/tsconfig.vite.json(0 hunks)tsconfig.base.json(1 hunks)
💤 Files with no reviewable changes (1)
- frontend/tsconfig.vite.json
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,js,jsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc
**/*.test.{ts,tsx,js,jsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc
**/*.{html,ts,tsx,css}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc
🧠 Learnings (4)
tsconfig.base.json (12)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{html,ts,tsx,css} : Use `bun build <file.html|file.ts|file.css>` instead of `webpack` or `esbuild` for building HTML, TypeScript, or CSS files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `bun <file>` instead of `node <file>` or `ts-node <file>` for running TypeScript or JavaScript files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `bun:sqlite` for SQLite instead of `better-sqlite3`
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.html : HTML files can import .tsx, .jsx, or .js files directly and Bun's bundler will transpile & bundle automatically
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.test.{ts,tsx,js,jsx} : Use `bun test` instead of `jest` for running tests
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Prefer `Bun.file` over `node:fs`'s readFile/writeFile
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{ts,vue} : Type safety everywhere
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Do not use dotenv; Bun automatically loads .env files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `Bun.redis` for Redis instead of `ioredis`
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.126Z
Learning: Applies to **/*.{tsx,jsx,js} : Import .css files directly in .tsx, .jsx, or .js files and Bun will handle them
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `Bun.$` (e.g., `Bun.$`ls``) instead of execa for running shell commands
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{html,tsx,jsx,js,css} : Use HTML imports with `Bun.serve()` instead of `vite` for frontend development
.kiro/steering/code-conventions.md (11)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.test.{ts,tsx,js,jsx} : Use `bun test` instead of `jest` for running tests
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.126Z
Learning: For more information, read the official Bun documentation at https://bun.sh/docs or check `node_modules/bun-types/docs/**.md` if available locally
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `bun <file>` instead of `node <file>` or `ts-node <file>` for running TypeScript or JavaScript files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Build reusable, well-structured components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use <script setup lang="ts"> at the top, template second, style last (rarely used) in Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{ts,vue} : Type safety everywhere
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.690Z
Learning: Applies to src/**/*.vue : Use Vue 3 with Composition API and <script setup lang="ts"> in all Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{html,tsx,jsx,js,css} : Use HTML imports with `Bun.serve()` instead of `vite` for frontend development
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.126Z
Learning: Applies to **/*.{tsx,jsx,js} : Import .css files directly in .tsx, .jsx, or .js files and Bun will handle them
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.690Z
Learning: Applies to src/**/*.vue : Use Tailwind CSS utility classes for all styling; Tailwind is mandatory for all styling
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Prefer composables over methods in Vue components
.kiro/steering/tech.md (16)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.test.{ts,tsx,js,jsx} : Use `bun test` instead of `jest` for running tests
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.126Z
Learning: For more information, read the official Bun documentation at https://bun.sh/docs or check `node_modules/bun-types/docs/**.md` if available locally
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `bun <file>` instead of `node <file>` or `ts-node <file>` for running TypeScript or JavaScript files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{html,ts,tsx,css} : Use `bun build <file.html|file.ts|file.css>` instead of `webpack` or `esbuild` for building HTML, TypeScript, or CSS files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `Bun.$` (e.g., `Bun.$`ls``) instead of execa for running shell commands
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{html,tsx,jsx,js,css} : Use HTML imports with `Bun.serve()` instead of `vite` for frontend development
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use auto-imports for Vue, Pinia, composables, and utilities
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Build reusable, well-structured components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.690Z
Learning: Applies to src/**/*.vue : Use PrimeVue as the UI library in all Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to package.json : Use `bun install` instead of `npm install`, `yarn install`, or `pnpm install` for dependency installation
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to package.json : Use `bun run <script>` instead of `npm run <script>`, `yarn run <script>`, or `pnpm run <script>` for running scripts
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `bun:sqlite` for SQLite instead of `better-sqlite3`
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `Bun.serve()` for HTTP servers and WebSockets instead of `express`
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Do not use dotenv; Bun automatically loads .env files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.126Z
Learning: Applies to **/*.{tsx,jsx,js} : Import .css files directly in .tsx, .jsx, or .js files and Bun will handle them
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `Bun.sql` for Postgres instead of `pg` or `postgres.js`
frontend/src/components/WikibaseSchemaEditor.vue (10)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.690Z
Learning: Applies to src/**/*.vue : Use Vue 3 with Composition API and <script setup lang="ts"> in all Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Props and emits must use explicit TypeScript interfaces
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use <script setup lang="ts"> at the top, template second, style last (rarely used) in Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use storeToRefs for state in components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Build reusable, well-structured components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Use useApi composable (Elysia Eden) for all API calls
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use v-memo, shallowRef, markRaw, and Suspense for performance optimization
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{ts,vue} : Type safety everywhere
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use reactive objects for form state and errors
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Use readonly and shallowReactive for large or expensive data
🪛 Biome (1.9.4)
tsconfig.base.json
[error] 9-9: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 9-9: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 9-9: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 9-9: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
🔇 Additional comments (18)
.kiro/steering/tech.md (4)
29-29: Excellent alignment with Bun-first approach!The addition of Bun Test as the native testing framework perfectly aligns with the project's Bun-first philosophy and retrieved learnings.
47-58: Comprehensive test command coverage.The expanded testing commands section provides clear guidance for running tests across different scopes (all, backend-only, frontend-only, specific files) using proper Bun syntax.
70-95: Well-structured testing framework documentation.The Testing Framework section provides clear guidance on:
- Native Bun test runner usage
- Proper file naming conventions (*.test.ts, *.spec.ts)
- Correct directory structure for frontend/backend tests
- Appropriate testing patterns with proper imports
The focus on logic testing over DOM testing aligns well with maintainable testing practices.
102-102: Strategic dependency addition.Adding @vue/test-utils for future DOM testing provides a clear upgrade path when component testing needs expand beyond logic testing.
.kiro/specs/wikibase-schema-editor/tasks.md (1)
52-52: Task completion properly tracked.Marking task 9 as completed correctly reflects the implementation of the WikibaseSchemaEditor container in this PR, aligning with the stated PR objectives.
tsconfig.base.json (1)
9-9: Appropriate module resolution update for bundler environment.Changing from "node" to "bundler" module resolution is correct for modern bundler setups and aligns well with Bun's bundling capabilities. This change supports better TypeScript integration in the frontend build process.
Note: The static analysis errors appear to be false positives from Biome's JSON parser.
.kiro/steering/code-conventions.md (1)
8-46: Comprehensive testing standards establishment.The new Testing Standards section excellently defines:
- Proper Bun Test framework usage (aligning with retrieved learnings)
- Clear file naming and organization conventions
- Pragmatic focus on logic testing over complex DOM testing
- Well-structured examples with correct import patterns
This provides essential guidance for maintaining consistent testing practices across the codebase.
frontend/src/components/__tests__/WikibaseSchemaEditor.test.ts (10)
1-3: Perfect alignment with testing standards.The import pattern
import { describe, test, expect } from 'bun:test'exactly matches the testing standards defined in the coding conventions, demonstrating excellent adherence to project guidelines.
4-13: Excellent documentation and test organization.The comprehensive file header clearly describes the test scope and purpose, providing valuable context for future maintainers. The focus areas align perfectly with the component's responsibilities.
14-32: Thoughtful interface validation approach.Testing the emit interface structure ensures type safety and validates the component's event API. This demonstrates good testing practices for TypeScript-based Vue components.
34-58: Comprehensive schema title logic testing.The tests cover all edge cases for schema title computation including empty strings, null values, and valid names. This thorough approach ensures robust fallback behavior.
60-120: Thorough item detection logic validation.The test suite comprehensively validates item existence detection across all possible scenarios (itemId, labels, descriptions, statements). This ensures reliable component state management.
122-154: Complete save button state logic coverage.All combinations of dirty/loading states are tested, ensuring the save button behaves correctly under all conditions. This prevents UI inconsistencies.
156-215: Well-structured drag-drop target validation.The tests validate both the structure and types of drop targets, ensuring proper drag-and-drop functionality. The type validation approach is particularly robust.
217-253: Solid event handler logic testing.The event handler tests cover both success and edge cases (like preventing duplicate items), ensuring reliable user interaction handling.
255-294: Comprehensive schema persistence validation.The payload construction tests ensure data integrity for both create and update operations, which is critical for reliable API interactions.
296-372: Excellent integration and data handling tests.The empty schema initialization and column data integration tests demonstrate thorough coverage of component lifecycle and drag-drop operations. The compatibility checking logic is particularly well-tested.
frontend/src/components/WikibaseSchemaEditor.vue (1)
1-19: Well-structured component setup following Vue 3 best practices.The script setup with TypeScript and explicit interfaces for props and emits aligns perfectly with the Vue 3 Composition API standards.
| // Store instances | ||
| const schemaStore = useSchemaStore() | ||
| const dragDropStore = useDragDropStore() | ||
| const validationStore = useValidationStore() |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using storeToRefs for reactive state access.
According to Vue 3 best practices, when accessing reactive state from Pinia stores, use storeToRefs to maintain reactivity.
If you're accessing reactive state properties from these stores elsewhere in the component, consider:
+import { storeToRefs } from 'pinia'
+
// Store instances
const schemaStore = useSchemaStore()
const dragDropStore = useDragDropStore()
const validationStore = useValidationStore()
+
+// Destructure reactive state if needed
+// const { schemaName, isDirty, isLoading } = storeToRefs(schemaStore)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Store instances | |
| const schemaStore = useSchemaStore() | |
| const dragDropStore = useDragDropStore() | |
| const validationStore = useValidationStore() | |
| import { storeToRefs } from 'pinia' | |
| // Store instances | |
| const schemaStore = useSchemaStore() | |
| const dragDropStore = useDragDropStore() | |
| const validationStore = useValidationStore() | |
| // Destructure reactive state if needed | |
| // const { schemaName, isDirty, isLoading } = storeToRefs(schemaStore) |
🤖 Prompt for AI Agents
In frontend/src/components/WikibaseSchemaEditor.vue around lines 21 to 24, the
Pinia stores are accessed directly which may cause loss of reactivity when
destructuring state properties. To fix this, import and use storeToRefs from
Pinia for each store instance to extract reactive references of the state
properties you need. Replace direct store property access with these refs to
ensure reactivity is preserved throughout the component.
| const handleSave = async () => { | ||
| if (!canSave.value) return | ||
|
|
||
| try { | ||
| if (schemaStore.schemaId) { | ||
| // Update existing schema | ||
| await updateSchema(props.projectId, schemaStore.schemaId, { | ||
| id: schemaStore.schemaId, | ||
| projectId: schemaStore.projectId, | ||
| name: schemaStore.schemaName, | ||
| wikibase: schemaStore.wikibase, | ||
| item: { | ||
| id: schemaStore.itemId ?? undefined, | ||
| terms: { | ||
| labels: schemaStore.labels, | ||
| descriptions: schemaStore.descriptions, | ||
| aliases: schemaStore.aliases, | ||
| }, | ||
| statements: schemaStore.statements, | ||
| }, | ||
| createdAt: schemaStore.createdAt, | ||
| updatedAt: new Date().toISOString(), | ||
| }) | ||
| } else { | ||
| // Create new schema | ||
| await createSchema(props.projectId, { | ||
| name: schemaStore.schemaName, | ||
| wikibase: schemaStore.wikibase, | ||
| }) | ||
| } | ||
|
|
||
| showSuccess('Schema saved successfully') | ||
| } catch (error) { | ||
| showError({ | ||
| errors: [ | ||
| { | ||
| code: 'DATABASE_ERROR', | ||
| message: 'Failed to save schema', | ||
| }, | ||
| ], | ||
| }) | ||
| } | ||
|
|
||
| emit('save') | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Improve error handling specificity and verify new schema creation.
The error handling assumes all failures are database-related, and new schema creation might be missing item data.
- Consider more specific error handling:
} catch (error) {
+ const errorCode = error?.response?.status === 500 ? 'DATABASE_ERROR' : 'SAVE_FAILED';
showError({
errors: [
{
- code: 'DATABASE_ERROR',
+ code: errorCode,
message: 'Failed to save schema',
},
],
})
}- Verify if new schema creation should include item data when
hasItemis true.
🏁 Script executed:
#!/bin/bash
# Check the createSchema API implementation to see what data it accepts
ast-grep --pattern 'function createSchema($$$) {
$$$
}'
# Also check for any createSchema usage patterns
rg -A 10 'createSchema\('Length of output: 3750
I need to inspect the createSchema implementation to confirm what payload it accepts and how it surfaces errors. Let’s dump its definition and surrounding logic:
🏁 Script executed:
#!/bin/bash
# Locate and display createSchema in the API composable
rg -n "createSchema" frontend/src/composables/useSchemaApi.ts
sed -n '1,200p' frontend/src/composables/useSchemaApi.tsLength of output: 3901
Refactor handleSave to properly surface API errors
Currently, both createSchema and updateSchema swallow API errors (they call showError() internally and never throw), so handleSave’s try/catch block will almost never catch a failure. As a result, showSuccess('Schema saved successfully') and emit('save') always run—even when the save has failed.
• Capture and inspect the return value from the composable and only proceed on success:
const handleSave = async () => {
if (!canSave.value) return
// 1) Invoke the correct action and get its result
const result = schemaStore.schemaId
? await updateSchema(props.projectId, schemaStore.schemaId, { /* … */ })
: await createSchema(props.projectId, {
name: schemaStore.schemaName,
wikibase: schemaStore.wikibase,
})
// 2) If the composable displayed an error, it returns undefined
if (!result) return
showSuccess('Schema saved successfully')
emit('save')
}• You can remove (or narrow) the outer try/catch, since API errors are already handled by showError.
• No changes are needed to the payload for new-schema creation—the composable will load the full schema (including item data) into the store once the server responds.
Locations to update:
- frontend/src/components/WikibaseSchemaEditor.vue (lines 136–180)
🤖 Prompt for AI Agents
In frontend/src/components/WikibaseSchemaEditor.vue between lines 136 and 180,
refactor the handleSave function to capture and check the return value from
updateSchema or createSchema calls instead of relying on try/catch. Remove or
narrow the outer try/catch block since API errors are handled internally by
showError in those composables. Only proceed to call showSuccess and
emit('save') if the result is truthy, indicating a successful save. Keep the
payload for createSchema unchanged as the store will update with full schema
data after the server response.
| <Button | ||
| icon="pi pi-pencil" | ||
| rounded | ||
| text | ||
| size="small" | ||
| aria-label="Edit item" | ||
| /> | ||
| <Button | ||
| icon="pi pi-trash" | ||
| rounded | ||
| text | ||
| severity="danger" | ||
| size="small" | ||
| aria-label="Delete item" | ||
| /> | ||
| </div> |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add disabled state or handlers to placeholder buttons.
The edit and delete buttons lack click handlers, which could confuse users. Consider disabling them or adding placeholder handlers until the functionality is implemented.
<Button
icon="pi pi-pencil"
rounded
text
size="small"
aria-label="Edit item"
+ :disabled="true"
+ title="Edit functionality coming soon"
/>
<Button
icon="pi pi-trash"
rounded
text
severity="danger"
size="small"
aria-label="Delete item"
+ :disabled="true"
+ title="Delete functionality coming soon"
/>Would you like me to create an issue to track the implementation of these edit and delete functionalities?
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <Button | |
| icon="pi pi-pencil" | |
| rounded | |
| text | |
| size="small" | |
| aria-label="Edit item" | |
| /> | |
| <Button | |
| icon="pi pi-trash" | |
| rounded | |
| text | |
| severity="danger" | |
| size="small" | |
| aria-label="Delete item" | |
| /> | |
| </div> | |
| <Button | |
| icon="pi pi-pencil" | |
| rounded | |
| text | |
| size="small" | |
| aria-label="Edit item" | |
| :disabled="true" | |
| title="Edit functionality coming soon" | |
| /> | |
| <Button | |
| icon="pi pi-trash" | |
| rounded | |
| text | |
| severity="danger" | |
| size="small" | |
| aria-label="Delete item" | |
| :disabled="true" | |
| title="Delete functionality coming soon" | |
| /> |
🤖 Prompt for AI Agents
In frontend/src/components/WikibaseSchemaEditor.vue around lines 299 to 314, the
edit and delete buttons currently have no click handlers, which may confuse
users. To fix this, either add disabled attributes to these buttons to indicate
they are inactive or implement placeholder click handler functions that prevent
default behavior and optionally show a tooltip or console message indicating the
feature is not yet implemented.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
frontend/src/stores/drag-drop.store.ts (1)
68-74: Parameter rename looks good but consider removing the leading underscore for consistency.The renaming avoids the reserved word collision, but the underscore prefix is not used elsewhere in the project for regular parameters and may be mis-read as “unused”. An alternative is to adopt a more descriptive name (e.g.,
colorsrcColumn) and keep the codebase stylistically uniform..kiro/steering/tech.md (2)
34-35: Spelling & clarity—replace “independatly” with “independently”.Minor typo that may confuse readers; also consider re-phrasing the sentence so it reads:
“The development server runs independently and should not be triggered manually.”
62-69: Align tooling narrative—Vite vs. Bun dev server.The project’s “Frontend Stack” still lists Vite as the dev server, while earlier steering docs (and project learnings) prescribe using
Bun.serve()/ Bun’s built-in tooling instead of Vite.
Consider either:
- Updating this section to clarify that Vite is retained deliberately (and why), or
- Replacing/augmenting Vite with Bun’s dev server commands for consistency.
This prevents future confusion for new contributors.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
.kiro/steering/code-conventions.md(2 hunks).kiro/steering/tech.md(1 hunks)frontend/auto-imports.d.ts(0 hunks)frontend/components.d.ts(1 hunks)frontend/src/components/ColumnPalette.vue(2 hunks)frontend/src/composables/useColumnConversion.ts(1 hunks)frontend/src/composables/useColumnDataTypeIndicators.ts(2 hunks)frontend/src/composables/useDataTypeCompatibility.ts(1 hunks)frontend/src/stores/drag-drop.store.ts(4 hunks)
💤 Files with no reviewable changes (1)
- frontend/auto-imports.d.ts
✅ Files skipped from review due to trivial changes (5)
- frontend/src/composables/useColumnConversion.ts
- frontend/src/composables/useDataTypeCompatibility.ts
- frontend/components.d.ts
- frontend/src/composables/useColumnDataTypeIndicators.ts
- frontend/src/components/ColumnPalette.vue
🚧 Files skipped from review as they are similar to previous changes (1)
- .kiro/steering/code-conventions.md
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js,jsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc
**/*.{html,ts,tsx,css}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc
🧠 Learnings (1)
.kiro/steering/tech.md (12)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.test.{ts,tsx,js,jsx} : Use `bun test` instead of `jest` for running tests
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.126Z
Learning: For more information, read the official Bun documentation at https://bun.sh/docs or check `node_modules/bun-types/docs/**.md` if available locally
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `bun <file>` instead of `node <file>` or `ts-node <file>` for running TypeScript or JavaScript files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `Bun.serve()` for HTTP servers and WebSockets instead of `express`
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{html,ts,tsx,css} : Use `bun build <file.html|file.ts|file.css>` instead of `webpack` or `esbuild` for building HTML, TypeScript, or CSS files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `Bun.$` (e.g., `Bun.$`ls``) instead of execa for running shell commands
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{html,tsx,jsx,js,css} : Use HTML imports with `Bun.serve()` instead of `vite` for frontend development
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Prefer `Bun.file` over `node:fs`'s readFile/writeFile
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `bun:sqlite` for SQLite instead of `better-sqlite3`
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to package.json : Use `bun install` instead of `npm install`, `yarn install`, or `pnpm install` for dependency installation
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to package.json : Use `bun run <script>` instead of `npm run <script>`, `yarn run <script>`, or `pnpm run <script>` for running scripts
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `Bun.sql` for Postgres instead of `pg` or `postgres.js`
🧬 Code Graph Analysis (1)
frontend/src/stores/drag-drop.store.ts (2)
frontend/auto-imports.d.ts (2)
ColumnInfo(360-360)DropTarget(354-354)frontend/src/types/drag-drop.ts (1)
DropTarget(35-42)
🪛 LanguageTool
.kiro/steering/tech.md
[grammar] ~34-~34: Ensure spelling is correct
Context: ...velopment The development server is run independatly and should not be triggered. ### Testi...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🪛 Biome (1.9.4)
frontend/src/stores/drag-drop.store.ts
[error] 115-115: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.
The declaration is defined in this switch clause:
Unsafe fix: Wrap the declaration in a block.
(lint/correctness/noSwitchDeclarations)
[error] 116-116: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.
The declaration is defined in this switch clause:
Unsafe fix: Wrap the declaration in a block.
(lint/correctness/noSwitchDeclarations)
| switch (target.type) { | ||
| case 'label': | ||
| case 'alias': | ||
| // Check for reasonable length constraints | ||
| const maxLength = target.type === 'label' ? 250 : 100 | ||
| const hasLongValues = column.sampleValues?.some((val) => val.length > maxLength) | ||
| const hasLongValues = _column.sampleValues?.some((val) => val.length > maxLength) | ||
| if (hasLongValues) return false | ||
| break |
There was a problem hiding this comment.
Scope the maxLength declaration inside its own block to satisfy noSwitchDeclarations.
Declaring maxLength directly within a case without an explicit block leaks the identifier across sibling clauses and triggers Biome noSwitchDeclarations. This is flagged as an error and may lead to subtle bugs if future cases accidentally reuse the variable.
- switch (target.type) {
- case 'label':
- case 'alias':
- // Check for reasonable length constraints
- const maxLength = target.type === 'label' ? 250 : 100
- const hasLongValues = _column.sampleValues?.some((val) => val.length > maxLength)
- if (hasLongValues) return false
- break
+ switch (target.type) {
+ case 'label':
+ case 'alias': {
+ // Check for reasonable length constraints
+ const maxLength = target.type === 'label' ? 250 : 100
+ const hasLongValues = _column.sampleValues?.some(
+ (val) => val.length > maxLength,
+ )
+ if (hasLongValues) return false
+ break
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| switch (target.type) { | |
| case 'label': | |
| case 'alias': | |
| // Check for reasonable length constraints | |
| const maxLength = target.type === 'label' ? 250 : 100 | |
| const hasLongValues = column.sampleValues?.some((val) => val.length > maxLength) | |
| const hasLongValues = _column.sampleValues?.some((val) => val.length > maxLength) | |
| if (hasLongValues) return false | |
| break | |
| switch (target.type) { | |
| case 'label': | |
| case 'alias': { | |
| // Check for reasonable length constraints | |
| const maxLength = target.type === 'label' ? 250 : 100 | |
| const hasLongValues = _column.sampleValues?.some( | |
| (val) => val.length > maxLength, | |
| ) | |
| if (hasLongValues) return false | |
| break | |
| } |
🧰 Tools
🪛 Biome (1.9.4)
[error] 115-115: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.
The declaration is defined in this switch clause:
Unsafe fix: Wrap the declaration in a block.
(lint/correctness/noSwitchDeclarations)
[error] 116-116: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.
The declaration is defined in this switch clause:
Unsafe fix: Wrap the declaration in a block.
(lint/correctness/noSwitchDeclarations)
🤖 Prompt for AI Agents
In frontend/src/stores/drag-drop.store.ts around lines 111 to 118, the variable
maxLength is declared directly inside a switch case without a block, which
violates the noSwitchDeclarations rule. To fix this, wrap the code inside the
'label' and 'alias' cases in a separate block (curly braces) so that maxLength
is scoped locally and does not leak to other cases.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
frontend/src/components/WikibaseSchemaEditor.vue (2)
131-168: Fix save logic to properly handle API responses.The current save logic has a critical flaw where success messages and events are emitted even when the save operation fails, because the API composables handle errors internally and don't throw.
The
handleSavemethod needs to check the return value from the API calls:const handleSave = async () => { if (!canSave.value) return - try { + let result if (schemaStore.schemaId) { // Update existing schema - await updateSchema(props.projectId, schemaStore.schemaId, { + result = await updateSchema(props.projectId, schemaStore.schemaId, { // ... existing payload }) } else { // Create new schema - await createSchema(props.projectId, { + result = await createSchema(props.projectId, { name: schemaStore.schemaName, wikibase: schemaStore.wikibase, }) } + // Only proceed if the operation was successful + if (!result) return + showSuccess('Schema saved successfully') + emit('save') - } catch (error) { - showError(createFrontendError('UI_STATE_ERROR', 'Failed to save schema')) - } - - emit('save') }
287-301: Add disabled state to placeholder buttons.The edit and delete buttons lack click handlers and could confuse users about their functionality.
Apply this diff to disable the buttons until functionality is implemented:
<Button icon="pi pi-pencil" rounded text size="small" aria-label="Edit item" + :disabled="true" + title="Edit functionality coming soon" /> <Button icon="pi pi-trash" rounded text severity="danger" size="small" aria-label="Delete item" + :disabled="true" + title="Delete functionality coming soon" />
🧹 Nitpick comments (2)
.kiro/steering/code-conventions.md (1)
68-68: Fix markdown formatting issue.There's an extra space in the code span element that violates markdown standards.
Apply this diff to fix the formatting:
-- **Avoid Reserved Names**: Never use `column`, `message, `row` as variable names in frontend code +- **Avoid Reserved Names**: Never use `column`, `message`, `row` as variable names in frontend codefrontend/src/types/client-errors.ts (1)
34-41: Consider standard parameter naming.The helper function is well-implemented, but the parameter naming
_messageis unconventional.Apply this diff for standard naming:
export const createFrontendError = ( code: FrontendErrorCode, - _message: string, + message: string, details?: any[], ): ExtendedError => ({ - errors: [{ code, message: _message, details }], + errors: [{ code, message, details }], data: [], })
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.kiro/steering/code-conventions.md(2 hunks)frontend/.eslintrc-auto-import.json(2 hunks)frontend/auto-imports.d.ts(3 hunks)frontend/src/components/WikibaseSchemaEditor.vue(1 hunks)frontend/src/composables/useErrorHandling.ts(1 hunks)frontend/src/types/client-errors.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- frontend/auto-imports.d.ts
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js,jsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc
**/*.{html,ts,tsx,css}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc
🧠 Learnings (5)
frontend/.eslintrc-auto-import.json (2)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use auto-imports for Vue, Pinia, composables, and utilities
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{html,tsx,jsx,js,css} : Use HTML imports with `Bun.serve()` instead of `vite` for frontend development
frontend/src/composables/useErrorHandling.ts (3)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Use useApi composable (Elysia Eden) for all API calls
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Handle errors and loading states reactively when making API calls
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/composables/**/*.ts : Use composables for logic that is not global state
frontend/src/types/client-errors.ts (2)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Always use backend-inferred types for API data
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Validate on client and handle server errors for forms
frontend/src/components/WikibaseSchemaEditor.vue (16)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Props and emits must use explicit TypeScript interfaces
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.690Z
Learning: Applies to src/**/*.vue : Use Vue 3 with Composition API and <script setup lang="ts"> in all Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use <script setup lang="ts"> at the top, template second, style last (rarely used) in Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{ts,vue} : Type safety everywhere
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use storeToRefs for state in components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Use readonly and shallowReactive for large or expensive data
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Use Pinia stores for global state
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use reactive objects for form state and errors
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Always use backend-inferred types for API data
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Use useApi composable (Elysia Eden) for all API calls
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.690Z
Learning: Applies to src/**/*.vue : Use Pinia for state management in all Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Prefer reactivity over computed unless necessary
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use v-memo, shallowRef, markRaw, and Suspense for performance optimization
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/composables/**/*.ts : Do not proxy or export Pinia store state/actions from composables
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use auto-imports for Vue, Pinia, composables, and utilities
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Handle errors and loading states reactively when making API calls
.kiro/steering/code-conventions.md (22)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.test.{ts,tsx,js,jsx} : Use `bun test` instead of `jest` for running tests
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{ts,vue} : Type safety everywhere
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.126Z
Learning: For more information, read the official Bun documentation at https://bun.sh/docs or check `node_modules/bun-types/docs/**.md` if available locally
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `bun <file>` instead of `node <file>` or `ts-node <file>` for running TypeScript or JavaScript files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use <script setup lang="ts"> at the top, template second, style last (rarely used) in Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{html,ts,tsx,css} : Use `bun build <file.html|file.ts|file.css>` instead of `webpack` or `esbuild` for building HTML, TypeScript, or CSS files
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.126Z
Learning: Applies to **/*.{tsx,jsx,js} : Import .css files directly in .tsx, .jsx, or .js files and Bun will handle them
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Prefer `Bun.file` over `node:fs`'s readFile/writeFile
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Props and emits must use explicit TypeScript interfaces
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Always use backend-inferred types for API data
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Build reusable, well-structured components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.690Z
Learning: Applies to src/**/*.vue : Use Vue 3 with Composition API and <script setup lang="ts"> in all Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.125Z
Learning: Applies to **/*.{html,tsx,jsx,js,css} : Use HTML imports with `Bun.serve()` instead of `vite` for frontend development
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Prefer composables over methods in Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.690Z
Learning: Applies to src/**/*.vue : Use Tailwind CSS utility classes for all styling; Tailwind is mandatory for all styling
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.690Z
Learning: Applies to src/**/*.vue : Use PrimeVue as the UI library in all Vue components
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use auto-imports for Vue, Pinia, composables, and utilities
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Prefer reactivity over computed unless necessary
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Use readonly and shallowReactive for large or expensive data
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use v-memo, shallowRef, markRaw, and Suspense for performance optimization
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.vue : Use reactive objects for form state and errors
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.691Z
Learning: Applies to src/**/*.{vue,ts} : Handle errors and loading states reactively when making API calls
🧬 Code Graph Analysis (1)
frontend/src/composables/useErrorHandling.ts (2)
frontend/src/types/client-errors.ts (1)
ExtendedError(22-29)frontend/auto-imports.d.ts (1)
ExtendedError(355-355)
🪛 markdownlint-cli2 (0.17.2)
.kiro/steering/code-conventions.md
68-68: Spaces inside code span elements
(MD038, no-space-in-code)
🔇 Additional comments (10)
frontend/src/composables/useErrorHandling.ts (1)
4-4: LGTM! Proper alignment with new error handling infrastructure.The type change from
ApiErrortoExtendedErrorcorrectly aligns with the new frontend error handling module and maintains compatibility with the existing error mapping logic.frontend/.eslintrc-auto-import.json (1)
26-27: LGTM! Proper ESLint auto-import configuration for new error handling types.The new global identifiers are correctly added in alphabetical order and align with the frontend error handling infrastructure introduced in
frontend/src/types/client-errors.ts.Also applies to: 34-34, 85-85
.kiro/steering/code-conventions.md (2)
8-46: Excellent testing standards documentation.The new testing standards section provides clear, comprehensive guidelines for using Bun's native test runner, including proper file organization, naming conventions, and testing approaches. This aligns well with the project's move to Bun-based tooling.
67-71: Important variable naming restrictions properly documented.The variable naming restrictions correctly address PrimeVue auto-import conflicts that can cause runtime errors. This is crucial guidance for preventing common pitfalls in the frontend codebase.
frontend/src/types/client-errors.ts (2)
6-13: Well-defined frontend error codes.The frontend error codes are descriptive and cover the common client-side failure scenarios. Good categorization of UI, initialization, and validation errors.
22-29: Proper error interface structure.The
ExtendedErrorinterface correctly extends the error handling capabilities to support both backend and frontend error scenarios with a consistent structure.frontend/src/components/WikibaseSchemaEditor.vue (4)
2-5: Well-defined TypeScript interfaces for props.The props interface correctly defines optional
projectIdandschemaIdwith proper TypeScript typing, following Vue 3 best practices.
7-12: Proper emit interface definition.The emits interface clearly defines all component events with appropriate naming and empty parameter arrays, adhering to Vue 3 TypeScript patterns.
75-78: Improved error handling with frontend-specific error codes.The error handling now uses the new
createFrontendErrorfunction with the appropriateSCHEMA_EDITOR_INIT_FAILEDcode, which is much more specific than the previous generic server error codes.
183-406: Well-structured template with proper conditional rendering.The template follows Vue 3 best practices with clear semantic sections, proper conditional rendering for different states (empty, configured, loading), and good accessibility attributes with
data-testidandaria-labelattributes.
| <Button | ||
| icon="pi pi-pencil" | ||
| rounded | ||
| text | ||
| size="small" | ||
| aria-label="Edit statement" | ||
| /> | ||
| <Button | ||
| icon="pi pi-trash" | ||
| rounded | ||
| text | ||
| severity="danger" | ||
| size="small" | ||
| aria-label="Delete statement" | ||
| /> |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Disable statement action buttons consistently.
Similar to the item edit/delete buttons, these statement action buttons also lack handlers and should be disabled for consistency.
Apply this diff to disable these buttons:
<Button
icon="pi pi-pencil"
rounded
text
size="small"
aria-label="Edit statement"
+ :disabled="true"
+ title="Edit functionality coming soon"
/>
<Button
icon="pi pi-trash"
rounded
text
severity="danger"
size="small"
aria-label="Delete statement"
+ :disabled="true"
+ title="Delete functionality coming soon"
/>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <Button | |
| icon="pi pi-pencil" | |
| rounded | |
| text | |
| size="small" | |
| aria-label="Edit statement" | |
| /> | |
| <Button | |
| icon="pi pi-trash" | |
| rounded | |
| text | |
| severity="danger" | |
| size="small" | |
| aria-label="Delete statement" | |
| /> | |
| <Button | |
| icon="pi pi-pencil" | |
| rounded | |
| text | |
| size="small" | |
| aria-label="Edit statement" | |
| :disabled="true" | |
| title="Edit functionality coming soon" | |
| /> | |
| <Button | |
| icon="pi pi-trash" | |
| rounded | |
| text | |
| severity="danger" | |
| size="small" | |
| aria-label="Delete statement" | |
| :disabled="true" | |
| title="Delete functionality coming soon" | |
| /> |
🤖 Prompt for AI Agents
In frontend/src/components/WikibaseSchemaEditor.vue around lines 368 to 382, the
statement action buttons for edit and delete lack event handlers and should be
disabled for consistency with item edit/delete buttons. Add the disabled
attribute to both Button components to prevent user interaction until handlers
are implemented.
1 participant
Addresses Task 9 of #66