Alice Cheshire posted:

gwennie-chan posted:

Honestly this is confusing, because I specifically have it only execute sortjson() once the function containing pulljson() is completely done:

This isn't an outright solution but I'd recommend against using stuff like $.when().done(). Stuff like that can easily result in code not actually executing when you'd expect it. It'd be best to use events or maybe even timers (setTimeout or setInterval depending on whether you need a one time deal or a repeating deal respectively) instead in my experience.

https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener
https://developer.mozilla.org/en-US/docs/Web/Events
https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout
https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setInterval

Yeah well I have no idea what any of that means or how to use it. I can't even JS without jQuery.

So thank you cyricc for redesigning it to fix the error. I've merged your pull request.

last edited at Oct 22, 2017 7:38AM

gwennie-chan posted:

Yeah well I have no idea what any of that means or how to use it. I can't even JS without jQuery.

So thank you cyricc for redesigning it to fix the error. I've merged your pull request.

Well it sounds like it's fixed either way so it doesn't really matter but my personal suggestion would be to use document.onreadystatechange which is an event listener which can do different things depending on what stage of loading the page is at. Something like this:

document.onreadystatechange = function () {    
    if (document.readyState === "loading") { //Runs first    
        //Do something here    
    } else if (document.readyState === "interactive") { //Runs second    
        //Do something else here    
    } else if (document.readyState === "complete") { //Runs last    
        //Do a third thing here    
    }    
};    

This would allow you to make sure that certain code should always run before other code.

Edit: Though going back and looking back over your code now that I don't have a killer headache that may not actually do quite what you're wanting anyways.

last edited at Oct 22, 2017 1:23PM

Alice Cheshire posted:
Well it sounds like it's fixed either way so it doesn't really matter but my personal suggestion would be to use document.onreadystatechange which is an event listener which can do different things depending on what stage of loading the page is at. Something like this:

document.onreadystatechange = function () {    
    if (document.readyState === "loading") { //Runs first    
        //Do something here    
    } else if (document.readyState === "interactive") { //Runs second    
        //Do something else here    
    } else if (document.readyState === "complete") { //Runs last    
        //Do a third thing here    
    }    
};    

This would allow you to make sure that certain code should always run before other code.

With ES6 now being more or less standard if we ignore IE, I find promise chaining the simplest way to order asynchronous Javascript functions; they're worth looking into if you're writing stuff that depends on multiple AJAX requests and such. ES2017 introduces async-await constructs which are even cleaner, though I'd say still a bit too bleeding edge to be using just yet in public releases.

last edited at Oct 23, 2017 2:29AM

cyricc posted:

With ES6 now being more or less standard if we ignore IE, I find promise chaining the simplest way to order asynchronous Javascript functions; they're worth looking into if you're writing stuff that depends on multiple AJAX requests and such. ES2017 introduces async-await constructs which are even cleaner, though I'd say still a bit too bleeding edge to be using just yet in public releases.

That's probably true. I haven't messed with promises yet because I haven't really had anything I wanted to make that I thought would work well with them. They might be a bit complicated for gwennie-chan to figure out though if she's only able to use jQuery currently.

Just a note, anyone using the Mark Read userscript should update to the latest version. I've (finally) set up autoupdate to make this manual update process unnecessary in the future. More importantly, performance of release 2.0 has been greatly improved by use of caching (I actually got the idea from working on your script Alice, so thanks).

Read chapters should now mark more or less instantly in most cases, regardless of the length of the page or size of your list. The only caveat is that removal of chapters from your Read list may not always be detected immediately (additions always show immediately). The cache will naturally refresh as you browse around the site, so no special action is required if this happens.

last edited at Oct 24, 2017 5:17AM

cyricc posted:

Just a note, anyone using the Mark Read userscript should update to the latest version. I've (finally) set up autoupdate to make this manual update process unnecessary in the future. More importantly, performance of release 2.0 has been greatly improved by use of caching (I actually got the idea from working on your script Alice, so thanks).

Read chapters should now mark more or less instantly in most cases, regardless of the length of the page or size of your list. The only caveat is that removal of chapters from your Read list may not always be detected immediately (additions always show immediately). The cache will naturally refresh as you browse around the site, so no special action is required if this happens.

Hey cyricc. I have two potential requests for this userscript. I haven't actually looked at the underlying code so I don't know how reasonable either of these are but:

1.) Letting it work on list pages would be pretty helpful. For example some of Nechan's lists have a huge number of entries and for me at least there's a lot of shared entries. With so many entries it's really difficult to remember all of the ones I've read so I frequently come across ones that sound interesting but it turns out I've already read them.

2.) The other suggestion is to let it work on your to-read list as well, although for this one I'd suggest coloring them differently since they're not yet read. This actually comes up frequently with issues like the first one as well where a significant chunk of those that I haven't read are already on my to-read list to begin with.

