It looks like my approach will be to listen to willShowNextQuestion to know what the upcoming question is, and also to modify the quiz-queue, replacing the correct reading with the onyomi version when appropriate. I wanted to do it by messing with the function that evaluates if the input is correct, but I don’t think you can change event data after they’ve been fired, and I couldn’t figure out how to reach the AnswerChecker to convert the input back to hiragana right before evaluation.
The data shown in the info dropdown is not pulled from the quiz-queue, nor does it seem pre-rendered so it seems I will have to handle this by looking for changes in the DOM, like I did before.
The event that is passed to newQuestion contains the information on the upcoming (if the page just loaded the event will fire for the current item as soon as you do anything) item.
var newQuestion = function (e) {
var currentquestiontype = e.type;
}
Note that this is likely to require a larger refactor since you can’t pull the data on demand with this method.
I actually think this was the right call. Like many here, though, I didn’t appreciate how many users would dislike this change, especially since “enter” works during reviews. Kudos to @Sinyaven for catching this.
Following standards for enter and tab navigation makes sense, but what is a user supposed to tab TO on lessons pages to navigate to the next item?
It’s not a problem with reviews, since a text input for your response is active, enter proceeds to the next item.
I just created a new account (so I could have some lessons) and it appears there is no input or button on lessons pages that always proceeds to the next item. The 5 (or however many) items have buttons on the bottom, but you’ve got to do a LOT of tabbing to get there.
Wouldn’t the simplest solution to this one user complaint be to add an input or button to the lesson pages (labeled “continue”, “next”, “>” or something?) with tabindex=1? That is, it seems like there should be something equivalent to the text input on review pages.
Sorry I am not sure I have entirely understood what you are asking. A user can tab onto the slide navigation buttons and press enter to go to the next slide. If they want to skip to the next subject/item they can use the g shortcut key. Does that answer your question?
The use of enter key on a form input field is expected to do one of 2 things, submit the form (which is the default) or navigate to the next input field (this requires special handling by the developer). This is why it works in reviews as using the enter key is used to submit your answer.
@tofugu-scotta big positive, is that the pause I noticed inbetween lessons is unnoticable now that the changes have been deployed to the production environment.
Nevermind, seems like it really depends on the kind of mood the system is in, it’s back to quite a noticeable pause.
Sorry that it took so long. In the new version, any calls done to wkQueue in immediate succession (i.e. without any awaits in between) are grouped together into a single queue recomputation.
How does this work exactly? I just updated to the latest version and doing wkQueue.lessonBatchSize = 9 without an await immediately updated the UI. This was in the console though, so I don’t know if that works differently for some reason.
Before calling the internal function that recomputes the queue, I added an await true;. This means that the control flow goes back to the code that did the call to wkQueue, and only once this code is finished, the control flow goes back to the code following the await true. And even if during this period, there were multiple calls that require a recomputation of the queue, I only do it once.
Is there no kind of race condition or timing issue with this approach? I’m probably missing something (as I’m not really familiar with how async works in JavaScript), but that was my worry.
I will admit that I don’t understand what the await true or the requestApplyManipulationsGeneric method are doing at all.
This describes my motivation for using Lesson Filter precisely. Large blocks of kanji followed by large dumps of vocabulary don’t work as well as when I can interleave vocabulary with guru’d kanji.
@tofugu-scott While looking at what it would take to migrate my script, I noticed none of the elements have ids anymore which is what I was using to figure out where I wanted to insert stuff. Was that a conscious decision? Kind of curious as to the thinking behind the design.
Javascript is single-threaded, so it won’t cause a race condition. The control flow will only return to the queue manipulation once your code has finished executing (or pauses because of an await).
I’m not remotely following how that happens or where that logic is, but I guess I’ll take your word for it.
Unrelated question… I’m really not happy about the thought of the queue not honoring the WaniKani lesson order. I know Scott discouraged it, but it doesn’t seem that hard to reimplement the ordering options. After all, the options are level then type, level then random, or random. All of which seem easy to implement with basic sorting functions given the level, type, and user preference can all be retrieved from the API. So two questions:
Do you think it would fit in with the theme of your script to implement that behavior within it and are you willing to add that?
If not and assuming I want to do it myself, is there any part of your script I’d still be able to leverage (like applying the changes to Turbo) without getting messed up by the summary endpoint’s arbitrary order? Or would I be better off just building it all myself at that point?
I do think that this would make sense to have in the script, but I don’t know when I will have the time to do this. Furthermore, this requires even more info from the API, and at that point I think I will keep the Open Framework dependency to at least have the benefit of the wkof caching.
