[Userscript] Show Total Lesson Count

[LupoMikti]

This is a third-party script/app and is not created by the WaniKani team. By using this, you understand that it can stop working at any time or be discontinued indefinitely.

Hello all. This is a script that was made in response to a request made in the Script Request thread several months ago. With the recent updates to the site, I had to update this script and it has a reached a point where it makes more sense to give it its own thread than to keep it secluded to that request thread.

Without further ado…

What does this script do?

This script replaces the daily lesson count shown on the lesson tile on the dashboard and in the lesson start navigation item in the top bar with the total number of available lessons. It has an option where you can choose to display only the total lesson count or both the daily amount and the total amount together on the lesson tile (not in the navigation bar though, that will either be the total or the daily). The numbers should update as you do lessons.

Links
You can grab the script from Greasyfork here.
I don’t currently have it hosted on my github but I will in the future and update here.

Original post

What do you want now? (Request extensions here)

Whipped this up quickly. Needs open framework (because I don’t want to deal with asking the user for their API key). Thanks to Mikey’s suggestions, it now displays today’s lesson count / total lesson count. Edit: if there is special styling when there are 0 lessons such that a number is not displayed I will have to address this at a later date (or someone could suggest the code for it) as I am far from having 0 lessons currently

Changelog

v 0.4.0 Updated script to work with the finished tra…

Continued changelog

v0.5.9 - 0.5.10 - Fixes typos in variables and tries to improve handling of turbo events/navigation
v0.5.8 - Update TurboEvents library dependency
v0.5.7 - Fix error for non-local instances of the TurboEvents library
v0.5.2 - 0.5.6 - Various fixes for global state management. Add a way for the script to run at least once if the turbo events are not firing properly. Fix an issue with the hiding of the start button on the lesson tile. More logging improvements.
v0.5.1 - Fix saving of settings
v0.5.0 - More logging improvements, navigation execution improvements, deprecation of the preferred daily amount settings
v0.4.11 - Changes that finally address intermittent loading issues
v0.4.10 - Dependency update + minor improvements
v0.4.9 - Update TurboEvents library dependency.
v0.4.8 - Update library dependency to hopefully fix an issue with intermittent failure to register the turbo event listeners. Also further improves the debug logging.
v0.4.7 - More improvements for logging
v0.4.6 - Improvements to the debug logging (accounting for when script fails to reach main())
v0.4.5 - Added debugging setting and debug logging. On by default as it outputs with console.debug() not console.log()
v0.4.4 - Update hover tip text in settings and update support url
v0.4.3 - Update maximum preferred daily amount to match Wanikani’s
v0.4.2 - Explicitly await load_script
v0.4.1 - Fix dependency url

[prouleau]

I move the ongoing discussion here.

The bug is intermittent. I did a refresh and the total lesson count showed up. I refreshed again and the total lesson count didn’t show up.

[LupoMikti]

This matches the behavior I was seeing until I fixed all scripts I have for turbo. Currently I no longer get the failure to modify the turbo frames because of this. Since I won’t be able to easily reproduce the intermittent behavior, I’ll try to get an update pushed that makes turning on the console debugging as simple as turning on a setting for it.

[prouleau]

I turned off all my script except Open Framework and Airagoshi’s which is turbo enabled. I still have the problem except that it is more likely to display the Total Lesson Count. In other words it is still intermittent but with a greater probability that it works than what it was with all my scripts turned on.

When I turned off Airagoshi’s script then the problem doesn’t occur at all.

This has the smell of a race condition, possibly caused by a mishandled promise somewhere. When doing a refresh all scripts fire at once which cause a greater load on the browser and has a greater probability to trigger the bug. When navigating with turbo fewer scripts fire and their workload is lighter. The bug has less room to manifest.

[LupoMikti]

Thanks, I’ll do some testing related to this finding and see if I can come up with something that more or less guarantees internal consistency without being affected by other scripts and events.

Edit: which script is Airagoshi’s by the way?

[prouleau]

@LupoMikti

which script is Airagoshi’s by the way?

[Userscript] Araigoshi's Dashboard Stage Breakdown

Yep, it’s yet another take on this. I tried to fit in with the new Wanikani styling, and let you pick between a more compact item type breakdown or the standard Wanikani one: Most compact settings: [wk-breakdown-script] Most expanded settings: [wk-breakdown-script-expanded] Settings screen: [wk-breakdown-script-settings] Detailed listings: [image] You can hover the compact icons for srs stages or item types to see the leeches. You can install it here, but don’t forget to install Wan…

Edit: I gave you the older deprecated link. Here is the current one.

[prouleau]

@Inserio @LupoMikti I think I know what is the bug. It is an issue I ran into when developing Item Inspector. I am sorry for not connecting the dots sooner.

wkof.load_script returns a promise that resolves when the script is done loading, not when the loaded script is done initializing. This means the Show Total Count script does not properly synchronize with the Turbo Event Library because there is a race condition involving the initalization of the library.

