Wanikani Open Framework [developer thread]

Was reading this new feature (wiping local storage after seven days of inactivity) for WebKit. I think the framework runs off of Indexed DB? Don’t know how it’ll affect the framework. Just wanted to give a heads up.


Well, time for WebKit to also implement “vacation mode” :rofl:

1 Like

Thanks for the heads-up!

Fortunately, it sounds like data doesn’t get wiped if the user uses the site within 7 days.
If someone goes longer than that, Open Framework will auto-repopulate its data, including API key. So, you may see a small up-tick in WK API usage. Probably not enough to notice, but if you guys have any issues, let me know.

Do you think this is a good idea?

1 Like

I suppose it would be best to follow Wanikani’s convention on how SRS stages are named (…if they continue to be named, which I assume they will).

1 Like

Did you miss the SRS announcement on June 17th? Due to adding multiple SRS systems with possibly varying numbers of categories, all names will be dropped.

I saw it, but I only skimmed the announcement since I’ve been neck-deep in project deadlines.

I had noticed that the stage names were not in the new API endpoint, but (as Viet said) I know they are fond of naming things – which is also a good thing for usability – so I hadn’t considered that they might discontinue the names.

I’ll still stick to my statement, though: It’s probably best to follow Wanikani’s convention. If they don’t plan to support names, then we (scripters) would likely be setting ourselves up for some headaches down the road if we try to sustain the names in the Framework and scripts. For example, new users will be confused as to what the names are referring to. And if, at some point, a future SRS stage-numbering system doesn’t align cleanly with the current names, then it will be an even messier cleanup.


It makes sense why you would want to do that! They definitely do seem like they plan to do something like that “future… numbering system”

1 Like

Seems to me that such a feature would be outside the scope of the framework. It’s a problem better solved with other scripts.

Also, thank you for the file cache methods. I am looking to store minified review data in IndexedDB for the heatmap and it makes things so much easier.


Suggestion: let settings inherit path properties.
To keep the Heatmap settings ordered, I override all setting paths. Although it’s not a big deal to add the path to all settings, it would be simpler if I could put the path on a higher level item. In this case it would be nice if I could just put path: '@lessons' in the page config, and it would automatically place the contained settings in that path.


Came upon this issue again with the new version of the Heatmap, haha. Good thing I could look back at this and be reminded why it wasn’t working as I expected. Ended up just wrapping my pre_open function and refreshing before it was called. A much better solution than what I did last time


1 Like

@rfindley I am having an issue where the default value of a setting is interfering with the chosen value.

I am storing an array of arrays for the heatmap. These are the defaults

colors: [[0, "#AAAAAA"], [100, "#BBBBBB"], [200, "#CCCCCC"],],

If I change the setting (and save it) to be

colors: [[0, "#DDDDDD"], [100, "#EEEEEE"],],

When I load the settings again, with the defaults, they will end up like this

colors: [[0, "#DDDDDD"], [100, "#EEEEEE"], [200, "#CCCCCC"],],

Is this intended?

This is the merge code:

wkof.settings[script_id] = $.extend(true, {}, defaults, settings);

It starts with an empty object {}, then merges the defaults, then merges the loaded settings.

So, I’m guessing this is how $.extend() works. I wouldn’t have expected it to merge parts of an array.

On a 'deep' extend, Object and Array are extended, but object wrappers on primitive types such as String, Boolean, and Number are not. Deep-extending a cyclical data structure will result in an error.

So, the deep merge (“true”) parameter is apparently causing the array to merge. But the deep merge is needed for nested object parameters. I’m not sure what solution to suggest, other than removing the color default and checking if it needs to be added after the merge.

1 Like


By this we can see that jQuery.extend():

  • Starts with the object provided by the first parameter.
  • Adds to it any property in the second parameter. If the property already exists in the first parameter, it is overwritten. The object for the second parameter is unchanged.
  • Repeats the above with any subsequent parameter.
  • Returns the first parameter.

This is useful for combining user and default option-objects together to get a complete set of options:

1 Like

Ah, thought it could be something like that. A bit annoying but your workaround will do. Thank you or looking into it!

1 Like

Suggestion: Invalidated setting values should stop settings from saving

I have this bug. I am not sure it belongs here so feel free to redirect me.

My list of scripts falls off the screen and the scrolling arrow too. I can’t scroll and access all my scripts settings. Is this an issue with Open Framework? I have an horizontal scroll bar at the bottom of my screen. Could this be the issue?

1 Like

…is too long? How do you have that many scripts with settings? end confusion

@prouleau I understand, my point was that it’s crazy that you found all those scripts… :wink:

1 Like

The number of scripts is not the issue. We should be able to scroll this list. There is a scrollbar for this (look at the screenshot) and I can’t use it. The scrollbar should be made to work.

It is a framework issue. Apparently, the framework is a victim of its own success :sweat_smile:

I don’t have time to work on it currently, but maybe someone with some CSS skill could take a quick look. If someone finds a solution, I’ll gladly add it to the framework.