Parts of Lessons converted to React now in Preview

Sharing this change ahead of time on in case it affects scripts.

These elements are now rendered using React:

The markup structure, element attributes should all be the same, and it is still tied to jStorage the same way.

Previously sections that weren’t active stayed on the page and just got style="display: none;" or display: block, now those sections are removed from and added to the page by React.

Will be testing this out on preview for at least this week or longer depending on feedback, before moving on to


Thank you, Javi


Minor Graphical Bug:

  1. Hard reload (ctrl+shift+r) the lessons page on the preview site.
  2. Click the reading tab.
  3. Observe that the font or font size for the voice actor’s names starts out as something and then rapidly switches to something else very shortly after loading.

Also, it looks like this does indeed break several scripts, which assumed certain elements would be present in the DOM when DOMContentLoaded is fired. It would be great if there could be a bit of time so that the script authors can write updates. Here is a list of the ones I know of:

  • Anything using the WKInteraction framework including
    • Keisei Semantic Phonetic Composition
    • Niai Similar Kanji
    • Rendaku Information
  • Advanced Context Sentence
  • Lesson User Synonyms (fixed)
  • Pitch Info

Also, another issue I am seeing, which also happens sometimes on the non-preview site, is that about 50% of the time when I load the lessons page, the icons at the top right of the screen are not rendered in the FontAwesome font and therefore look like garbled text.

Edit: Also, when you do something that causes the answer of the box to shake, at the very bottom of the page, there is some weird gray flickering due to I think a scrollbar popping in and out of existance rapidly. This also affects the non-preview site.


The reading tab currently has the id supplement-kan-meaning – I assume this is not intentional?


What’s this???

It’s a javascript framework that provides certain WaniKani related events that scripts can subscribe to so you don’t need to write as much ad-hoc code for figuring out when to show something on the page. I think only a few scripts use it, but they are pretty popular scripts. I haven’t used it myself so I’m not super familiar with its functionality. I think it’s made by the person who wrote some of the scripts that use it.

1 Like

Ah, so it’s not native?

If by native, you mean made by the WaniKani team, then no it’s not.

1 Like

Ah yes, I think it’s layout shift from the audio button rendering slightly later. Fixed it in a recent build.

Good catch, fixed that earlier today.


Oh no, I love all of the scripts you mentioned here
(and now the two of them that were bugged for me are working perfectly because of your fixes, thank you so much for that btw!)

Quite a lot of the scripts on WK are made by people who aren’t around anymore to update them, right? Doesn’t sound good if this update will break many of them :slightly_frowning_face:



On the preview site, audio on the reading lesson card now plays twice sometimes, but not all the time. It either plays once, followed by a short delay, then again, or it plays overlapped with the second play started before the first one ends. It might be that in the instances where it doesn’t seem to play twice, it is actually playing twice, but starts at the same time so you don’t notice it. (Not sure, just a guess.) I have confirmed this happens with all scripts disabled.

Also, sometimes it is more than 2 times. Like as I’m writing this, it’s playing doubled up audio for 掲載 once every 20 seconds or so even though I’m not interacting with the page at all. (8 total playbacks, 2 overlapped after clicking the reading tab, then 2 overlapped once every 20 seconds or so three times)


Can someone confirm that the Lesson Filter script works? I don’t have any lessons available to test it myself.

I have had this issue on the current site as well. Not every time I play the audio though, it’s pretty rare.

Two more bugs I found during lessons on the preview server (with userscripts disabled):

  • When I’m on a vocab item “Reading” tab and switch to a different vocab item by clicking on it in the list at the bottom, it autoplays this item’s audio.
  • When I’m on a kanji item’s “Examples” tab and press Enter, instead of going to the next item, it switches back to the current item’s “Readings” tab. This seems to only happen in a specific circumstance: The first completed lesson in this batch has to be a radical. I have added a screenshot below showing a situation (RKKRR) where this problem occurs. If I get KKRRR and continuously hit enter, it works correctly. But if I jump to a radical before completing the first K, and later come back to the K, the bug occurs. Similarly, if I get RRKRR and immediately jump to the K lesson, it works, but if I first complete an R lesson, it breaks. (sorry for the wordy explanation; I hope it was still understandable)

The double autoplay audio bug also happens to me. Sometimes they play delayed, making it more noticeable, and sometimes they play at the same time, making it just louder.

On another note: Since @acm2010 (the original script author) is not around anymore, I have looked into fixing wk_interaction.js that was created for the Keisei and Niai scripts, and is also used by the Rendaku Information script. However, React makes it really hard to reliably tell when a lesson tab switch happens. Until now, wk_interaction.js used a MutationObserver to detect when the supplement div changes, but React sometimes just re-uses existing elements, so this approach does not seem sufficiently reliable. It also seems like on a tab switch, React does not always remove elements that were added to the old tab by a script, so scripts now have to do that themselves.

My current solution for wk_interaction.js contains

$.jStorage.listenKeyChange("l/currentLesson", () => this.lessonInfoCallback());
this.lessonInfoObserver.observe(document.getElementById(`lesson`), {childList: true, subtree: true});

The MutationObserver is for detecting tab changes, but it misses changes where the tab stays the same, and only the current lesson changes – this can happen for example if you are at the “Name” tab (the first tab) of a radical and then jump to a different radical by clicking on it at the bottom. For the new radical, the tab is still the “Name” tab, and the MutationObserver only reports small content changes that I think can’t be discerned from changes made by other userscripts, which I think should not trigger anything. To catch these cases, I added a jStorage change listener that triggers when the lesson changes, but this means that if the tab and the current lesson change at the same time, the script triggers twice. So in my solution, Keisei generates and adds its information section, then immediately deletes it and generates and adds it again.

It works, but it’s not ideal. If anyone has better suggestions/solutions for detecting tab changes, let me know – otherwise I will leave it at that and create a pull request with this mediocre fix.

1 Like

How about creating a test account? You would start at level one on such an account and plenty of lessons would be available.

Would a test account be against terms of service? :thinking:
If yes, then this is definitely not a test account. Not that anyone could guess what my main account is, anyway. There is definitely nothing that would give it away.


Hey aren’t you that person that made Sergues Sionfucon


Which portion of the terms of service do you refer to?

I didn’t any such restriction in the terms of service. Tofugu wants the scripts from the API to work. I don’t see why they would object to a test account.