Made this for myself so why not share, I guess.
Nothing crazy, just calculates the earliest possible time you can level-up if you do everything on time and don’t miss any. I find myself often estimating this in my head, so why not just show it on the front page?
Looks like this:
Link to script (at greasyfork .org)
Requires Wanikani Open Framework. Huge thanks to @rfindley for making all this possible for relative newbies.
Updated/extended to show a detail table when you click on the summary text.
Looks like: (after clicking)
(bottom of the detail table)
Colors indicate already guru (purple), in progress (pink), and not started (grey). Thick line is when you level up. The table goes away again when you click it.
Now I can watch the dates changing, but also the colors marching down the list as I make progress. Fun!
Ideally I would have some kind of legend or explanation. I’m learning this as I go, and I’m not quite there yet.
Now I’m thinking something more like this, with the kanji’s individual next review and estimated guru time in a little popup when the mouse hovers over it.
…as I learn css so I can make it do that. It doesn’t do it yet.
(Or maybe I should just re-order, re-color, and add the popup to the kanji table that is already there in the next section instead of adding my own table. Seems way above my skill level – for now.)
Ok, little less ugly, a little more simple. Individual item dates show in a tool tip when moused over.
Hijacking WaniKani’s existing kanji status chart instead of making my own is going to have to wait for another day.
Fixed to work with wanikani’s new front page changes (it seems like)
(and matched the size of the kanji icons to match the ones in the tables below it)
(and added a couple more bits of info to the summary line)
(the “started level on” calculation is going to break the first time I encounter a kanji I already did because of content level moves, but I’ll cross that bridge when I come to it)
@ctmf , based on comments about math and stats you have mentioned in the past, you may find this post interesting, if you have not seen it already.
I’ll just leave this here 
I haven’t checked out your code yet, but I thought you might find it entertaining that there’s some stuff with very similar functionality out there. I will say though that you took it a step further with the frontend, since aside from the absolute earliest level-up time, I decided to log the individual times to the console 
Haha, yeah, I’m going to have a look and see how you did the math, because that was the “seems easy enough - oops it’s a little harder than I thought” part.
The front-end display stuff is just playing around (learning how, really). Lately I’ve been tearing my hair out with the recent wanikani changes that broke everything (right after I made it, of course). I think it works again now
In that case, I’ll spare you some time.
Focus on get_item_guru_date() (which does the final calculation) and add_dates_to_items() (which is called in prepare_items() (with a usage comment) and sets the earliest_study_date property on the items returned by wkof, allowing it to be used elsewhere).
I was really looking for how you dealt with locked kanji and finding the longest component radical. Very similar.
I was about to reply that I actually got that part almost verbatim from someone else, but after searching all over, I couldn’t find anything indicating as such. Kinda frightening that I may have repressed it from memory lol.
I managed to get the meat of it into like 60 lines, most of that by avoiding iterating anything and letting .map do most of the work for me.
Thanks! I’m finding this very useful.
Just one question, what’s the meaning of yellow color? I’m most probably missing something now
That’s the one that’s controlling when you level up - last one you have to guru. I’m not thrilled with the big yellow color, but it’s surprisingly hard to come up with some color, or circled, or outline, or something that is more obviously “Yay, this is your last one”. Maybe a little race-car finish line between that one and the next one? Maybe I’ll think of something eventually.
Glad you like it.
Using map is still iterating. I guess it’s just a difference of outlook. You can probably tell that most of my programming experience is in compiled languages, where the actual number of lines of code is an irrelevant indicator for how performant it will be.
P.s., your indentation on line 182 stunlocked me for a good 10 seconds (though it strangely got auto-fixed in the version that ended up getting installed).
Oh I think it’s pretty much irrelevant too except that I don’t have a good IDE that hops back and forth easily, so lines of code translates to how confused I’m going to make myself trying to remember what I just did.
I plan to try re-forming the whole thing to try out the turbo library this weekend. One thing I noticed just kind of playing around is I don’t get the desired effect from any of the events other than turbo:render. Load still acts unpredictably. Hopefully using the library will take care of that, or worst case, go back to this (which works, but where’s the fun in that?)
Well, I can tell for starters,as someone with an account with legacy assignments data (i.e., sometimes non-existent), the script fails to even finish calculating. At least, that’s my assumption for the reason why. Actually, I’m pretty sure that assignments can be nonexistent when there just haven’t been any assignments yet. Like the item hasn’t had a lesson. Either way, my suggestion remains the same.
I would suggest figuring out a backup plan for when obj.assignments is undefined.
Hm, that’s never happened to me before even when I first start a level (at which time none of the items have had a lesson.) Wouldn’t hurt to have a check and a backup like you say, but I’ll have to think about what could be causing that.
Hmm, then maybe it is account-related after all. 
Anyway, also, if you end up using wkof.turbo.on.common.dashboard(callback), I would move the install_css() outside of init() and not call init() separately, or some other manner along that sort. Since it is already set up to essentially guarantee running on the page.
El well checking the API reference, it doesn’t guarantee there will be an assignment until it’s unlocked. So maybe I’ve just been lucky? I just added a check for undefined, see if that works (because I can’t see the problem, but I think that should fix it)
