Separately from the a11y tweaks to the filter-form component mentioned in #1721 and the HTML/layout refacor mentioned in https://github.com/mdn/developer-portal/issues/1752 there is a Django-centric piece of work that would be good to do, even if it is not a blocker:
AC
[ ] Filter form is made much simpler, with checkboxes populated simply during template render on the Django side, rather than filling them based on the querystring.
The result will be cleaner, more idiomatic for a Django app and will satisfy a minor itch spotted in the automated scan of the site.
This change is not super challenging to implement, but does touch a few moving parts.
One needs to work out how to get a form into the Page rendered by Wagtail. Suggestion 1 would be to add it via the relevant Page's get_context() method, as the closest thing to the way we'd do it with a function-based-view in Django
The form will have no required fields, which will help keep it light. We really just want to benefit from Django's auto-binding of Form fields using request.GET
The JS that currently populates checkboxes based on the querystring will need to be pruned down so that it does not do this, while also ensuring the remaining JS (eg for clearing checkboxes) still works. There are JS tests for the related code, plus some HTML fixtures for them that will need updating, too
stevejalim
commented
3 years ago
Separately from the a11y tweaks to the filter-form component mentioned in #1721 and the HTML/layout refacor mentioned in https://github.com/mdn/developer-portal/issues/1752 there is a Django-centric piece of work that would be good to do, even if it is not a blocker:
AC
The result will be cleaner, more idiomatic for a Django app and will satisfy a minor itch spotted in the automated scan of the site.
This change is not super challenging to implement, but does touch a few moving parts.
get_context()method, as the closest thing to the way we'd do it with a function-based-view in Djangorequest.GET