Prompt user to confirm deleting block when an existing block reference is linked to the block

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.

1 Like

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:

  1. When your cursor is on a block, its number of references is completely hidden, like this:

(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

  • merge this block with its parent block to reduce complexity
  • cut 10 blocks including this one and paste them under another block in another page

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.

  1. There exists situation where the number of references is hidden even when the cursor is not on the block. Like this:

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.

1 Like

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

1 Like