NotificationBlock: Better handling of blockable trail items

[marcustyphoon]

No matter if it winds up being the reason behind #491 or not, the fact that NotificationBlock only blocks notes from the particular reblog you clicked on is definitely confusing, in my opinion, when the post in question contains trail items/a root item that you would receive notifications for.

It seems easy to detect whether this is the case (though perhaps this needs special handling for group blogs - do you get notifications about posts that a member of one of your group blogs created? I assume no?):

const { trail } = await timelineObjectMemoized(id);
const isBlockable = ({ blog, post: id }) => blog?.isMember && blockedPostTargetIDs.includes(id) === false;
if (trail.some(isBlockable)) {
  // ...
}

Question is, what to do about it? I can think of three options to add to the modal (besides providing an explanation):

1. Add an additional button that blocks the ids of every relevant item in the trail instead of just this posts's ID.
2. Just always block the ids of every relevant item in the trail. (This seems like what almost everyone would want in almost every situation, in my mind, but it makes the unblocking process non-obvious.)
3. Just provide an explanation and let the user click through and block everything if they want to. (This feels kind of easy to miss, IMO, and it's quite clunky.)

I started on a demo of the third option (and spent far too many lines on grammar, but that can be refined later if this is your desired path):

https://github.com/AprilSylph/XKit-Rewritten/compare/master...marcustyphoon:notificationblock-handle-previous?expand=1

But, what do you think? I think I would definitely lean towards 1 or 2.

(As an aside, I think it would be much easier to understand what's going on if there were a visual indicator on posts - and, given the behavior brought up here, trail items - whose notifications have been blocked. This would be a piece of cake to code, but finding an elegant place for the indicator if this did include trail items is definitely nontrivial. But the amount of UI clutter added seems really small considering how few posts this would affect.)

[AprilSylph]

do you get notifications about posts that a member of one of your group blogs created?

Yes. A blog's activity feed is the same for all members.

[AprilSylph]

Not exactly on-topic, but your destructuring there is renaming post to id instead of destructuring id from post.

- const isBlockable = ({ blog, post: id }) => blog?.isMember && blockedPostTargetIDs.includes(id) === false;
+ const isBlockable = ({ blog, post: { id } }) => blog?.isMember && blockedPostTargetIDs.includes(id) === false;

[marcustyphoon]

...Whoops. (I also realized that there ought to be a bunch of defaults in there; malformed NPF doesn't seem particularly uncommon. I admit that when I code for myself I often prefer not destructuring in these kinds of cases because of the ease/clarity of optional chaining everything and then not having to worry about "cannot destructure property of undefined.")

[AprilSylph]

I think the best solution would be to detect in the confirmation window if the post about to be blocked is a reblog, and display an additional warning about blocking a reblog's notifications.

To go further, there's also the inverse problem - if you block the original post's notifications, you'll still see notifications if those notifications are for your own reblog of that post (since they have different target IDs). So I would say there needs to be a warning either way, but what it says depends on whether the post you're blocking notifications on is a reblog or not.

[marcustyphoon]

...though this does break any currently-blocked reblogs unless we write both IDs into separate data attributes (or something) in order to keep them working, which is a bit unfortunate.

[AprilSylph]

It does, but I would hazard a guess that the case where you want to block specific reblogs' notifications is essentially nonexistent.

[AprilSylph]

Working on this now. Hit a bit of a speedbump, though: the filter functions for meatball items are synchronous-only, and only the post id is exposed in the DOM, so I'll need to do some work on the meatballs util to keep the "Block notifications"/"Unblock notifications" button behaviour intact.

[marcustyphoon]

"Oh, I have a solution for that: all you have to do is make timelineObject synchronous by communicating the payload via DOM mutation,,,"

Joking, joking :D Awesome! I think this behavior will line up well with user expectations.

[AprilSylph]

Just pushed 6fd9963 to implement a pure root ID-only approach.