Alice Cheshire posted:
Hey cyricc. I have two potential requests for this userscript. I haven't actually looked at the underlying code so I don't know how reasonable either of these are but:

1.) Letting it work on list pages would be pretty helpful. For example some of Nechan's lists have a huge number of entries and for me at least there's a lot of shared entries. With so many entries it's really difficult to remember all of the ones I've read so I frequently come across ones that sound interesting but it turns out I've already read them.

2.) The other suggestion is to let it work on your to-read list as well, although for this one I'd suggest coloring them differently since they're not yet read. This actually comes up frequently with issues like the first one as well where a significant chunk of those that I haven't read are already on my to-read list to begin with.

Sure, these suggestions should not be hard to implement at all. In fact #1 can be done by simply adding the lists url to the includes; I neglected to do so because I hadn't thought of that particular use case. #2 should be pretty easy after some refactoring to allow code reuse.

Alice, your suggestions have been implemented. Let me know here or on Github if you find any issues I missed.

cyricc posted:

Alice, your suggestions have been implemented. Let me know here or on Github if you find any issues I missed.

Awesome, thanks a lot!

cyricc, your Dynasty Markread only works for individual chapters. I can't have a whole grouping selected as Read and that inherit to individual chapters.

gwennie-chan posted:

cyricc, your Dynasty Markread only works for individual chapters. I can't have a whole grouping selected as Read and that inherit to individual chapters.

Hm, now this is a more challenging (but worthwhile) problem to solve. The script right now only marks entities directly corresponding to an entry in the list(s), or whose status appears as read/to_read/subscribed on the chapter page. Dynasty itself doesn't apply inheritance to groupings, which leads to the issue you mention. I can think of two general approaches at the moment, each with their own tradeoffs:

• Scrape each series/anthology entry in the Read list to get its member chapters, and mark those as well. Problem with this is that it could be expensive in terms of network requests if the list contains a large number of groupings. Caching could hide most resulting performance issues from the user, but the server would still get hammered in the background. Also introduces some possibly confusing inconsistency, i.e. all future chapters added to the series will immediately show as marked.

• Change the behavior of the Read button on series/anthology pages, such that adding/removing the series from Read does the same for every chapter on its page. Given that this has persistent effects beyond how pages are displayed, I would probably create a new userscript for this as I believe it is out of scope of this one. Problem with this method is that it would not apply retroactively; you would have to go through your list and re-add all your series.

I can't really say I have a strong preference toward either approach... possibly the second one by a slight margin. Any thoughts?

EDIT: hm, the performance issue with #1 could be alleviated by making cache reload more intelligently, and would also reduce the server load generated by the script as a whole... might work on that over the next few days, actually.

last edited at Nov 15, 2017 5:39PM

You could possibly handle series separately from normal network requests and have a fairly low time-limited throttle on the caching so it doesn't become a severe issue. It would just require more patience from the users for their list to update. Though you could potentially sidestep this issue somewhat for future requests, if you haven't already at least (I still haven't examined the code very closely yet), by adding event handlers to the add-to-list buttons that would immediately add/remove an entry from the corresponding script list.

Alice Cheshire posted:

You could possibly handle series separately from normal network requests and have a fairly low time-limited throttle on the caching so it doesn't become a severe issue. It would just require more patience from the users for their list to update. Though you could potentially sidestep this issue somewhat for future requests, if you haven't already at least (I still haven't examined the code very closely yet), by adding event handlers to the add-to-list buttons that would immediately add/remove an entry from the corresponding script list.

My current idea is similar; attach event handlers to the list buttons that invalidate or reload the cache. Your suggestion to update the list client-side would definitely have better performance, but I'm hesitant to sidestep the server with direct modifications to client-side state since that could lead to a number of challenging issues, particularly keeping state on multiple machines consistent with each other.

gwennie-chan, your suggestion has been implemented. That was a fun little project :)

Note that the mechanism for cache reloading has changed. To trigger the initial cache reload, remove or add an item from a list using the list drop down, then navigate to the front page or any chapter list.

cyricc posted:

My current idea is similar; attach event handlers to the list buttons that invalidate or reload the cache. Your suggestion to update the list client-side would definitely have better performance, but I'm hesitant to sidestep the server with direct modifications to client-side state since that could lead to a number of challenging issues, particularly keeping state on multiple machines consistent with each other.

Looks like you've already got a solution that'll work but it should be possible to use the event handler to set a temporary timer or something and wait for the server's feedback about the chapter state since adding/removing chapters doesn't change the symbol in the list until it gets feedback from the server.

cyricc posted:

gwennie-chan, your suggestion has been implemented. That was a fun little project :)

Note that the mechanism for cache reloading has changed. To trigger the initial cache reload, remove or add an item from a list using the list drop down, then navigate to the front page or any chapter list.

I can tell you it doesn't work at all on Firefox 58.

