[Userscript] WaniKani Open Framework Date Filters

Yes, if I remember correctly, that was the original intent of the ‘button’ type.

I would have to study the ‘html’ type more to be sure how to implement an associated value.

1 Like

How do we inform the framework of which value(s) to pass as a parameter to a filter? I don’t see support for this in the documentation.

Currently, there is no way to specify.
Since all filters are currently only one field, the value is extracted as elem.val() inside the on(‘change’) event.

If you use something like ‘html’ or ‘button’, your html (for ‘html’) or popup (for ‘button’) could include a unique tag for the field, and your filter could fetch and interpret the field.

Yes. You are the second one to mention something like this. @Kumirei too seems to prefer Date.parse in most circumstances. But in the Mozilla documentation I find this.

Note: Parsing of strings with Date.parse is strongly discouraged due to browser differences and inconsistencies.

And here there is more details

It is not recommended to use Date.parse as until ES5, parsing of strings was entirely implementation dependent. There are still many differences in how different hosts parse date strings, therefore date strings should be manually parsed (a library can help if many different formats are to be accommodated).

This scares me a bit. By nailing the format I work around these differences. But if I am wrong I am willing to hear about it.

1 Like

Well, mozilla.org is generally a good source, so I can’t argue with that.

For my part, I’ve just found that browser developers are almost always more knowledgeable about the wide variety of differences in date representation around the world. I learned that lesson with Ultimate Timeline :slight_smile:

2 Likes

I don’t understand. A html or dialog contains several fields. Which one will be the elem for elem.val() purpose? And how is this information available to the filter? The information is different for each preset in each script. How do I locate the correct one from a filter? Do I miss something?

In the wkof Settings module [here], it calls an event handler depending on the type of element:

dialog_elem.find('.setting[multiple]').on('mousedown', toggle_multi.bind(null,context));
dialog_elem.find('.setting').on('change', setting_changed.bind(null,context));
dialog_elem.find('form').on('submit', function(){return false;});
dialog_elem.find('button.setting').on('click', setting_button_clicked.bind(null,context));

Most input types have class .setting, so it is handled in the setting_changed() function, which has call spec setting_changed(context, event).

And elem = $(event.currentTarget)

For button types, it simply calls the on_click handler, and it’s up to you to check your own values when the user clicks the close button in your pop-up dialog.

I don’t remember enough about ‘html’ to know how it works.

Of course, I didn’t implement all features of wkof in Self-Study. I figured I would add support as coders needed them, which usually helps define how those features should be implemented.

[edit:]
Regarding html, the event handlers above will still affect elements inside an ‘html’ object. So, if you tag your fields with .setting, the event handler will be called. So, take a look at setting_changed() in the Settings module (linked at the top of this post) to see how it handles events on .settings objects. There may be a way to get it to respond correctly to custom html types.

Supporting locale date formats is a rabbit hole. There are entire libraries available to work around Date.parse limitations. There is no way to get it right without resorting to such a library. I don’t want to go that route. I think this is overkill for Wanikani scripting purposes. This is why I have cut off locale date support.

But I sense an appetite from two prominent developers to use whatever Date.parse provides. Perhaps I should add this as an option in my collection of time functions because opinions differ on this matter.

From my perspective, I wouldn’t claim an ‘appetite’. I just saw you putting in the work to parse dates, and thought the ‘lazy’ method might work, and avoid some potential locale pitfalls in the process. But you make valid points, too.

1 Like

I wouldn’t either. It’s just that for my purposes as a hobbyist scripter Date.parse is very convenient and works well enough. Also I literally learned to program on here and haven’t really done anything else, so people shouldn’t listen to me

1 Like

i avoid these pitfalls by not supporting locale. I agree that if someone wants to support locale Date.parse is the most sensible way for wanikani scripting purposes.

2 Likes

I’m still amazed how much and how fast you’ve learned. It doesn’t matter where you learn it. As long as you never stop learning, you’re worth listening to! :slight_smile:

2 Likes

You are a better script programmer than I am. Of course I will listen to you.

1 Like

Even if that’s true it wouldn’t mean my coding practices are correct sweat_smile I’m sure I have plenty of bad habits

1 Like

I will look into this but not now. I have a plan for filters that may use html but I have other projects that take priority. Let’s postpone this discussion until it is time to do my filter.

Version 1.1.0 is out - Download it at the link in the top post.

Added the support for relative time at the suggestion of @rfindley

Version 1.2.0 is out - Download it at the link in the top post.

Added support of wkof.wait_state('dateFilters', 'ready'). Developers may now synchronize with the filters initialization.

It is now version 1.2.3

I had problems getting the right file on greasyfork. It is fixed now.

Version 1.3.0 is out. - You may install it at the link at the top post.

Adds filters relative to the date of the last review.

A note to developers.

The code is now released under the MIT license and is available on github