pull down to refresh

This is why, even on SN, I had no choice but to extend your script into full bliss mode, so that I can still function.

And you committed the deadly sin of not contributing upstream! I still notice when there’s a muted reply that my script nuked because the blast zone looks weird. I don't even want to know there was a muted reply.

// Run on initial page load
mutenuke();

this is the issue. I do :

window.addEventListener('load', () => {
  function runAfterHydration(callback) {
    requestAnimationFrame(() => {
      requestAnimationFrame(callback);
    });
  }

  runAfterHydration(mutenuke);
});

(I reverse engineered this by eye so test it)

reply
126 sats \ 4 replies \ @ek 7 Sep

Mhh, in the case of Brave Shields, I mention this scriptlet in the README:

window.addEventListener('DOMContentLoaded', () => {
    function mutenuke() {
        document
            .querySelectorAll('div[class*="comment_collapsed"]')
            .forEach(node => {
                if (node.textContent.startsWith('reply from someone you muted')) {
                    node.style = 'display: none';
                }
            }
        )
    }

    // Run on initial page load
    mutenuke();

    // Watch for dynamically loaded content
    const observer = new MutationObserver(mutenuke);
    observer.observe(document.body, { childList: true, subtree: true });
})

My userscript does not include the event listener. IIRC, the extension executes userscripts after the DOM has finished loading, so the listener shouldn't be needed. So I think this shouldn't be the issue, but I could of course be wrong.

Btw, since I realized we don't need API keys anymore with nsec authentication, I could, in theory, start writing a TUI as an alternative client, haha. Could be fun?

Edit: Oh, maybe you meant runAfterHydration(mutenuke)

reply

Ah but you don't have the post-hydration request in there? I don't remember why I had to nest requestAnimationFrame twice (see what I mean about maintainability?), but without that I got ugliness and now I have prettiness. So perhaps you only need that, not the event listener itself.

I could, in theory, start writing an alternative client as a TUI

Heh. Yes. I had that ever since I wrote the weekly AI posts tho. Locally cached too. Also not for sharing. And that wasn't for sharing over a year ago haha.

reply
126 sats \ 2 replies \ @ek 7 Sep
I don't remember why I had to nest requestAnimationFrame

I think @sox did something similar in SN's code to prevent the page from jumping around with live comments. Maybe that's where you got your inspiration from?

reply
111 sats \ 0 replies \ @sox 7 Sep

I got the idea from here (explanation is within the first minute from timestamp):

pretty cool trick tbh

reply

Potentially. This was months ago. It's not that important hehe.

reply

It's not shareable in terms of maintainability (neither was yours fwiw, it's basically just the concept that I still have now). I don't have much shareable code anymore at all because the bar for making code more useful in a state of being shared than not shared went up about 100x in the past 6 months. I have patches sitting in my forge for months waiting to be cleaned up then the problem gets refactored away upstream by some slop so I did all that for nothing anyway.

FOSS software is dying hard for me (I also quit my maintainer roles) and I am moving to bespoke-only. Protocols: awesome. Services: nah. Software: also nah.

reply