Implement multiple type fields on card upstream / add more hooks to


About 2 years ago I published the Add-On “Multiple type fields on card for 2.1”) (which was really just a port of the Anki 2.0 Add-On “Multiple type fields on card”). However, it has been difficult to maintain it, and it is incompatible with many other Add-Ons (which also rely on replacing methods of the Reviewer to modify how type fields behave), as I wasn’t able to use Hooks.

This is because, essentially, it just changes the self.typeCorrect attribute of the Reviewer from a string to a list, and then changes any methods using this property to use loops. It also adds a JavaScript function to get the answers, though that part hasn’t made any trouble.

I imagine there might be a solution with hooks and filters, but the implementation would probably be complicated, require adding a lot of new hooks as well as further modularization of the original code (i.e. putting things that need to be done in loops into their own functions).

I wanted to ask if I should rather
1.) Leave everything in its current state (my Add-On, when loaded on its own, still works right now, but I expect it to break eventually, and maintainability is low, so I would probably leave it broken),
2.) Try and make this work with Hooks and Filters, making Pull Requests to make the original code more modular and add these Hooks,
3.) Make a Pull Request with my changes to allow multiple type fields.

Both last two options would probably break a few Add-Ons, since I have noticed that it is not rare to directly modify and replace one of the Reviewer.typeAns*Filter methods.

4.) Maybe there is also a fourth option of mostly restructuring my code, only encapsulating and not changing the old code, maybe e.g. changing self.typeCorrect's __get__ and __set__ methods such that it behaves like a stack. I just wanted to ask if you maybe just preferred to add this feature to the original code, in which case I could save myself that work.

TLDR: Is there interest in implementing multiple type fields in the original code base? If not, is it okay to make Pull Requests which modularize code into functions (to be able to reuse them in Add-On code)?

Thank you in advance!


I’d recommend doing nothing for now, as the reviewer and type answer code is likely to be updated in the not too distant future, and multiple fields may possibly even come as part of that.


Ah thank you, that is great to hear.