You will need to listen to at least one of those events to replace jStorage. Which events depend on what you application is. The data exists in the detail property of the event
window.addEventListener(`willShowNextQuestion`, e => {
console.log(e.detail);
});
Thank you! This is exceedingly helpful. Just what I needed.
FWIW, I had been using DOM observation to implement the feature I wanted in my user script. I don’t know if the Turbo events are new to this particular WK release, but they certainly simplified the script by allowing the removal of all the clumsy observation code.
They are new, and are part of WK becoming a SPA (Single Page Application)
If you use the Lesson Filter script and would like continued support after this update, please answer a few polls over here. Thanks!
Thanks for the clarification. Unfortunately Enter shouldn’t have been a default in the first place no matter how unpopular that opinion is. I am not expecting users to use the Tab and the Enter keys for general navigation (that is why there are 3 other shortcut keys to choose from), the Tab and Enter is there to support users with disabilities (e.g. a motor disability or impaired vision). There are laws and regulations around accessibility, that shouldn’t be ignored.
As for switching the tab order, that would not follow the general guidline of left to right top to bottom navigation. I think it would be a problem for the users that I was addressing when the enter key was removed.
I hope this extra context helps, and like I said I appreciate your feedback.
Yes it was a conscious decision. The things that have ids are the thinks that need them for ARIA. There will still be some ids hanging about, but they may be removed. I would use the BEM names as they will be more stable. Is there a particular thing you are trying to select that you are having trouble with? if so let me know and I will help as best I can.
I will just reiterate that the DOM will change as necessary, and my commitment to you is to keep you informed of such updates as they happen. It is just the nature of user scripts being outside the things that I can control.
Please be careful with this. If we change the algorithm I don’t expect to keep you informed of these changes and you will be out of step. Just a warning as it is brittle, an ultimately does the user of your script a disservice should it change in the future.
The event has nothing to do with Turbo, it is just a standard browser CustomEvent. You will want to read up about these, MDN is a good starting point.
No, but if you add a listener to your browser you will be able to deduce the payload. I don’t expect the payload to change, but just know that it might do in future as this is not an API, you are just hooking into our internals.
EDIT: I have just seen others responded to your question. I will leave this response just to clear up the misconception about Turbo.
Thanks for the tip. We do actually test on device, both IOS and android.
Just to clear up the confusion… the link to which you replied was not to do with mobile but to do with the screen resolution of someone using a 14" notebook. I was just using the developer tools to set the viewport to an appropriate size to match that users screen resolution.
How can you change this algorithm short of deleting the user setting? It’s very explicitly “level then type”, “level then shuffled”, or “shuffled”. Putting aside that tie-breaks may be different, I don’t see how you can possibly change this behavior (short of removing the setting entirely) that causes a noticeable difference.
If you’re that concerned though, would you consider meeting us halfway? Right now, the whole review queue is loaded ahead of time and is accessible during reviews. Could you make the whole lesson queue (sorted by the user setting obviously) available in a similar way on the lesson (pre-quiz) page? I understand that this isn’t strictly needed for the core WaniKani functionality (or else it would already be there), but if you provide that we can avoid using the API and avoid reimplementing the lesson ordering algorithms.
Sorry my intent was just to point out the dangers. It was a bad example.
We have already covered this above
Any reason why the lessons page is HYPER sensitive to swiping left or right then?
I don’t consider myself impaired at all but I can’t quickly scroll up and down the page with flipping between lessons and tabs. (and since you’ve removed the confirmation before moving to the quiz, no doubt plenty of us are gonna end up going to the quiz well before we were ready)
Where was this? It’s hard to keep track and there are over 200 posts in this topic. 
I have just deployed an update that fixes this. Thanks for the feedback.
Yeah the post is pretty long now. I was referring to the thread of feedback from this post
I personally like the fresh touch of the new UI and see there was a lot of thought in how the things were designed. But I agree with some of the other people’s comments (summary page, etc.).
I noticed two other things that I think haven’t been yet mentioned by others.
Just a minor visual thing, but I think the “Radical Combination” and “Kanji Decomposition” should be at the same list spot in the “More Information Card” during reviews.
For Radicals, it’s at the top.
For Kanjis, it’s at the bottom.
I always look at the wrong list spot when searching for it and I’m annoyed about myself 
Not sure if this was a feature from a userscript that now got broken, but it feels so natural and absolutely essential to me that I get the feeling that it MUST come already from the WaniKani team. And if it does, then I’m a bit surprised why it disappeared now.
What I’m talking about: If you submit a wrong answer and press ENTER immediately again, it should not accept the key press for a short delay (~0.3 sec?) and stop at the current item. Right now with the new UI, it just skips to the next item.
You’ll get to a habit where you do your reviews like a machine by pressing ENTER twice for submitting an answer and advancing to the next item. Though, if you are wrong then you’ll essentially skip the opportunity to find out where you were wrong (was it a typo? confusion with another word? etc.).
Especially now since the summary page is gone, there should be some time to acknowledge the mistake and study what was the correct meaning/reading. Else you’ll just encounter the item a second time and have to again submit a wrong answer to wait and check the information card.
Thanks for the feedback. This isn’t quite the right place for the type of feedback you mention. It is much better to send these feature requests to hello@wanikani.com where they will be dealt with appropriately and fed into the priority list of changes should they be accepted. I believe an input delay is on the list, although I don’t know where in priority. It can’t hurt to let customer support know again though.
Oh, I was more hoping this was the kind of thing you could “just do” to help us out a bit. Not talking about updating the API at this point, but just adding the data into the DOM just like the review page. Seemed like the kind of thing you might be able to “just do” without it being evaluated as a roadmap item. Totally understand if you’re not comfortable doing that, but that was my hope.
