There are two types of options that you can pass into ItemData.get_items(config, global_options):
config.xxxxx.options – This is passed to each data source (xxxxx) individually. The data source is usually wk_items.global_options – This is passed to all data sources, not just wk_items. wk_items forwards it to Apiv2.get_endpoint(endpoint_name, options) as the options parameter.
So, you should be able to call:
wkof.ItemData.get_items(your_config, {force_update:true});
Edit: Although it’s easy to miss, this is how the github documentation describes it:
wkof.ItemData.get_items([config [, global_options]])
config - (optional) A string or object that specifies the data sources and filters to be used in fetching the desired items. (Described in detail below).global_options - (optional) An object that specifies options to be passed as a second parameter to all fetcher functions, including wkof.Apiv2.get_endpoint() and wkof.Apiv2.fetch_endpoint(), which are used by wkof.ItemData.get_items(). (See Apiv2 section for details).
1 Like
This appears to work. I will definitely know when I get a small review to test.
In any way, as I have explained in the previous post, I believe this is a bad idea. If all scripts that wanted updated data do the same thing there is no working cache.
force_update doesn’t actually invalidate the cache. It just forces wkof to immediately check if there are any updates, and update the in-memory object accordingly. Without force_update, wkof is going to check for updates again anyway, but it won’t check more than once per minute. I don’t want to do a check upon every pageload because users frequently navigate through the site without actually needing updated data.
If a script really needs the update immediately, I would recommend that the script monitor for specific circumstances that cause data to be updated. Long ago, I briefly considered having wkof monitor the lessons and reviews, but my fear was that it would create a maintenance nightmare, which I think the last few years of maintaining Double-Check has confirmed. Right now, wkof is totally passive, only performing actions upon request from scripts, and I think that has allowed it to be surprisingly stable.
2 Likes
Got it. Thanks for replying.
@rfindley I just made a one item review session. Your solution worked like a charm. Thanks again.
It seems like with the Sept 24 content push wkof.ItemData.get_items(‘assignments,include_hidden’) is throwing an error:
Uncaught (in promise) TypeError: can't access property "assignments", subjects[subject_id] is undefined
I saw some items in queue manipulator that when it went through sort the item was undefined. I’m just wondering if this is unique to me that a bunch of scripts broke yesterday, or if it’s a known issue that might have a fix coming in the near future.
I don’t know if this is due to the dashboard upgrade but I noticed the settings dropdown doesn’t show a scroll bar when it is too long to fit the screen
I have a strange bug with the menu module.
- When I refresh my browser all settings link are properly defined and working.
- When I customize the dashboard and return to the dashboard by clicking on the Wanikani image in the top bar, the <Settings link menu won’t expand so I can’t get to the settings.
After customizing the dashboard when I examine the <Settings menu option all the settings links seems properly defined to me. I see no problem with the <Settings link itself.
The workaround is to refresh the browser. But the link should be working without having to refresh. I am stumped. What should I do? Any suggestion?
This is not a problem with a particular script. All my scripts are affected because the <Settings menu option won’t expand.
I’m guessing the JS event handlers are getting deleted or disconnected somehow. I don’t think I can look into it this week, but the first place I would start is to check what event handlers are connected to the various menu-related html tags, before and after. (Events are listed on one of the sub-tabs of the CSS window in devtools.)
1 Like
It is the <Setting menu that doesn’t respond. I can’t get to the individual scripts links. I am not sure how event handlers are related to that.
I have noted that in the browser address bar the www.wanikani.come becomes www.wanikani.com/# (note the extra #) and everything jams there.
I checked the event handlers.
- When I refresh the browser all the individual links have click() event handlers. The <Script submenu doesn’t have a handler.
- When I go to Customize Dashboard and return to the dashboard no link have handlers. The <Script submenu doesn’t have handlers.
If I understand correctly the handlers are provided by the Open Framework. Is there something I can do about it?
We’ll have to figure out a way to detect when the menu is updated (or whatever WK is doing), and re-add the handlers. Probably need to dig through some WK code to understand its design pattern.
1 Like
Could the lack of handlers explain why the <Settings submenu won’t even open?
Yes, wkof adds a click handler that toggles the presence of an “open” class.
1 Like
The problem always occurs after a new page load. I guessed the event handlers could be reinstated in a Turbo:load event driver. Guess what? It works. I submitted a Pull Request on github.
Alright, so tentatively, I may have figured out a wkof.on_frameload() function to pair with the wkof.on_pageload() functionality added some time back. This is especially relevant with the new dashboard widget system where each widget is a turbo frame and those frames aren’t guaranteed to have their contents when turbo:load is fired or the document is ready. It also helps significantly with handling the case of multiple of the same widget/frame being on the page at once.
I’m going to continue to do some testing outside of my toy script (by utilizing my actual Show Total Lesson Count script which interacts with the Today’s Lessons frame) but wanted to ask how best I should submit this code for review/discussion since the github repo is fairly out of date at the moment but trying to coherently put all the changes here wouldn’t be the best and nor would trying to provide a diff block since this isn’t an adjustment or fix for something.
I’m glad I moved on to testing with my actual script because it’s been 3 days of a lot of fixing small logic errors that piled up. But I think I got it, or at least something that could be considered ‘experimental’ instead of fully unstable. It helped clean up my script quite a bit even if the length is only 100 lines shorter – which can be seen at my repo comparing main to the frame-load branch – so I would love if I could contribute it to open framework.
Doing that via the github would be best, but it’s 2 years out of date and I’d prefer rfindley to get the repo synced with the current greasyfork version before making a PR there for review.
I’m finally seeing the light of day after some crazy work and home projects coming to a close. There’s a chance I might actually be able to work on this in the next few days.
1 Like
