spec(wikibase-schema-editor): add store auto-save functionality#123
spec(wikibase-schema-editor): add store auto-save functionality#123
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe changes update the design, requirements, and tasks documentation for the Wikibase Schema Editor to formalize an autosave architecture. All schema-editing actions now immediately update the local Pinia store, eliminating manual save/cancel buttons for individual elements. Only a single manual "Save to Server" button remains for backend persistence. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI Component
participant Pinia Store
participant Backend
User->>UI Component: Edit schema (e.g., term, statement, qualifier)
UI Component->>Pinia Store: Immediately update state (autosave)
Pinia Store-->>UI Component: State updated, mark as dirty
User->>UI Component: Click "Save to Server"
UI Component->>Backend: Persist schema changes
Backend-->>UI Component: Confirm save
UI Component->>Pinia Store: Update lastSyncedAt, clear dirty flag
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
✨ 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. 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
🔭 Outside diff range comments (5)
.kiro/specs/wikibase-schema-editor/requirements.md (2)
137-152: Requirement 10.8 is not achievable without persisted store“Retain all locally saved changes … when the user navigates away” requires persistence beyond in-memory Pinia. Amend requirement to explicitly mandate persisted state (e.g., localStorage/IndexedDB) or scope it to “within session” if persistence is out of scope.
Proposed rewording:
- 8. WHEN the user navigates away from the editor THEN the system SHALL retain all locally saved changes in the Pinia store + 8. WHEN the user navigates away or reloads THEN the system SHALL retain all locally saved changes using persisted local storage (e.g., IndexedDB/localStorage via Pinia persistence)
53-65: Clarify atomicity and validation messaging for autosave during statement editsThe current requirements specify immediate autosave (AC 7) and no save/cancel buttons (AC 8), but they don’t explain how partial or invalid edits are handled before a statement is “complete.” We need to define:
• Whether intermediate invalid states (e.g. property selected but value unmapped, or invalid data type) are persisted to the store
• How and when inline validation errors or warnings are displayed during multi‐step editsSuggested additional acceptance criteria:
- WHEN the user begins editing a Statement (selects property or maps values) THEN the system SHALL allow intermediate edits but SHALL NOT persist an incomplete or invalid Statement until all required fields are valid
- WHEN the user enters invalid data (e.g. mismatched type or missing property) THEN the system SHALL display inline validation messaging immediately and block autosave until the error is corrected
These criteria ensure clear rules around autosave atomicity and user feedback for partial edits.
.kiro/specs/wikibase-schema-editor/design.md (3)
137-159: Type definitions: include autosave fields or the store sample will not type-checkYou set schema.value.isDirty and lastSyncedAt later, but these fields aren’t part of the interface. Add optional fields to avoid TS errors.
Patch:
interface WikibaseSchemaMapping { id: string projectId: string name: string wikibase: string item: ItemSchemaMapping createdAt: string updatedAt: string - // Note: isDirty and lastSyncedAt may already exist in current implementation - // Only add if not already present in existing schema structure + // Autosave metadata + isDirty?: boolean + lastSyncedAt?: string }
623-698: Avoid mixing UseDraggable with native HTML5 drag-and-drop on the same elementUseDraggable manipulates element position for pointer dragging; HTML5 DnD uses ghost images and DataTransfer. Combining them can cause event quirks and UX jitter. Prefer HTML5 DnD without UseDraggable for data transfer here.
Suggested simplification:
- <UseDraggable v-slot="{ isDragging }" :initial-value="{ x: 0, y: 0 }" :prevent-default="true"> - <div class="column-chip" draggable="true" @dragstart="handleDragStart" @dragend="handleDragEnd">...</div> - </UseDraggable> + <div + class="column-chip cursor-grab active:cursor-grabbing" + draggable="true" + @dragstart="handleDragStart" + @dragend="handleDragEnd" + >...</div>
703-777: TermsEditor example: hard-coded 'en' and direct classList usage
- Don’t hard-code language ('en'); derive from current language selection in store/props.
- Avoid classList mutations; rely on reactive class bindings already present.
Patch snippet:
- handleColumnDrop('label', column, 'en') + handleColumnDrop('label', column, activeLanguage.value)And remove classList adds/removes in handlers; keep the reactive :class bindings only.
🧹 Nitpick comments (17)
.kiro/specs/wikibase-schema-editor/tasks.md (4)
210-216: Instrument TermsEditor autosave with debounce for text inputsAutosaving every keystroke to the store can thrash validation/reactivity. Add a task to debounce user typing (labels/descriptions/aliases) while still applying immediate updates for non-typing events (drops, selects).
Proposed addition:
+ - [ ] 35a. Debounce autosave for text inputs in TermsEditor + - Debounce 150–300ms while typing; immediate on blur/enter + - Update tests to assert batched store updates during typing + - _Requirements: 10.1, 10.2_
238-244: Verify manual backend sync compatibility via integration testsGood call-out. Add explicit integration tests covering dirty state clearing, lastSyncedAt updating, and rollback on failure while preserving local changes.
Proposed addition:
+ - [ ] 39a. Integration tests for manual sync + autosave + - Assert isDirty resets and lastSyncedAt updates on success + - Assert local store remains intact on failure; isDirty stays true + - _Requirements: 10.3, 10.4_
252-258: Initialize autosave at schema load/create with feature flag fallbackDocument a feature flag or safe rollout plan (env or store flag) to toggle autosave, enabling staged rollout/testing.
Proposed addition:
+ - [ ] 41a. Feature flag for autosave rollout + - Gate autosave mutations behind a config flag for staged rollout + - E2E tests for both modes (flag on/off) + - _Requirements: 9.4, 9.5, 9.8_
259-266: Expand test updates to cover performance and validation impactsUpdate tests to assert:
- Validation isn’t spuriously retriggered in tight loops during typing.
- Large schemas don’t regress performance with per-change autosave.
Proposed addition:
+ - [ ] 42a. Add performance/validation regressions tests + - Typing in terms does not trigger excessive validations + - Large schema (100+ statements) remains responsive + - _Requirements: 10.1, 8.1, 8.2_.kiro/specs/wikibase-schema-editor/requirements.md (6)
11-22: Avoid implementation-specific terms in requirementsReferencing “Pinia” in requirements couples UX expectations to a library. Consider phrasing as “local store” while keeping Pinia in design/tasks. This keeps requirements technology-agnostic.
39-50: Define language selection behavior for term mapping autosaveClarify how the active language is determined on drop, and what happens on multilingual fields (multiple aliases). Acceptance criteria should cover current language context and defaulting rules.
68-79: Rank changes: validation and constraintsAdd acceptance criteria for constraints like “at least one normal/preferred rank exists” if relevant, and expected behavior when changing ranks rapidly under autosave.
82-93: Qualifiers autosave: ordering and deduplicationClarify whether qualifier order matters and how duplicates (same property/value) are handled. Add criteria for these cases.
96-107: References autosave: required fields and validityAdd criteria for minimally valid references (e.g., require P248 or P854?) and behavior when partial/incomplete reference data is autosaved.
124-136: Schema selection: autosave enablement in read-only contextsConfirm that viewing an existing schema in a read-only context does not autosave. If read-only mode exists, add acceptance criteria.
.kiro/specs/wikibase-schema-editor/design.md (7)
47-55: Root container responsibilities: add unsynced changes indicatorInclude an indicator (badge/toast) when isDirty is true to remind users they have changes not yet saved to the server.
430-437: State management: note on debouncing and watchersAutosaving on every change can over-trigger validations and derived computations. Document debouncing for text fields and microtask batching for store updates where appropriate.
438-456: Two-level autosave: clarify dirty clearing and sync timestampsDocument when isDirty clears (after successful sync) and how lastSyncedAt updates. Include behavior on sync error (keep isDirty true).
472-478: Backend integration unchanged: confirm optimistic updates don’t double-applySince autosave is local-only, ensure existing optimistic update logic in sync doesn’t re-run local mutations redundantly. Note this explicitly.
782-833: Validation composable: broaden compatibility map and centralize typesPut the compatibilityMap in a single source (e.g., validation constants) and cover more Wikibase types (external-id, monolingualtext, url, globe-coordinate). Add tests to prevent drift.
838-874: Drag store: compute valid targets reactively rather than storing stringsKeep validDropTargets as a computed derived from draggedColumn + schema shape, not an eagerly stored array, to reduce state divergence.
536-544: Minor copy edit: repeated ‘immediately’There’s adverb repetition in these bullet points. Tighten wording to improve readability.
Suggested edit:
- - Drop zones immediately apply mappings on drop - - Property selectors immediately update on selection - - Rank dropdowns immediately update on change - - Language selectors immediately update on change - - Add/remove buttons immediately modify arrays + - Drop zones apply mappings on drop + - Property selectors update on selection + - Rank dropdowns update on change + - Language selectors update on change + - Add/remove buttons modify arrays
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.kiro/specs/wikibase-schema-editor/design.md(5 hunks).kiro/specs/wikibase-schema-editor/requirements.md(8 hunks).kiro/specs/wikibase-schema-editor/tasks.md(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-07-20T14:13:24.706Z
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
Applied to files:
.kiro/specs/wikibase-schema-editor/design.md
📚 Learning: 2025-07-20T14:13:24.706Z
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
Applied to files:
.kiro/specs/wikibase-schema-editor/design.md
📚 Learning: 2025-07-20T14:13:24.706Z
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
Applied to files:
.kiro/specs/wikibase-schema-editor/design.md
📚 Learning: 2025-07-20T14:13:24.706Z
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
Applied to files:
.kiro/specs/wikibase-schema-editor/design.md
🪛 LanguageTool
.kiro/specs/wikibase-schema-editor/design.md
[style] ~538-~538: This adverb was used twice in the sentence. Consider removing one of them or replacing them with a synonym.
Context: ...y mappings on drop - Property selectors immediately update on selection - Rank dropdowns im...
(ADVERB_REPETITION_PREMIUM)
[style] ~541-~541: This adverb was used twice in the sentence. Consider removing one of them or replacing them with a synonym.
Context: ...y update on change - Add/remove buttons immediately modify arrays - No confirmation dialogs...
(ADVERB_REPETITION_PREMIUM)
🔇 Additional comments (2)
.kiro/specs/wikibase-schema-editor/design.md (2)
76-83: SchemaCanvas: avoid mixed class manipulation and bindingsExamples later use both classList mutations and Vue class bindings for DnD feedback. Prefer reactive class bindings only to avoid divergence and flicker.
⛔ Skipped due to learnings
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 necessaryLearnt 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 componentsLearnt 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 dataLearnt 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 errorsLearnt 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 optimizationLearnt 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 : No inline style attributes in templatesLearnt 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 : Do NOT use custom CSS in <style> blocks except with explicit approvalLearnt 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 Tailwind CSS utility classes for all styling; Tailwind is mandatory for all stylingLearnt 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 componentsLearnt 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
171-188: No duplicate StatementSchemaMapping in design.md
The design spec only references the backend’sStatementSchemaMappingtype—it does not declare its own. There is no conflicting interface in.kiro/specs/wikibase-schema-editor/design.md, so no renaming or consolidation is needed.Likely an incorrect or invalid review comment.
| #### Component-Level Autosave | ||
| ```typescript | ||
| // Example: TermsEditor autosave pattern | ||
| const handleTermMapping = (termType: string, language: string, columnMapping: ColumnMapping) => { | ||
| // Immediately update Pinia store - no save button needed | ||
| schemaStore.updateTermMapping(termType, language, columnMapping) | ||
|
|
||
| // Mark schema as dirty for backend sync | ||
| schemaStore.markDirty() | ||
| } | ||
|
|
||
| // Example: StatementEditor autosave pattern | ||
| const handlePropertySelection = (statementId: string, property: PropertyReference) => { | ||
| // Immediately update Pinia store - no save button needed | ||
| schemaStore.updateStatementProperty(statementId, property) | ||
|
|
||
| // Mark schema as dirty for backend sync | ||
| schemaStore.markDirty() | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Store sample: missing comma and defensive guards
There’s a missing comma after markDirty in return. Also, ensure nested paths exist before assignment to terms[termType][language].
Patch:
export const useSchemaStore = defineStore('schema', () => {
const schema = ref<WikibaseSchemaMapping | null>(null)
const updateTermMapping = (termType: string, language: string, mapping: ColumnMapping) => {
if (!schema.value) return
- // Immediate store update
- schema.value.item.terms[termType][language] = mapping
+ // Ensure term bucket exists
+ const terms: any = schema.value.item.terms as any
+ terms[termType] ||= {}
+ // Immediate store update
+ terms[termType][language] = mapping
schema.value.isDirty = true
schema.value.updatedAt = new Date().toISOString()
}
const markDirty = () => {
if (schema.value) {
schema.value.isDirty = true
}
}
return {
schema: readonly(schema),
updateTermMapping,
- markDirty
+ markDirty,
// Note: syncToBackend already exists in current implementation
}
})📝 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.
| #### Component-Level Autosave | |
| ```typescript | |
| // Example: TermsEditor autosave pattern | |
| const handleTermMapping = (termType: string, language: string, columnMapping: ColumnMapping) => { | |
| // Immediately update Pinia store - no save button needed | |
| schemaStore.updateTermMapping(termType, language, columnMapping) | |
| // Mark schema as dirty for backend sync | |
| schemaStore.markDirty() | |
| } | |
| // Example: StatementEditor autosave pattern | |
| const handlePropertySelection = (statementId: string, property: PropertyReference) => { | |
| // Immediately update Pinia store - no save button needed | |
| schemaStore.updateStatementProperty(statementId, property) | |
| // Mark schema as dirty for backend sync | |
| schemaStore.markDirty() | |
| } | |
| ``` | |
| export const useSchemaStore = defineStore('schema', () => { | |
| const schema = ref<WikibaseSchemaMapping | null>(null) | |
| const updateTermMapping = (termType: string, language: string, mapping: ColumnMapping) => { | |
| if (!schema.value) return | |
| // Ensure term bucket exists | |
| const terms: any = schema.value.item.terms as any | |
| terms[termType] ||= {} | |
| // Immediate store update | |
| terms[termType][language] = mapping | |
| schema.value.isDirty = true | |
| schema.value.updatedAt = new Date().toISOString() | |
| } | |
| const markDirty = () => { | |
| if (schema.value) { | |
| schema.value.isDirty = true | |
| } | |
| } | |
| return { | |
| schema: readonly(schema), | |
| updateTermMapping, | |
| markDirty, | |
| // Note: syncToBackend already exists in current implementation | |
| } | |
| }) |
🤖 Prompt for AI Agents
In .kiro/specs/wikibase-schema-editor/design.md around lines 481 to 500, the
sample code for the store's autosave pattern is missing a comma after the
markDirty method in the return statement, and it lacks defensive checks before
assigning to nested paths like terms[termType][language]. Fix this by adding the
missing comma after markDirty and adding checks to ensure that terms[termType]
and terms[termType][language] exist before assignment, initializing them if
necessary to avoid runtime errors.
| - [ ] 34. Implement autosave functionality in schema store | ||
| - Write tests for immediate Pinia store updates on all schema changes | ||
| - Write tests for isDirty flag management and lastSyncedAt tracking | ||
| - Write tests for automatic store persistence without manual save operations | ||
| - Implement autosave mutations in schema store for all schema operations | ||
| - _Requirements: 10.1, 10.2, 10.8_ | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add explicit persistence strategy for "retain on navigation" requirement
Tasks omit implementing persisted local storage, yet Requirement 10.8 expects local changes to survive navigation. Add a task to enable persisted Pinia state (e.g., pinia-plugin-persistedstate or IndexedDB/localStorage) and tests for reload/navigation scenarios.
Proposed addition:
+ - [ ] 34a. Implement persisted local store for autosave
+ - Use pinia-plugin-persistedstate (or IndexedDB) to persist schema state
+ - Write tests verifying state survives route changes and page reloads
+ - Ensure security: avoid persisting sensitive tokens
+ - _Requirements: 10.8_📝 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.
| - [ ] 34. Implement autosave functionality in schema store | |
| - Write tests for immediate Pinia store updates on all schema changes | |
| - Write tests for isDirty flag management and lastSyncedAt tracking | |
| - Write tests for automatic store persistence without manual save operations | |
| - Implement autosave mutations in schema store for all schema operations | |
| - _Requirements: 10.1, 10.2, 10.8_ | |
| - [ ] 34. Implement autosave functionality in schema store | |
| - Write tests for immediate Pinia store updates on all schema changes | |
| - Write tests for isDirty flag management and lastSyncedAt tracking | |
| - Write tests for automatic store persistence without manual save operations | |
| - Implement autosave mutations in schema store for all schema operations | |
| - _Requirements: 10.1, 10.2, 10.8_ | |
| - [ ] 34a. Implement persisted local store for autosave | |
| - Use pinia-plugin-persistedstate (or IndexedDB) to persist schema state | |
| - Write tests verifying state survives route changes and page reloads | |
| - Ensure security: avoid persisting sensitive tokens | |
| - _Requirements: 10.8_ |
🤖 Prompt for AI Agents
In .kiro/specs/wikibase-schema-editor/tasks.md around lines 203 to 209, the
autosave functionality tasks lack implementation of persisted local storage
required by Requirement 10.8 to retain state across navigation. Add a task to
enable persisted Pinia state using a persistence plugin or
localStorage/IndexedDB, and include tests verifying state retention after page
reloads or navigation events.
| - [ ] 36. Remove save/cancel buttons from StatementEditor component | ||
| - Write tests for immediate statement configuration updates without save buttons | ||
| - Write tests for automatic property selection and rank changes persistence | ||
| - Remove save/cancel buttons from StatementEditor interface | ||
| - Update StatementEditor to use autosave store mutations | ||
| - _Requirements: 4.7, 4.8, 5.6, 5.7, 10.5_ | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Cover undo/redo or revert workflows after removing save/cancel
With save/cancel removed, users need a way to revert unintended edits. Add a small history/undo task (store-level snapshot stack) and tests.
Proposed addition:
+ - [ ] 36a. Provide undo/redo for autosaved edits
+ - Implement lightweight history (bounded stack) in store
+ - Keyboard shortcuts and UI affordance
+ - Tests for reverting terms/statements/qualifiers/references
+ - _Requirements: 10.1, 10.2_📝 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.
| - [ ] 36. Remove save/cancel buttons from StatementEditor component | |
| - Write tests for immediate statement configuration updates without save buttons | |
| - Write tests for automatic property selection and rank changes persistence | |
| - Remove save/cancel buttons from StatementEditor interface | |
| - Update StatementEditor to use autosave store mutations | |
| - _Requirements: 4.7, 4.8, 5.6, 5.7, 10.5_ | |
| - [ ] 36. Remove save/cancel buttons from StatementEditor component | |
| - Write tests for immediate statement configuration updates without save buttons | |
| - Write tests for automatic property selection and rank changes persistence | |
| - Remove save/cancel buttons from StatementEditor interface | |
| - Update StatementEditor to use autosave store mutations | |
| - _Requirements: 4.7, 4.8, 5.6, 5.7, 10.5_ | |
| - [ ] 36a. Provide undo/redo for autosaved edits | |
| - Implement lightweight history (bounded stack) in store | |
| - Keyboard shortcuts and UI affordance | |
| - Tests for reverting terms/statements/qualifiers/references | |
| - _Requirements: 10.1, 10.2_ |
🤖 Prompt for AI Agents
In .kiro/specs/wikibase-schema-editor/tasks.md around lines 217 to 223, after
removing the save/cancel buttons from the StatementEditor component, add a new
task to implement undo/redo or revert functionality to allow users to revert
unintended edits. Specifically, introduce a store-level snapshot stack to manage
history and write corresponding tests to cover these undo/redo workflows.
| - [ ] 40. Update drag-and-drop operations to use autosave | ||
| - Write tests for immediate store updates on column drop operations | ||
| - Write tests for automatic mapping persistence without confirmation dialogs | ||
| - Update all drop zone handlers to use autosave store mutations | ||
| - Remove any remaining save/cancel patterns from drag-and-drop workflows | ||
| - _Requirements: 10.1, 10.2, 10.5_ | ||
|
|
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Automate removal of legacy save/cancel UI
Add a task (with a script) to detect any lingering “Save”/“Cancel” buttons and confirmation dialogs in target editors and DnD flows.
Script to run:
🏁 Script executed:
#!/bin/bash
# Find lingering save/cancel patterns in components
rg -n -S --glob "src/**/*.vue" --glob "src/**/*.ts" \
-e '\bSave\b' -e '\bCancel\b' -e 'confirm\(' -e 'confirmDialog' \
-e 'onConfirm' -e 'saveToServer' -e 'save/cancel' -A2 -B2Length of output: 316
🏁 Script executed:
#!/bin/bash
# Retry searching for lingering save/cancel patterns across the entire repo
rg -n --no-ignore \
-e '\bSave\b' -e '\bCancel\b' \
-e 'confirm\(' -e 'confirmDialog' \
-e 'onConfirm' -e 'saveToServer' -e 'save/cancel' \
-A2 -B2Length of output: 5827
Remove all legacy Save/Cancel UI elements
We ran the detection script and confirmed multiple “Save”/“Cancel” buttons and confirmation dialogs remain. Please remove or replace them with the new autosave-driven patterns in the following locations:
• frontend/src/features/wikibase-schema/components/StatementEditor.vue (labels “Cancel” at line 297, “Save” at line 303)
• frontend/src/features/wikibase-schema/components/SchemaSelector.vue (label “Cancel” at line 79)
• frontend/src/features/wikibase-schema/components/ReferencesEditor.vue (label “Cancel” at line 500)
• frontend/src/features/wikibase-schema/components/QualifiersEditor.vue (label “Cancel” at line 417)
• frontend/src/features/project-management/composables/useProjectListComposable.ts (rejectProps label “Cancel” at line 13)
• frontend/src/features/wikibase-schema/components/WikibaseSchemaEditor.vue (save-button helpers at lines 178–183)
• backend/src/api/project/index.ts (legacy “Save file to temporary location” logic at lines 94–96)
• API.md (endpoints under /command/core/cancel-*)
Update each component to use the autosave store mutations and remove any manual save/cancel or confirm dialogs.
🤖 Prompt for AI Agents
In .kiro/specs/wikibase-schema-editor/tasks.md around lines 245 to 251, the
legacy Save/Cancel UI elements and confirmation dialogs remain in multiple
frontend components and backend logic. Remove or replace all "Save" and "Cancel"
buttons and dialogs in the specified files and lines with autosave-driven
patterns by updating the components to use autosave store mutations. Also,
eliminate manual save/cancel logic in backend/src/api/project/index.ts lines
94-96 and remove related endpoints in API.md under /command/core/cancel-*.
Ensure all drag-and-drop and editing workflows rely solely on autosave without
manual confirmation.
1 participant
No description provided.