[Userscript] Niai 似合い Visually Similar Kanji

Since WKOF loads from:

var supported_modules = { Apiv2: { url: 'https://greasyfork.org/scripts/38581-wanikani-open-framework-apiv2-module/code/Wanikani%20Open%20Framework%20-%20Apiv2%20module.js?version=700865'}, ItemData: { url: 'https://greasyfork.org/scripts/38580-wanikani-open-framework-itemdata-module/code/Wanikani%20Open%20Framework%20-%20ItemData%20module.js?version=701635'}, Menu: { url: 'https://greasyfork.org/scripts/38578-wanikani-open-framework-menu-module/code/Wanikani%20Open%20Framework%20-%20Menu%20module.js?version=701233'}, Progress: { url: 'https://greasyfork.org/scripts/38577-wanikani-open-framework-progress-module/code/Wanikani%20Open%20Framework%20-%20Progress%20module.js?version=601473'}, Settings: { url: 'https://greasyfork.org/scripts/38576-wanikani-open-framework-settings-module/code/Wanikani%20Open%20Framework%20-%20Settings%20module.js?version=607871'}, };

Should I whitelist greasyfork.org as well? If so, what parameters should I whitelist? (See above screenshot)

Disabling this script may fix it on the one page you’re looking at if no other scripts are loading all that data, but I think it’s primarily a problem with your browser settings. I’m afraid I don’t use Brave though, so I can’t help you beyond that.

1 Like

That’s probably cat pics and gifs :wink:

Maybe you can find some info in the WKOF thread. I’m sure someone already got and solved the problem.

Edit: I think the important part for whitelisting of storage is api.wanikani.com, but I also don’t know exactly what’s going on with disabled caching

You are already successfully receiving the data, you should search for persistent storage for Tampermonkey, or the storage WKOF is using

Thanks !! I had a similar ssue and it seems that disabling the visual similar kanji did the trick ! In my case, it was not loading for every single wrong answer, just from time to time on a wrong answer. But also it would sometimes just load without any prompt I could understand, just in the middle of review the “load data” would pop up and block everything for a couple of seconds.

But I just did a big review (> 100 items) with this script disabled and the issue didn’t appear even once. :partying_face:

For information I’m on windows 10 and chrome and my list of script is the following:
Wanikani Open Framework
Wanikani Reorder Ultimate 2
Wanikani Double-Check
Wanikani Heatmap
Wanikani Ultimate Timeline
WaniKani Keisei Phonetic-Semantic Composition
Wanikani Niai Similar Kanji

I will check if I can improve the caching, or just make it optional. Looks like WKOF fetches the data again after it gets 60 seconds old, not what I was expecting.

Yeah, I saw that in an earlier post of yours - exactly why I’d like to change it to .8 like the ones you personally added. (Still leaving a value of 1 for anything I manually add myself.)

As to your current method of ordering… that’s weird and time-consuming if they’re already present… I’d have to delete it, and add it, and make sure I do it in the reverse order of what I want… I’d leave them whatever random order your script puts them in over that, even though it’s less helpful (deleting more to bring them closer together, helps, though.)

Oh, also, could I remove whether it’s a locked or unlocked item? Having the diagonal lines across the pink make it a bit harder to see the white lines of the font and differentiate the differences 100%.

Wow. That’s often. Makes me wonder if that’s what @rfindley intended (is that a part of WKOF’s script, or how you’re having WKOF work within your script, ACM?)…

@Arzar33 @honmashinsei I removed the WKOF support for now in Niai version 1.3.2, updating the script should solve your problems until I fixed the caching.

I’m probably not using it as intended, but on the other hand Ultimate Timeline doesn’t refresh the data all the time …?

WKOF caches forever (assuming indexeddb is working), but it queries for updates each time the page reloads… but not more often than once per minute to avoid tons of requeries when you’re just navigating around WK.

But in most cases (except internet lag or lost packets), an update query should return almost immediately with no data, and the ‘loading’ popup only comes up if the server takes more than 1sec to return data.