gwennie-chan posted:

I can tell you it doesn't work at all on Firefox 58.

I'm having no issues on FF57. I wonder though if there's not some issue with your install of Firefox. You're having issues with both this script as well as the Thingifier when it seems to be working fine for everyone else.

Ok so I finally stopped being lazy and deleted Greasemonkey and installed Tampermonkey. I was only using Thingifier and Title Rethingifier, but it seems the title thing is now part of the Thingifier? At least it works for me with just Thingifier installed. Rethingifier required being logged in on some other account on some other site or something so maybe that is the case? Though I'm not logged in there right now and I don't see anything expect for Greasemonkey active/installed on my firefox.

EDIT/ Nvm, I found it is still installed in scripts page. Well I'm not really good with it, so I thought thingifier was installed through Tampermonkey, but apparently Firefox has separate page from add-ons etc. for scripts and it instaled there through Tampermonkey? Either way my previous confusion was solved.

Speaking of it, I think the post for Thingifier should be updated. Sure the OP says you need to use Tampermonkey for both browsers, but the post that is linked there still says Firefox uses Greasemonkey and links to it, so if someone will miss that 1 line in main post, they can try to install Greasemonkey instead.

last edited at Nov 16, 2017 12:19PM

Also I have red 1 on top of Tampermonkey icon as if there was some message or something, but I can't find it anywhere, not to mention I can't even see all the options when I click on it, since for some time for some reason when I do, the window is not fit to what is inside, but has set size, even if it means cutting the part of content inside. I have the same issue with uBlock for some time.

Nevri posted:

I was only using Thingifier and Title Rethingifier, but it seems the title thing is now part of the Thingifier?

Yeah, as you realized later it's not. I do actually intend to roll it into the Thingifier eventually though. I just need to find the time and energy to deal with it is all.

Speaking of it, I think the post for Thingifier should be updated. Sure the OP says you need to use Tampermonkey for both browsers, but the post that is linked there still says Firefox uses Greasemonkey and links to it, so if someone will miss that 1 line in main post, they can try to install Greasemonkey instead.

Ah, I must have missed that when I fixed up the OP. I meant to completely remove Greasemonkey links.

Edit: Oh, I see why I overlooked it. That's because the OP link just links straight to Greasyfork's site instead.
Edit2: Ah wait, I thought you were talking about the Title Rethingifier but after logging into Greasyfork I see I was mistaken. I'll get the Thingifier post edited.

Nevri posted:

Also I have red 1 on top of Tampermonkey icon as if there was some message or something, but I can't find it anywhere, not to mention I can't even see all the options when I click on it, since for some time for some reason when I do, the window is not fit to what is inside, but has set size, even if it means cutting the part of content inside. I have the same issue with uBlock for some time.

That's just listing how many userscripts are active on the current page.

last edited at Nov 16, 2017 1:03PM

Alice Cheshire posted:

I do actually intend to roll it into the Thingifier eventually though. I just need to find the time and energy to deal with it is all.

Yea, I think it would be neat, since Thingifier already have so many functions so adding titles to it wouldn't be a stretch. But of course when you have time and energy x3

Edit2: Ah wait, I thought you were talking about the Title Rethingifier but after logging into Greasyfork I see I was mistaken. I'll get the Thingifier post edited.

Sorry for confusion. Yea, both names are kinda wonky, so Thingifier and Rethingifier can get mixed up easily.

That's just listing how many userscripts are active on the current page.

Ah ok. Thanks.

I can tell you it doesn't work at all on Firefox 58.

I haven't tried nightly, but it works for me on FF 56 and 57. Was it working for you before the update to the script?

cyricc posted:

I can tell you it doesn't work at all on Firefox 58.

I haven't tried nightly, but it works for me on FF 56 and 57. Was it working for you before the update to the script?

The old version before partially worked, but displayed the wrong link colors and was incomplete.

gwennie-chan posted:
The old version before partially worked, but displayed the wrong link colors and was incomplete.

I'm not able to reproduce the issue on Firefox 58 beta 4 (Windows/x64). I suspect your installation might have broken localStorage in some way, since the updated script relies on it now.

EDIT: I just came across this post which suggests your profile might be corrupted. You might want to try creating a new profile and seeing if that changes anything.

last edited at Nov 17, 2017 7:26AM

Holy hell is Mercurial infuriating as shit to actually get to cooperate when it comes to Github. I went and fixed a few minor issues on the Thingifier (quick quote cancel not clearing the text field and the unread posts link not appearing on series and anthology pages) and it wouldn't let me push the changes to Github because of gwennie-chan's outstanding merge request which I hadn't accepted due to the fact it still has a kinda major bug related to the own posts link never showing up. And of course after that even closing the request didn't allow me to push the changes as per usual when Mercurial starts erroring out. Luckily I found out I could manually update the file directly on Github I guess. Really irritating that this is even an issue though.