WaniKani Open Framework Library?

WaniKani API And Third-Party Apps
#1

First of all, I’m not very deeply familiar with userscripts, so apologies if this is a silly idea.

I dabbled with userscripts and GreasyFork a little bit now, and had an idea. How about using the WKOF as a library script instead of a prerequisite? Is there a reason why that’s not done? I tested it with a small script, and @require-ing the WKOF works even if the installed version is switched off.

From my understanding, if every script (that needs it) was to @require the (same version of the) WKOF, the script should only be loaded once and cached.

#2

I was using a setup like this, one problem is that every script will have its own instance of wkof. The userscripts are separated from each other, so you would have to make sure that the wkofs don’t interfere with each other while still communicating settings etc. across all scripts.

Another thing is that versioning in Tampermonkey is not great, it’s hard to ensure that all scripts use the newest version of wkof all the time.

2 Likes
#3

Are they really using separate instances? Because I think that when I required a certain jQuery version in a script earlier, other scripts suddenly had problems.

EDIT: I guess that’s because jQ adds things to window - as does WKOF.

#4

You can mess around with global objects, so you can override jquery for everyone for example. It depends on the rights you grant to the script.

With a global wkof you would need every script to run with full privileges, and make sure that you don’t override an existing wkof. I wouldn’t be too sure that there will never be race conditions where two scripts mess around with the wkof object at the same time.

I’m not saying your idea is impossible, but from my experience Tampermonkey is not well suited for interdependencies.

Additionally wkof does some nifty things with its own requirements … Don’t know if you can reproduce that inside of another script.

No idea what the ultimate reasons are, though :slight_smile:

1 Like
#5

Makes sense. I had hoped there would be a viable option for “utility” scripts. Seems pretty un-userfriendly to need them to be installed manually…

#6

I’m pretty sure the reasons @acm2010 outlined are the ones @rfindley had mentioned when he explained his reasoning for taking the prerequisite approach. Though surely it’s better for him to answer himself.