WKOF doesn’t load anything after page-load, so if (for example) you’re doing something in the reviews page, it won’t load anything on a per-item basis unless it’s a non-cached part of the API.

3 Likes

Hmm, so it means there must be some issue on the client side to cause the pop-ups? At the moment I’m loading kanji (not that many items) to see their locked status and meaning. I could probably do it in one go, but I thought that the second one is a non-operation. Or maybe there is some mistake in the usage?

Edit: the script also monitors the page and check if you open the info folds on the review and lesson pages, so that code can be called multiple times on the same page.

    wkof_fix_info = function(similar_list)
    {
        const wkof_config_locked = {
            wk_items: {
                options: {},
                filters: {
                    srs: {value: 'lock', invert: true},
                    item_type: 'kan'
                }
            }
        };

        const wkof_config_meaning = {
            wk_items: {
                options: {},
                filters: {
                    item_type: 'kan'
                }
            }
        };

        const _fix_info = function(items)
        {
            const type_items = wkof.ItemData.get_index(items, `slug`);

            similar_list.forEach((sim_kanji) => {
                if (sim_kanji in type_items)
                    $(`li[id$="${sim_kanji}"]`).removeClass(`locked`);
                else
                    $(`li[id$="${sim_kanji}"]`).addClass(`locked`);
            });
        };

        // Retrieve the latest meanings directly from WK
        const _fix_meanings = function(items)
        {
            const type_items = wkof.ItemData.get_index(items, `slug`);

            similar_list.forEach((sim_kanji) => {
                if (sim_kanji in type_items)
                {
                    $(`li[id$="${sim_kanji}"] li.niai_meaning`)
                        .text(type_items[sim_kanji].data.meanings[0].meaning);
                }
            });
        };

        wkof.ready(`ItemData`)
            .then(()=>
                    wkof.ItemData.get_items(wkof_config_locked)
                        .then(_fix_info)
            )
            .then(()=>
                    wkof.ItemData.get_items(wkof_config_meaning)
                        .then(_fix_meanings)
            );
    };

One correction to what I said…
WKOF queries a (cached) endpoint for updates only once per pageload… but not necessarily at pageload. It does the query upon the first request from any script.

And as for your usage above, it makes no difference if you do it as on query or two.

So … it is impossible to get multiple “loading assignments” during reviews/wrong answers in a session? Some people are reporting that that is what is happening to them.

The kanji are cached, right?

Correct. Technically, if you requested different endpoints at different times, you could get a popup more than once. For example, “loading subjects” one time, and “loading assignments” another time. Neither one would ever repeat, though.

Also, if you’re loading from an uncached endpoint like ‘reviews’. (I think ‘reviews’ is one of the uncached ones… it’s been a while since I looked at the endpoints :slight_smile: )

1 Like

Maybe the filter function for srs status “lock” is getting something uncached, and that several times? I actually don’t really know what endpoint I’m reading from.

Looks like the filter reads from /assignments, and the docs say it’s also cached. I really don’t know what’s going on there.

Just tested it, you can ignore the red border it uses the entered value anyway :slight_smile:

If it’s really saying “loading assignments” each time (with no page-load happening), there’s definitely something not working correctly.

Are you loading anything in an <iframe>? Because TamperMonkey might load another copy of WKOF inside an iframe, though in that case I would assume the ‘loading’ popup would appear within the iframe, which would probably be conspicuous.

1 Like

No iFrame, I’m either altering the page directly or wait with an observer for changes in the page.

One thing where I don’t exactly know what is going on is that I have to use unsafeWindow.wkof because I’m using Tampermonkey built-in functions, so I have to use their permission model. (Maybe not the smartest idea, but in the beginning I didn’t know how buggy the functions are.)

Based on what you said maybe Tampermonkey starts spawning more WKOF in its sandboxes or something? [still doesn’t explain multiple loads during reviews, though.]

Weird. But thanks.

I’ll try tonight at home. ^^

(Is it weird that I’m enjoying reading the two of you hash this out?)

1 Like

Current conclusion is that what is happening is impossible to happen, who wouldn’t enjoy reading that :slight_smile:

1 Like