feat(wikibase-schema-editor): create property selection interface#90
feat(wikibase-schema-editor): create property selection interface#90
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis change introduces a new property selection feature for the statement configuration editor. It adds a reusable Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant StatementConfigEditor
participant PropertySelector
participant usePropertySelection
User->>StatementConfigEditor: Open editor
StatementConfigEditor->>PropertySelector: Render with current property
User->>PropertySelector: Type/search/select property
PropertySelector->>usePropertySelection: filterProperties(query)
usePropertySelection-->>PropertySelector: Return filtered properties
User->>PropertySelector: Select property
PropertySelector->>StatementConfigEditor: Emit update(selectedProperty)
StatementConfigEditor->>useStatementConfig: Update currentStatement.property
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~18 minutes Possibly related PRs
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches
🧪 Generate unit tests
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 (
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
frontend/src/composables/usePropertySelection.ts (2)
11-33: Comprehensive property list with good coverage.The common properties list covers a wide range of typical Wikibase use cases with proper data structure. However, consider the long-term maintainability of hardcoded property data.
Consider extracting property data to a separate configuration file or fetching from an API to improve maintainability:
// Consider moving to a separate config file const COMMON_PROPERTIES_CONFIG = './config/common-properties.json'
86-88: Consider returning all available properties.The method only returns
commonPropertiesbut could potentially include properties fromdataTypePropertiesfor a more comprehensive list.const getAllProperties = (): PropertyReference[] => { - return commonProperties + // Get all unique properties from both common and data type specific + const allProperties = new Map<string, PropertyReference>() + + commonProperties.forEach(prop => allProperties.set(prop.id, prop)) + Object.values(dataTypeProperties).flat().forEach(prop => allProperties.set(prop.id, prop)) + + return Array.from(allProperties.values()) }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
.kiro/specs/wikibase-schema-editor/tasks.md(1 hunks)frontend/.eslintrc-auto-import.json(1 hunks)frontend/auto-imports.d.ts(2 hunks)frontend/components.d.ts(2 hunks)frontend/src/components/PropertySelector.vue(1 hunks)frontend/src/components/StatementConfigEditor.vue(2 hunks)frontend/src/composables/__tests__/usePropertySelection.test.ts(1 hunks)frontend/src/composables/__tests__/useStatementConfig.test.ts(7 hunks)frontend/src/composables/usePropertySelection.ts(1 hunks)frontend/src/composables/useStatementConfig.ts(4 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit Inference Engine (.cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc)
**/*.{ts,tsx,js,jsx}: Usebun <file>instead ofnode <file>orts-node <file>for running TypeScript or JavaScript files
Do not use dotenv; Bun automatically loads .env files
UseBun.serve()for HTTP servers and WebSockets instead ofexpress
Usebun:sqlitefor SQLite instead ofbetter-sqlite3
UseBun.redisfor Redis instead ofioredis
UseBun.sqlfor Postgres instead ofpgorpostgres.js
Use built-inWebSocketinstead ofws
PreferBun.fileovernode:fs's readFile/writeFile
UseBun.$(e.g.,Bun.$ls``) instead of execa for running shell commands
Files:
frontend/components.d.tsfrontend/src/composables/__tests__/usePropertySelection.test.tsfrontend/auto-imports.d.tsfrontend/src/composables/usePropertySelection.tsfrontend/src/composables/__tests__/useStatementConfig.test.tsfrontend/src/composables/useStatementConfig.ts
**/*.{html,ts,tsx,css}
📄 CodeRabbit Inference Engine (.cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc)
Use
bun build <file.html|file.ts|file.css>instead ofwebpackoresbuildfor building HTML, TypeScript, or CSS files
Files:
frontend/components.d.tsfrontend/src/composables/__tests__/usePropertySelection.test.tsfrontend/auto-imports.d.tsfrontend/src/composables/usePropertySelection.tsfrontend/src/composables/__tests__/useStatementConfig.test.tsfrontend/src/composables/useStatementConfig.ts
**/*.test.{ts,tsx,js,jsx}
📄 CodeRabbit Inference Engine (.cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc)
Use
bun testinstead ofjestfor running tests
Files:
frontend/src/composables/__tests__/usePropertySelection.test.tsfrontend/src/composables/__tests__/useStatementConfig.test.ts
🧠 Learnings (8)
frontend/components.d.ts (13)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
Learning: Applies to src/**/*.vue : Use v-memo, shallowRef, markRaw, and Suspense for performance optimization
frontend/src/composables/__tests__/usePropertySelection.test.ts (6)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
Learning: Applies to src/composables/**/*.ts : Use composables for logic that is not global state
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
Learning: Applies to src/composables/**/*.ts : Place composables in the composables/ directory
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
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.153Z
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.706Z
Learning: Applies to src/composables/**/*.ts : Do not export store state from composables
frontend/auto-imports.d.ts (15)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
Learning: Applies to src/composables/**/*.ts : Use composables for logic that is not global state
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
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.706Z
Learning: Applies to src/composables/**/*.ts : Do not export store state from composables
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
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.706Z
Learning: Applies to src/composables/**/*.ts : Do not proxy or export Pinia store state/actions from composables
frontend/src/composables/usePropertySelection.ts (7)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
Learning: Applies to src/composables/**/*.ts : Use composables for logic that is not global state
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
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.706Z
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.706Z
Learning: Applies to src/composables/**/*.ts : Do not export store state from composables
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
Learning: Applies to src/**/*.vue : Props and emits must use explicit TypeScript interfaces
frontend/src/composables/__tests__/useStatementConfig.test.ts (3)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
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.706Z
Learning: Applies to src/**/*.vue : Use Pinia for state management in all Vue components
frontend/src/composables/useStatementConfig.ts (3)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
Learning: Applies to src/composables/**/*.ts : Use composables for logic that is not global state
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
Learning: Applies to src/composables/**/*.ts : Do not export store state from composables
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
Learning: Applies to src/**/*.vue : Use storeToRefs for state in components
frontend/src/components/PropertySelector.vue (10)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
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.706Z
Learning: Applies to src/**/*.vue : Prefer reactivity over computed unless necessary
frontend/.eslintrc-auto-import.json (9)
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
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/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.153Z
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.153Z
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.153Z
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/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
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.706Z
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.706Z
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.706Z
Learning: Applies to src/composables/**/*.ts : Use composables for logic that is not global state
🧬 Code Graph Analysis (1)
frontend/src/composables/usePropertySelection.ts (1)
frontend/auto-imports.d.ts (2)
PropertyReference(370-370)WikibaseDataType(370-370)
🔇 Additional comments (29)
.kiro/specs/wikibase-schema-editor/tasks.md (1)
96-96: Task completion accurately reflects the implemented feature.The marking of Task 16 as completed aligns with the property selection interface implementation shown in the other files.
frontend/.eslintrc-auto-import.json (1)
319-319: Auto-import configuration correctly added.The
usePropertySelectionentry is properly placed alphabetically and follows the established pattern for composable auto-imports.frontend/components.d.ts (1)
11-11: Global component declarations properly added.Both
AutoCompletefrom PrimeVue andPropertySelectorare correctly declared, enabling their use without explicit imports. The alphabetical ordering is maintained and the type declarations follow the established pattern.Also applies to: 31-31
frontend/src/components/StatementConfigEditor.vue (2)
15-18: Property selection handler properly implemented.The
handlePropertySelectionfunction correctly updates the current statement's property with the selected value, properly handling the nullablePropertyReferencetype.
30-40: UI consolidation improves user experience.The replacement of multiple manual property input fields with a single
PropertySelectorcomponent streamlines the interface. The grid layout change from 3 columns to 1 column is appropriate for the consolidated property selection approach.frontend/auto-imports.d.ts (1)
260-260: Global type declarations properly configured.The
usePropertySelectioncomposable is correctly declared in both the global constants section and Vue component custom properties section, enabling proper TypeScript support for auto-imports and template usage.Also applies to: 630-630
frontend/src/composables/__tests__/usePropertySelection.test.ts (3)
1-10: LGTM! Proper test setup with bun:test.The imports follow the coding guidelines correctly using
bun:test, and the beforeEach setup properly initializes the composable for isolated testing.
77-99: LGTM! Property selection tests cover core functionality.The tests properly verify the initial null state, property selection, and clearing functionality. The PropertyReference object structure matches the expected type definition.
12-75: Properties P31 and P279 confirmed; tests approvedVerified that
P31andP279are defined infrontend/src/composables/usePropertySelection.ts(in bothcommonPropertiesand thewikibase-itemarray), so the existing tests are valid and comprehensive.frontend/src/composables/__tests__/useStatementConfig.test.ts (7)
5-5: LGTM! Simplified import structure.The import simplification to only use
PropertyIdfrom backend types is appropriate and aligns with the test requirements.
25-25: LGTM! Updated to reflect new nullable property initialization.The test correctly expects
propertyto benullinitially, which aligns with the new default statement structure in the composable.
42-76: LGTM! Validation tests updated for nullable property structure.The tests now properly handle the property as an object or null, which aligns with the composable changes. The addition of the null property test case provides important validation coverage.
115-133: LGTM! Reset test updated for new property structure.The test correctly verifies that
propertyis reset tonull, which aligns with the new default statement structure.
135-165: LGTM! Simplified auto-save testing approach.Removing mocks and directly checking
store.statementsprovides a more direct test of the actual behavior. The explicit reset ensures clean test state.
167-193: LGTM! Consistent testing approach for invalid statements.The changes are consistent with the auto-save test and properly verify that invalid statements don't trigger auto-save.
195-222: LGTM! Manual save test follows consistent testing pattern.The test properly verifies manual saving functionality by directly checking the store state rather than using mocks.
frontend/src/components/PropertySelector.vue (5)
1-19: LGTM! Proper TypeScript interfaces for props and emits.The component correctly uses explicit TypeScript interfaces for props and emits as required by the coding guidelines. The prop structure with sensible defaults is appropriate for a reusable form component.
21-30: LGTM! Proper composable usage and display formatting.The component correctly uses the
usePropertySelectioncomposable and implements proper display formatting that handles cases where the property label might be undefined.
32-45: LGTM! Well-structured event handlers.The event handlers properly manage the autocomplete functionality with correct type annotations and appropriate emit patterns for property selection and clearing.
48-59: LGTM! Clean template structure with proper bindings.The AutoComplete component is properly configured with all necessary props and event handlers. The binding structure follows Vue best practices.
60-81: LGTM! Well-designed option rendering with proper fallbacks.The scoped slot provides excellent user experience with proper handling of cases where properties might not have labels. The visual design with tags and conditional styling is well-implemented.
frontend/src/composables/usePropertySelection.ts (4)
1-9: LGTM! Proper composable setup with good documentation.The imports are correct and the JSDoc documentation clearly describes the composable's purpose. The reactive state initialization follows Vue best practices.
90-103: LGTM! Well-implemented filtering with proper edge case handling.The filtering method correctly handles empty queries, implements case-insensitive search, and uses optional chaining to safely handle optional labels. The logic is robust and user-friendly.
105-112: LGTM! Clean selection management methods.The selection and clearing methods are simple and handle the expected use cases correctly with proper typing.
114-124: LGTM! Proper composable API design with readonly state.The return object follows Vue composable best practices by exposing state as readonly and organizing methods logically. This prevents external mutation of internal state while providing a clean API.
frontend/src/composables/useStatementConfig.ts (4)
11-19: LGTM! Good refactoring with centralized default statement creation.The
createDefaultStatementfactory function is a clean approach that centralizes default statement creation and aligns with the new nullable property structure. This improves maintainability and consistency.
25-25: LGTM! Clean initialization using factory function.Using the
createDefaultStatementfactory function for initialization is consistent and clean.
95-101: LGTM! Important safety improvement for null property handling.Adding the explicit check for
currentStatement.value.propertybeing truthy prevents potential runtime errors and makes the validation logic more robust for the nullable property structure.
118-142: Ensure removal of automatic reset is intentionalLGTM! The null-check guard in
saveCurrentStatementimproves safety, and using the factory inresetStatementmaintains consistency. However, I found no documentation or code references for automatic reset after saving, so please confirm this UX change is deliberate.• Searched
StatementConfigEditor.vueandschema.store.tsfor “reset” / “auto-save”
• No existing comments or logic enforcing auto-reset upon save
| // Data type specific property suggestions | ||
| const dataTypeProperties: Record<WikibaseDataType, PropertyReference[]> = { | ||
| string: [ | ||
| { id: 'P1476', label: 'title', dataType: 'monolingualtext' }, | ||
| { id: 'P2093', label: 'author name string', dataType: 'string' }, | ||
| { id: 'P1810', label: 'subject named as', dataType: 'string' }, | ||
| ], | ||
| 'wikibase-item': [ | ||
| { id: 'P31', label: 'instance of', dataType: 'wikibase-item' }, | ||
| { id: 'P279', label: 'subclass of', dataType: 'wikibase-item' }, | ||
| { id: 'P19', label: 'place of birth', dataType: 'wikibase-item' }, | ||
| { id: 'P27', label: 'country of citizenship', dataType: 'wikibase-item' }, | ||
| ], | ||
| time: [ | ||
| { id: 'P569', label: 'date of birth', dataType: 'time' }, | ||
| { id: 'P570', label: 'date of death', dataType: 'time' }, | ||
| { id: 'P577', label: 'publication date', dataType: 'time' }, | ||
| { id: 'P813', label: 'retrieved', dataType: 'time' }, | ||
| ], | ||
| quantity: [ | ||
| { id: 'P2043', label: 'length', dataType: 'quantity' }, | ||
| { id: 'P2044', label: 'elevation above sea level', dataType: 'quantity' }, | ||
| { id: 'P1082', label: 'population', dataType: 'quantity' }, | ||
| ], | ||
| url: [ | ||
| { id: 'P856', label: 'official website', dataType: 'url' }, | ||
| { id: 'P854', label: 'reference URL', dataType: 'url' }, | ||
| { id: 'P973', label: 'described at URL', dataType: 'url' }, | ||
| ], | ||
| commonsMedia: [ | ||
| { id: 'P18', label: 'image', dataType: 'commonsMedia' }, | ||
| { id: 'P41', label: 'flag image', dataType: 'commonsMedia' }, | ||
| { id: 'P94', label: 'coat of arms image', dataType: 'commonsMedia' }, | ||
| ], | ||
| 'external-id': [ | ||
| { id: 'P213', label: 'ISNI', dataType: 'external-id' }, | ||
| { id: 'P214', label: 'VIAF ID', dataType: 'external-id' }, | ||
| { id: 'P227', label: 'GND ID', dataType: 'external-id' }, | ||
| ], | ||
| 'globe-coordinate': [ | ||
| { id: 'P625', label: 'coordinate location', dataType: 'globe-coordinate' }, | ||
| ], | ||
| monolingualtext: [ | ||
| { id: 'P1476', label: 'title', dataType: 'monolingualtext' }, | ||
| { id: 'P1448', label: 'official name', dataType: 'monolingualtext' }, | ||
| ], | ||
| 'wikibase-property': [ | ||
| { id: 'P1687', label: 'Wikidata property', dataType: 'wikibase-property' }, | ||
| ], | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Data type organization is useful but has duplication concerns.
The data type-specific property organization is valuable for contextual suggestions. However, there's significant duplication with commonProperties, and the dataTypeProperties variable appears to be unused in the current implementation.
Consider either:
- Using
dataTypePropertiesin the filtering logic for contextual suggestions - Removing the unused mapping to reduce code complexity
- Combining both approaches with a unified property management system
Would you like me to help implement contextual property suggestions based on data type?
🤖 Prompt for AI Agents
In frontend/src/composables/usePropertySelection.ts between lines 35 and 84, the
dataTypeProperties object is defined but not used, causing duplication with
commonProperties and unnecessary code complexity. To fix this, integrate
dataTypeProperties into the property filtering logic to provide contextual
suggestions based on data type, or if not needed, remove dataTypeProperties
entirely to simplify the code. Optionally, refactor to unify commonProperties
and dataTypeProperties into a single property management system for better
maintainability.
Addresses Task 16 of #66