Original request from Discord – Discord
For blocks that contain a block reference linked to it, could we have LS prompt the user to confirm they want to delete the block? Currently its too easy to delete a block that contains at-least 1 block reference without realizing it.
Wanted to give a +1 to this. Helping users “fail gracefully” is a pretty critical UX pattern and there should definitely be a confirmation when a user is going to complete a destructive action, like deleting a block or page with existing references to it.
The current solution is “just be careful lol” but sometimes the level of care to get around this issue gets in the way of productivity:
(Here I place the reference immediately below the block being edited so you see it is being referred to)
I believe editing a block several levels deep without zooming all the way in is common, and necessary for productivity. So then you are in this situation where you are editing a block without knowing it is being referred to elsewhere.
Now you want to restructure your note (which should be an effortless activity for an outliner PKM app), you might want to
These very basic operations implicitly delete the blocks, change its UUID and break reference completely silently in the background and make your PKM useless.
I believe dragging the blocks would avoid the issue above, but it’s very clunky to drag 15-20 big blocks of text and images with 2000 words in them to a specific location in another page, and very error prone too.
The two blocks under 8.4.1 look like they aren’t being referred to elsewhere? so it’s ok to cut 8.4.1 together with other sections around it and paste to another page?
Nope, I did that and broke my references: look 1 level deeper, the references suddenly become visible!
So if you somehow get in the situation above, no amount of care can save you from breaking your block references.
Therefore I believe adding a prompt that says two things whenever implicit deletion, implicit recreating UUID happen:
“are you sure you want to delete these blocks?”
“the blocks being deleted are being referred to at these places…”
should be of highest priority
because one of the main reasons people use apps like logseq or Roam is atomic/block level references to link ideas, but quirks like this discourage people from using this fundamental operation.
That’s a very well written up use-case scenario, thanks for sharing that. Another thing that we have to also keep in mind is currently at this time there’s also a bug in Logseq (0.7.9) where it will not always display the block-ref indicator. This too can lead to accidental deletion, or breaking the block-ref if you are not careful or explicitly know if that block contains references.
This is part of my belief and reason I have been very vocal on discord about the need to get these type of bugs fixed. I know there is a lot of focus from the dev team to get major milestones completed like File Sync and Collaboration, but the tool at its core values needs to be rock solid to retain users, and in its current shape I feel this is not the case.
Link to the GH issue = Block Ref Indicator is missing from the references-blocks class · Issue #5375 · logseq/logseq · GitHub
When deleting referened block user should be somehow notified that there are some “broken” references in his graph.
It happened to me multiple times that i deleted some block that had some referenced sub-block and later on i wondered why i have some broken references…
reply from mod: Thank you for the feature request! For better tracking, I merged it with a similar post.
+1 I often accidentally delete block references and don’t notice it until much later.
Just get to this problem again =(
Related issue: Child block reference breaks with pressing delete ⌦ on the end of parent block · Issue #9218 · logseq/logseq · GitHub
It’s become frustrating as hell when I know something should be there and its simply not. Likely gone due to my own mistake not realizing I was deleting a block reference.
It’s been nearly 2 years since this was requested. Tienson even commented way back then that he liked the idea and he was going to link it to their roadmap. So where is it on the roadmap?
I think it’s a good feature to implement, although the counter for block references should work for similar purpose. I may add it to the build together project if there’s a similar ticket on GitHub.
Thanks @Junyi_Du for commenting. That’s certainly appreciated, the frustration was really around the lack of communication when there was initally interest and for an issue that was causing data to go missing. The block-ref indicator works fine but only if block is expanded and visible.
Meanwhile, I’m using this query for broken reference on default journal query, so at least I’m aware and can fix as soon it happens:
The solution I’ve always wanted for this is effectively:
If you’ve got a block referenced in 3 locations and the block is deleted, instead of simply breaking the earlier references, move the contents of the block to the oldest reference and update the other references to point to the new location.
This allows the other locations to still have the contents of the block but lets the user reorganize/restructure their notes without fear of breaking other notes.
the block-ref indicator is visible on collapsed blocks, but it’s not always visible due to this bug caused by lazy loading in long pages: References counter to the block references dont show in all the blocks (after 50 blocks) · Issue #6801 · logseq/logseq · GitHub
I’ve been migrating everything to Remnote at this point. I have found its ability to allow me to organize everything from the top-down as a big win, and not just that but it also gives me a nice big warning message if I try to delete a rem that contains a reference:
This is a huge drawback for me… I’ve just realized that a bunch of my block references are broken, with no way of knowing what was there…
+1
I’m surprised that a common issue that impacts data integrity and data loss isn’t being more actively addressed.
Figured out how to recover the data: grep 'id:: <block-ref>' logseq/bak/ folder for the ref id – logseq seems to insert the ref id as the value for the block property id:: whenever you copy a block reference, so even if deleted from current graph it should be in a backup page if it was deleted recently.
