I personally prefer this approach. In my opinion it is out of scope for Open Framework to always inject jQuery, no matter if it’s needed or not.
I’m wondering if with the transition away from jQuery, they will also switch from jStorage to something else. That might become the bigger problem for unmaintained scripts.
I haven’t spent much time thinking about it, but… how?
Userscripts rely on @run-at, which, as far as I know, is inevitably asynchronous. You can use @run-at document-start and immediately add a script tag, but I think it will still potentially run other userscripts while jquery is loading.
Agreed. That’s why it only loads it if a script explicitly requests it via wkof.include('Jquery');
Agreed. Fortunately, most of jStorage is directly replaceable with localStorage. The exception, as far as I know, is the StorageEvent if a key is changed from within the same tab. I think it only fires if it’s changed from another tab.
But again, we can patch jstorage in if needed.
I think it should be synchronous by using
// @require https://ajax.googleapis.com/ajax/libs/jquery/3.6.1/jquery.min.js
In that case Tampermonkey has already downloaded the jquery file and just pastes it into the userscript before injecting the entire thing, so I think it should be immediately available.
True, but every script would load another copy, I think. And not necessarily the same version.
It seems that at least with Tampermonkey/Violentmonkey in Chromium/Firefox, the @required jQuery gets installed into the page context. What I meant was that the @require method can probably be used for the “Install Jquery” userscript approach:
// ==UserScript==
// @name WaniKani jQuery Injector
// @namespace jQueryInjector
// @version 3.6.1
// @description Injects jQuery into every WaniKani page to ensure backwards compatibility.
// @license MIT-0
// @match https://www.wanikani.com/*
// @require https://ajax.googleapis.com/ajax/libs/jquery/3.6.1/jquery.min.js
// @run-at document-start
// @grant none
// ==/UserScript==
With this, jQuery should be immediately available to every script injected afterwards.
Ahh, I see. Yeah, that would work, though you’d want to @exclude the pages that still have WK’s jquery, and monitor for when the excluded pages drop jquery. (And, of course, it would need to be in the #1 script position).
To sum it up we need a volunteer to write and publish the “Install Jquery” script. This person should maintain the @exclude directive according to the actual use of Jquery by Wanikani. This volunteer shall not be me. Who volunteers?
When this is done @rfindley should remove his installation of Jquery from the Settings module and rely on the “Install Jquery” script instead.
Does this sound like a plan?
I’ll leave it in wkof, because it’s only going to install jquery if scripts request it and it’s not already present. It’s compatible with @Sinyaven’s solution.
And that way I won’t have to change every script thread to instruct people to install yet another script 
I like the combination. Script authors who use WKOF can just add it through WKOF, authors who don’t can switch to the native API or instruct users to install the script. For unmaintained scripts we can instruct users to install the jquery script.
I don’t want to add another installation step for my users so I’ll just use WKOF or switch to the native API
How important is this really?
I don’t know for sure these days, but I remember some past experiences where two copies of jquery were causing havoc. The second copy overwrote the first, and event handlers got lost in the process. Depending on startup timing, you’d encounter different issues.
That could cause havoc to users who need both a script using wkof and a script that @require Jquery. My preference is to have only one standard install mechanism for all scripts to avoid dual install issue. How about to @require Jquery from wkof?
Edit: On a second thought the current wkof don’t use an exclude mechanism for the WK pages that still use Jquery. Don’t you expect the same problem to show up?
No, wkof will never load jquery if it’s already present.
Maybe this is what’s confusing you:
wkof.include('Jquery');
This doesn’t actually load jquery. It loads a tiny piece of code that checks if the jquery library is present.
If jquery is already present, wkof just sends a ‘ready’ event to let scripts know that jquery is ready to use. If jquery is not already present, it loads jquery, then sends the ‘ready’ event.
I only want to load jquery when it’s needed. If I @require it from wkof, it will load every time you click a link. Granted, it will load it from cache, but still… it takes a little bit of time for jquery to initialize.
wkof is designed to only load what is needed, and only when requested. For example, Self-Study Quiz doesn’t do a wkof.include('Settings') until the user clicks the Open Settings link. So, it cuts down on page-load time.
Hi. I’ve run into an issue here:
if (event.target.result === undefined) {
load_promise.reject(name);
} else {
load_promise.resolve(event.target.result.content);
}
event.target.result can also be null so all my scripts started to crash.
I’ve changed it to:
if (event.target.result === undefined || event.target.result === null) {
load_promise.reject(name);
} else {
load_promise.resolve(event.target.result.content);
}
and now it works for me.
Don’t sure if it is the fault of this framework, but item loading notification blocks the way. The Internet connection was bad at the time.
study_materials keeps loading.
You can close them by clicking on the X or drag them away by clicking and dragging the top grey bar.
The dialog appears only briefly (5 seconds or so), but repeatedly (even at 4/5 of new lesson reviewing batch, for example).
Also, clicking outside the text box would remove the blinking cursor from text box, that is, changing the focus.
The ‘loading’ box pops up any time a script is trying to fetch data and the server takes longer than 2sec to respond. So, you are running a script that is accessing study_materials, and for some reason WK’s server is slow to respond. Maybe the script is asking for too much data, or it’s just the bad internet connection like you said.
A few months ago, I added a feature to allow users to disable the popup. In your Javascript console (press F12 and click the Console tab), type the following while on wanikani:
wkof.include('Progress');
wkof.Progress.popup_delay(-1);
If you ever want to restore it:
wkof.include('Progress');
wkof.Progress.popup_delay('default');
Alternatively, if you know which script is loading data, you could request that the script author add a flag in their script to disable the popup just for their script. (They just need to add “disable_progress_dialog: true” to the options when fetching data).
[edit: oops, I corrected the code above to -1 for the popup delay to disable it.]
This might have been my Lesson User Synonyms 3 script. It fetches the user synonyms for the current item every time they need to be displayed without caching them. I’m not sure if I want to add caching functionality, but I can at least add the disable_progress_dialog: true setting.