Upcoming Front-End Updates on WaniKani & Effect on Scripts

Would it be possible to add support to the public API for manipulating lesson and review ordering? That seems like it would be better, as it allows scripts to keep working no matter how you change the frontend.

1 Like

I wouldn’t want to either. Some of them seem essential to me now. Maybe some of them could be built in as options, like Lightning Mode? Something for leeches? You could expand your ‘cult’ concept with something for levelling up!


Hi all :wave:t3:

Thanks for following along. I’m here to let y’all know that we’ve updated the preview site with the first batch of front-end updates to WaniKani. You can use your regular WaniKani credentials here: http://preview.wanikani.com/.

:warning:Remember: The preview site is not a test site! The data is from your regular account, so all lessons and reviews are the real deal.

We’d love it for you to try some lessons and quizzes out on the preview site. Try your add-ons and user scripts, especially if they are used on parts of the page that have been converted.

For more nitty gritty details on this update:

  • What changed? The top half of the components on the Lessons page and Quiz page have been converted to React, specifically: the Home button, the Skip button, the Stats bar on the top right (with the number of Radicals, Kanji, Vocabulary and total completed), the main character display and the bar that displays what kind of question you’re answering. If you want to follow along with the React changes, I recommend using a React browser extension.
  • What hasn’t changed? None of the features, user interfaces or design have changed. For the most part, CSS class names, DOM element structures and hierarchies have not changed. The data for these components, for example, the number of Kanji left, still come from $.jStorage.

If you notice any bugs, please @wanikanijavi and I (@gomakuma) know in this thread.

Update, 2/12: Thanks to @sornvru for pointing out the whitelist. All scripts you’re testing should have preview.wanikani.com on their whitelist at the top of the script code as well. For example, the Wanikani Ultimate Timeline script’s whitelist includes both sites with this line: // @include /^https://(www|preview).wanikani.com/(dashboard)?$/. The script won’t work the @include line only has wanikani.com and not preview.wanikani.com

Thank you and happy reviewing!


I don’t have any lessons so I would appreciate a mention if anyone notices that one of my scripts don’t work. I don’t know if I even have any lesson scripts, though image


Reset to level 1?


Your “Hotkey for the other voice actor” is not appearing neither during lessons nor reviews.

Btw, www.preview.wanikani.com is not a thing apparently. (the “www” part)

1 Like

Just as a quick look from the scripts I have, Dashboard Progress Plus, and Ultimate Timeline still work.

Pitch Info, Self-Study Quiz, and most importantly Golden Burn do not work for me.

The first is managed by @Invertex, the latter two by @rfindley.

EDIT: The reason appears to be the scripts are only whitelisted for www.wanikani.com and not any other subdomains. The scripts that continue to work have already whitelisted the preview subdomain. Reorder Ultimate 2 is also impacted for the same reasons.


Thanks! I have updated this script as well as a couple of others


Just finished deploying another update on preview.wanikani.com, these components are now React


  • Answer submission and feedback are now handled in a React component
  • The row of buttons beneath it (but not the interactions yet)
  • The bottom right corner buttons for keyboard shortcuts reminder and the contact link

(some of the interactions and children are still in plain JavaScript, but we’ve been working our way through them)

We’re aiming for the next update to be the last one before we go to production (later this week or early next week).


How are we supposed to add our UI to the DOM when all this is done? I know as of a month ago you said you were still thinking about it. My [Userscript] WaniKani Lesson Filter script will likely be impacted by this, and I’d hate for that to break. It may not have a ton of users (a few hundred), but those that use it rely heavily on it. So I’d like to find a way to keep it working if possible.


I tried out this script locally and it still works. We’ve only been working on the quiz part of lessons though.
From my own testing React seems to have issues when elements within it are deleted, but is fine with modifications (don’t hold me to this yet). I can see an issue if you also insert siblings. But in the case of your script, I think it should be fine because we can create a render boundary like

<Lesson App/> 
<!-- your script appends markup here -->
<Other Stuff Like footer nav />

And then the data side should still be fine since we are still using jStorage.

In other cases though (if you need your script’s UI to be within the app), I would experiment with inserting a div outside of the React app’s markup and overlaying it in the right position (so it visually appears within the app) by doing some measurements to align it with the rest of the app:

Something like:

<App />
<YourScript's Div style="top: top edge to align to; position: absolute;" />

Thanks for looking into it. I’ll just have to try it out once you start making changes to the lesson page itself.

By the way, have you considered adding some global variable for the current page’s version? Then scripts could support both versions of the page for the transition period. I think currently we’d have to check for existence of specific DOM elements to achieve the same thing.


This is exactly what I do with some scripts that I have updated for the preview

1 Like

I’m probably not understanding what you’re asking, but why not just use window.location.hostname to see whether or not you’re on preview?

edit: Oh… you mean some sort of version indicator so your script can (more easily) detect when the changes go to production.

1 Like

Yep, that. :slight_smile:

Apologies for the long silence here. One thing I can think of without any additional changes is going by the fingerprint on styles and script tags. For instance on reviews, https://cdn.wanikani.com/assets/v03/review/application-0339826d1c9325aceb25b748c74dfc2348ab1aedf379cfaa0afffaef6530b4ff.js

Fingerprinting is a technique that makes the name of a file dependent on the contents of the file. When the file contents change, the filename is also changed. For content that is static or infrequently changed, this provides an easy way to tell whether two versions of a file are identical, even across different servers or deployment dates.


After doing some more of our own testing there are still some bugs we want to work out before updating preview and making the push to production. In the meantime, we’ll be testing some smaller updates on preview.wanikani.com.


I don’t think that would work. The idea is to do thing A when version > X, otherwise B. You can’t do that kind of > comparison with the fingerprints. Checking the fingerprints directly (equivalence check) would risk the script code breaking if you pushed even a minor change (changing the fingerprint in the process) before official release.


We updated the main post, but I wanted to call out that we updated preview.wanikani.com today with some React goodness back in the page. To quote:

Everything inside the #lessons div on /lessons will be rendered by React but manipulated by jQuery, and the stats section is now a React component. We’re still using jStorage for all of it.


Added to the original post again about changes that went out today on preview.