Updates to Lessons, Reviews, and Extra Study

I just noticed that reordering this way actually clears the item stats, so any answers already submitted (correct or incorrect) for uncompleted items are wiped. Any way we could avoid that? It really hampers the usability of reordering scripts.

For people following along at home, unless we can keep the item stats on reorder “back to back” is not viable

1 Like

Version 0.5 fixes the dumb bug I introduced in version 0.4. structuredClone() does not clone getters.

EDIT: Shouldn’t these two data attributes be able to replicate the most important parts of back to back?

I’m not sure if you get notified when I edit the reply, so I’m also tagging you @Kumirei

1 Like

This is actually pretty cool and I like most of the changes. The only thing I’m not a huge fan of is the huge space between the kanji and the word below it. I think it looks pretty closer together. Other than that this is pretty cool though :slight_smile:

1 Like

It can handle the “repeat until correct” type of back to back, but it’s better when you can shuffle an item when you get it wrong. I also have the “true back to back” option, which forces you to get both questions right back to back


You are right – and if I understand correctly, the problem is that if you reorder the queue after a wrong answer, the record about the wrong answer is wiped so that the final result will always be submitted as passed. The only idea I currently have is to listen to the didAnswerQuestion event and manipulate the answer stats there:

window.addEventListener(`didAnswerQuestion`, e => e.detail.subjectWithStats.stats.meaning.incorrect = 1);

This should at least allow you change the submitted result to “not passed”. This could probably solve the “true back to back” problem, but I don’t think it will help with the shuffle option.

Anyway, I have added wkQueue.completeSubjectsInOrder and wkQueue.questionOrder to modify the corresponding data attributes.


While doing lessons, there’s a significant pause when switching from one subject to the next. What could be causing this?

Also, I assume this is part of the session removal, but the number of items completed in that session is gone. I personally used this to pace my reviews, doing x an hour. Could this maybe get the same treatment as the “last 10 reviewed items”, so that the number items done in the last hour is shown?

1 Like

Scott, do you see any issues with something like this:

let quiz_queue = Stimulus.getControllerForElementAndIdentifier(

do_some_sort_of_reordering(); // ...by manipulating the tags containing the subjects/subjectIDs
quiz_queue.completeSubjectsInOrderValue = true;
quiz_queue.questionOrderValue = 'readingFirst';

I’ve tested this, it works, and I haven’t noticed any side-effects yet, but I’m new to Stimulus.

As far as I can tell, all the resources from prior calls to initialize(), such as QuizAPI and QuizQueue, should be junk-collected.

Of course, if a userscript does this after the user has already answered some items, it should also keep track of the answered items and make sure they are removed from the initial <script> tags, and I think the other scripters are already aware of that.


Is there a way to change the lesson order after the lesson page has loaded (not the quiz) or must it be done on page load?

Also, does that URL take all the lessons possible or just the ones for a single batch? That is, if my batch size is 5, will the URL always have 5 subject ids or will it have the ids for all the lessons available?

Is there a way to manipulate the batch size?

In [Userscript] WaniKani Lesson Filter I allow the user to filter lessons by type (radical, kanji, vocab), change the batch size, and shuffle the lessons. All of this is done on the lesson page (not the quiz). I’m trying to figure out what is still possible on the lesson page itself versus if I’ll have to change the script to execute prior to the lesson page by opening the lesson URL with the necessary query params up front.


Thanks for the heads up. I have managed to get the scroll to disappear in Firefox but not Edge. I wont spend anymore time on this particular issue as the plan is to have a better UI for this on narrow screens in the future.


Thanks for the helpful info, both in terms of the summary page and the home button. I think we can do a better job of highlighting the wrap up which would negate the need for a confirmation dialog when you click the home button. To a veteran user, having to confirm when you click home would be annoying.

That said, I would consider this for future updates and not address these points this time round. Your points have been noted though.

1 Like

Thanks for your feedback on this, and while I agree that the meaning and reading could be better, the focus at this point was to bring the styling inline between subject pages and the item info. The thought is that any improvements made in one place will benefit the other.

Your feature requests have been noted and may be addressed in the next batch of changes I will be doing after this change is on production.

Thanks for taking the time to provide your feedback here, and if you have further suggestions and feature requests please do let customer support know by emailing them at hello@wanikani.com


There is no way to manipulate the answer stats sorry.

The suggestion by @Sinyaven above will no longer work either. I have addressed this loophole. My reason is that you should not rely on the code I consider internal. I want to be free to manipulate and change this however I see fit without the need to notify the user script community of every change. I feel that If I change the events then I can let you know, but if the internal structure of my code changes, it shouldn’t break anything you add. This helps reduce the burden on customer support as users of the scripts often don’t know if the script is causing a problem, or if it is Wanikani (not all users, but some…)

The above is great feedback, and should be submitted as a feature request. I do however intend to reduce the payload of the subjects sent to the client by removing the non-preferred voice actor. If you feel that having randomness of voice actor is a great feature could you please raise a feature request by sending customer support an email?! We can then evaluate and prioritise with the other features that we want to deliver.

Maybe this should be a feature request for extra study too.

Can you please clarify what is a significant pause? It is loading a new page from the server when you move between subjects. There are optimisations that I could do to preload the next subjects, but preloading should be done mindfully as the extra bandwidth may not be necessary.

Could you please request this as a feature by sending an email to customer support so it can be evaluated and fed into the backlog as appropriate?

Looking at the network tab, it varies pretty wildly, but really anywhere from 200ms at best to a whole second at worst.

Sure, I’ll link back to the post I’ve made originally, I assume that works fine.

1 Like

I would heavily advise against this approach as you are going to be to reliant on code that is likely to change. If, for instance I decide that the initialise code should be done on the connect callback, then your code will break. You are of course free to do what ever you like, but I think that approach is much more brittle than the alternative.

However, I will admit that I don’t know what any of the user scripts do in detail, so if you need to do this, I will just say “here be dragons”.

1 Like

Once this goes out to production I will monitor the performance and timings. We have tools on production to help us do that.

The production hardware is different to that used for preview also, so I will defer to the performance optimisations until then (if they are still necessary).


So far everything looks great. I’ve found one thing tho.
In the vocabulary examples for a kanji, before I could see the reading by hovering the word, now, it doesn’t show. That helps with understanding how a kanji will sounds in a word, and even if there’s other readings different from the one showing.

See the screenshot below.



Now, I found another one.
When teaching the kanji there were two readings, I picked あた for this one. Turns out I shouldn’t.

See the kanji page below.


あた is a kun’yomi reading, so it seems like the shake is correct but the lesson info is wrong.


This now works as it did before.

like @seanblue helpfully identified, this was an issue with the lesson slide and not the lesson quiz. I have fixed this issue now.

Thank you I really appreciate you taking the time to report these issues.