Generally I go with not having to use await on async functions if I attach .then to them. It shouldn’t matter here either because nothing after the ready calls depends on the modules being ready; everything that depends on ready resolving is contained in the callbacks from the .thens.
This is true if everything afterward is contained within the then.
In the case of your script
if (INTERNAL_FORCE_DEBUG_OUTPUT) printDebugLog(INTERNAL_FORCE_DEBUG_OUTPUT);
gets called immediately after the earlier promise is made.
But like we both said, it’s not a big deal.
Edit:
Oh. I meant to mention, I pushed an update taking the earlier suggestion in mind, but also expanding on it a bit to see if it has anything to do with it.
I know… that’s why I specified
The debug printing specifically does not depend on the promises, I want it to print regardless of their resolution (in which case I should probably attach some .catches and .finallys, I’ll do that in the next update).
@LupoMikti, I created a basic version that accommodates handling versions.
I don’t know if there’s anything I’m missing, but aside from that and any huge refactors, I believe it should function.
The only problem I was having was making it so older scripts wouldn’t end up overwriting it. I.e., any script prior to the version system implementation, though I figured out a brute force solution for that (the older ones will throw an error, but it’ll end up being fine).
Pushing in a few minutes.
Pushed, and OP updated (new greasyfork versionId = 1423213)
1 Like
@LupoMikti and @prouleau,
First things first. I noticed an oversight in my version handler. Versions 2.2.3 and earlier won’t have the exposed internal property, so there’s no way for me to remove the existing handler(s) for those versions in a later version.
However, the way it’s currently (previously) managed, it’ll quietly give up on loading if it can’t find the property.
So, obviously I’ve changed that.
It’ll now overwrite the existing version to the best of its ability, but since those existing handlers might not be accounted for, it’ll display a message to the user (which can be hidden for 7 days clicking “OK”) that something is awry. Though this isn’t really that important, since it’s unlikely people will be using those versions.
Now… for the hard part.
In light of these issues we’ve been working through, I decided it would be best for me to do a major refactor to remove as many assumptions as possible, starting with the event options.
The README offers a table with details about what the options parameter accepts and what they do.
I was able to replicate the double-event firing issue, though I wasn’t really able to completely understand why it happened. However, I have a pretty good guess, because changing the way the internal events are structured seems to have fixed it for me. Btw, while I was working through possible solutions, I removed the special case "load" event from the “typical” listener in lieu of turbo:load by itself, and I plan to deprecate or remove that functionality in the future anyway.
Anyway, check out the new update (1423969) when you find some time.
The new update doesn’t fire the events. I see them firing from window.addEventListener() but not from wkof.turbo.on.event.xxx Is there a change that could explain this behavior?
Anyway it is time to go to bed and I will be busy with real life events tomorrow. I will resume debugging Friday.
Is there a particular setting under which it doesn’t fire? Or are you getting any errors in the console that might indicate something?
I have tried various events/settings on my end, but they all have been working consistently.
Whenever you get a chance, this would be helpful. Also, what browser are you using? So that I might focus my test cases on a particular one. Apologies if you’ve mentioned it somewhere already.
I am debugging the script Show Total Lesson Count. No error is displayed. I just don’t see the events fired. Browser is Chrome on Window 10 Professional.
1 Like
Okay, thanks. I’ll take a look into it tomorrow and see if I can find anything.
1 Like
This is strange. I am unable to reproduce this behavior. All I can reproduce is the race condition discussed in the other thread. The new version seems to work fine.
Alright, I’m long overdue for update. I finally feel like I’ve gotten the changes in version 4 under control and to my satisfaction.
Update 4.1.0 is live (greasyfork id 1426289). Updating the links in the OP to match.
I’ll start looking into it.
Nothing jumps out immediately to me why that might be happening though.
For example, I can access wkof.turbo.on.common.lessons_picker in my console on the site.
@MysteryZA I don’t think this will change anything, but on the off chance it does, I pushed a change that reverts an inlining I had done in the previous update. The new link is
https://update.greasyfork.org/scripts/501980/1426667/Wanikani%20Open%20Framework%20Turbo%20Events.user.js
Ah I figured it out, my other script was still using an old version of the turbo events library so that is what was causing the issue. Sorry about that
1 Like
Quite random but I just wanted to plop this here as an FYI.
In the process of returning to update one of my scripts that used this library, I wanted to set up type checking for my repo without needing to download this script locally for the JSDoc stuff present. So I made the start of a proper type definition file that can pulled into a project independently (since I’m using deno, if it was in Inserio’s repo I could’ve just used the URL in my config which is neat).
Here’s a link to that definition file in my repo if anyone (probably no one but me) is interested in using it. It does rely on another type definition file, the wkof.d.ts file that Kumirei originally made for Reorder Omega; that file with some updates from me is also in my repo. I did rename the TurboEvent class to TurboWrapper and then renamed a few types accordingly to dispel some confusion I was having reading the library source.
Thanks to Inserio for all the effort that went into making this library script. I’ll still be making use of it unless Open Framework itself adds an on_frame_load() function to match on_page_load().
1 Like