Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Pull request overview
This PR removes re-ordering support for collection-backed table data blocks by gating drag-and-drop / position-based reordering behind the RELATIONS source type.
Changes:
- Restricts DnD reordering UI (
DndContext,SortableItem,PositionBox) tosource.type === 'RELATIONS'. - Adjusts reorder helpers to use a computed
totalEntriesForReorderand to select which relations array to operate on.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
97bb092 to
f305a64
Compare
Remove collectionRelations/collectionLength props and SystemIds import that became unused after gating reorder to RELATIONS source type only. Simplify handleMove to use relations directly since the COLLECTION branch was unreachable.
Enable reordering for both COLLECTION and RELATIONS source types. Remove unused collectionRelations/collectionLength props and SystemIds import from the DnD items component.
…-for-collection-data-blocks' of https://github.com/EE-Solutions/geogenesis into fix/data-block-reorder-functonality-should-only-show-up-for-collection-data-blocks
…-for-collection-data-blocks' of https://github.com/geobrowser/geogenesis into fix/data-block-reorder-functonality-should-only-show-up-for-collection-data-blocks
…o fix/data-block-reorder-functonality-should-only-show-up-for-collection-data-blocks
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const movingRelation = relationsToUse.find(r => r.toEntity.id === currentRow?.entityId); | ||
|
|
||
| if (!movingRelation) return; | ||
|
|
||
| const allSortedRelations = [...collectionRelations].sort((a, b) => | ||
| const allSortedRelations = [...relationsToUse].sort((a, b) => | ||
| Position.compare(a.position ?? null, b.position ?? null) | ||
| ); |
| entries={entries} | ||
| onUpdateRelation={onUpdateRelation} | ||
| relations={relations ?? []} | ||
| collectionRelations={collectionRelations ?? []} | ||
| collectionLength={collectionLength} | ||
| pageNumber={pageNumber} | ||
| pageSize={pageSize} | ||
| shouldAutoFocusPlaceholder={shouldAutoFocusPlaceholder} |
| const canReorder = source.type === 'RELATIONS' || source.type === 'COLLECTION'; | ||
|
|
||
| const totalEntriesForReorder = relations?.length ?? sortableEntries.length; |
|
Closing as part of a sweep of the open-PR queue. Not a judgement on the work — reopen if you still want it and I will help get it current. Opened 2026-03-10 and now conflicting with master. At this distance a rebase is usually more work than redoing the change against current code, and the surrounding code has moved a long way underneath "fix: remove the re-order funcationality from collection data blocks". @b-d055 — if the idea still stands but the branch does not, a fresh PR or a ticket is probably a better route than reviving this one. Nothing is discarded: the branch and its history remain, and reopening costs a click. Context: 74 PRs were open, 25 older than two months, the oldest from February. The point is to make the queue mean something so genuinely ready work is visible rather than buried — #2449 sat ready for three days this week partly because of the noise. Only non-draft, conflicting PRs are in scope; drafts and anything still mergeable are being left alone. |
No description provided.