The solution is the turbo event library callsj wkof.set_state(someScriptId, 'Ready') when it is done initializing and the Show Total Lesson script calls wkof.wait_state(someScriptId, 'Ready') after doing wkof.load_script. This returns a promise that resolves when the turbo event library makes a corresponding call to wkof.set_state

[Inserio]

Though I believe the wkof.ready(someScriptId) is essentially just a convenience function for wkof.wait_state(someScriptId, 'Ready'). The latter allows additional functionality, but most usages of the former are essentially just a shortcut.

[prouleau]

I don’t believe this is the case. There is separate code in the framework for wkof.ready and wkof.wait_state. The two don’t overlap.

The difference is wkof.ready is for readying wkof modules. wkof.wait_state is for handling user defied events set by wkof.set_state.

[Inserio]

function ready(module_list) {
    let module_names = split_list(module_list);

    let ready_promises = [ ];
    for (let idx in module_names) {
        let module_name = module_names[idx];
        ready_promises.push(wait_state('wkof.' + module_name, 'ready'));
    }

    if (ready_promises.length === 0) {
        return Promise.resolve();
    } else if (ready_promises.length === 1) {
        return ready_promises[0];
    } else {
        return Promise.all(ready_promises);
    }
}

While technically true that that’s the intended purpose, that doesn’t change that that’s still essentially what it does.

[prouleau]

You have a point. But I think the turbo event library still needs a wkof.set_state call to properly support loading the module with wkof.load_module

[Inserio]

I thought I had that?

    function turboEventsReady() {
        wkof.set_state('wkof.TurboEvents', 'ready');
    }

Is that not in the version that’s imported?

[prouleau]

Yes this is what is needed. It is not mentioned in the script documentation so I erroneously assumed you didn’t have it, I now see that what is missing is only the documentation so people know they need a corresponding wkof.wait_state

[Inserio]

I had to go check for myself that I didn’t include it because I had an inkling that I had at least included it an example or something. But you’re right. To be fair, I was also right, it’s just that I had only included it in the examples for the description at the GitHub/Greasy Fork links.

[prouleau]

I see that Show Total Lesson Count has a wkof.ready('TurboEvents') call. According to my tests this does the job. So I was wrong. The issue is not what I thought iis.t`

[Inserio]

@prouleau

The issue is not what I thought it is.

That’s a mood.

では、頑張って！

(Jogs away)

[prouleau]

I ran some tests. I equipped the script with some console.log to see which path are executed.

    wkof.ready('TurboEvents').then(() => {
        console.log('wkof.ready(\'TurboEvents\')');
        let urlList = [wkof.turbo.common.locations.dashboard, wkof.turbo.common.locations.items_pages, /^https:\/\/www\.wanikani\.com\/(settings|level|radicals|kanji|vocabulary)(\/|\?difficulty=).+\/?$/];

        wkof.turbo.on.common.urls(() => {
            console.log('wkof.turbo.on.common.urls');
            initial_load = stateStarting = true;
            todaysLessonsFrameLoaded = navBarCountFrameLoaded = false;
            _start();
        }, urlList);
        wkof.turbo.on.event.before_frame_render((e) => {
            console.log('wkof.turbo.on.event.before_frame_render');
            if (['todays-lessons-frame', 'lesson-and-review-count-frame'].includes(e.target.id)) {
                todaysLessonsFrameLoaded = false;
                navBarCountFrameLoaded = false;
            }
        }, { urls: urlList, noTimeout: true });
        wkof.turbo.on.event.frame_load(async (e) => {
            console.log('wkof.turbo.on.event.frame_load');
            if (e.target.id === 'todays-lessons-frame') {
                todaysLessonsFrameLoaded = true;
                await main();
            }
            else if (e.target.id === 'lesson-and-review-count-frame') {
                navBarCountFrameLoaded = true;
                await main();
            }
        }, { urls: urlList });
    });

The i disabled my scripts to get the intermittent behavior. The idea was to see the difference between the path when the script is working and when it is not working.

Here is what happens when the script is working.

When the script is not working some Turbo events don’t fire at all. Here is an example.

There are some variations on the events not firing. Here is another example.

[LupoMikti]

What’s additionally concerning to me is how in your ‘working’ example, turbo:before-frame-render also seemed to never fire, which shouldn’t be the case as you successfully got turbo:frame-load. This will be difficult to reproduce because for me the events are never missing, even when I was observing intermittent behavior myself. Thank you for the continued help in investigating.

[prouleau]

@LupoMikti

also seemed to never fire, which shouldn’t be the case as you successfully got turbo:frame-load

This suggests that the turbo events are fired but the event handlers are not notified. How could that be?

[LupoMikti]

My only thought is that the wrong element is being listened to. I notice that in the library it uses document.documentElement.addEventListener but in other scripts I’ve modified I use window.addEventListener. I am wondering if I changed the script from using the library (which I like due to the simplification of URL checking) whether the issue would go away due to using window.addEventListener.