Kuma: jQuery-UI ~ What happens if we remove it?

[schalkneethling]

We have two bundles related to jQuery-UI inside common.py:

'jquery-ui': {
    'source_filenames': (
        'js/libs/jquery-ui-1.10.3.custom/css/ui-lightness/jquery-ui-1.10.3.custom.min.css',
        'styles/libs/jqueryui/moz-jquery-plugins.css',
        'css/jquery-ui-customizations.scss',
    ),
    'output_filename': 'build/styles/jquery-ui.css',
}

...

'jquery-ui': {
    'source_filenames': (
        'js/libs/jquery-ui-1.10.3.custom/js/jquery-ui-1.10.3.custom.min.js',
        'js/libs/jquery-ajax-prefilter.js',
        'js/moz-jquery-plugins.js',
    ),
    'output_filename': 'build/js/jquery-ui.js',
}

It is being used in the following files:

kuma/kuma/dashboards/jinja2/dashboards/revisions.html
kuma/kuma/users/jinja2/users/ban_user_and_cleanup_summary.html
kuma/kuma/users/jinja2/users/ban_user_and_cleanup.html
kuma/kuma/users/jinja2/users/user_detail.html
kuma/kuma/users/jinja2/users/user_edit.html
kuma/kuma/wiki/jinja2/wiki/create.html
kuma/kuma/wiki/jinja2/wiki/edit.html
kuma/kuma/wiki/jinja2/wiki/move.html
kuma/kuma/wiki/jinja2/wiki/translate.html

The purpose of this issue

Determine answers to the following:

1. How badly does the above break if we remove jQuery-UI?
   1.1 How much work would it be to fix what breaks?
2. Where can we safely remove it? (here I am especially interested in everything inside /users/

If we cannot entirely remove jQuery-UI, we might want to look at upgrading it as the legacy version of this library is currently set to 1.11.4 and we are on 1.10.3.

Some of this is related to wiki editing which will go away at some point in 2020 but, dashboards and /users/ is unrelated and will still live on for some time(years?)

Next steps

Research
Share thought, comments, ideas

[evanplaice]

How badly does the above break if we remove jQuery-UI?

The following would need to be replaced

• autocomplete inputs
• datepicker inputs
• tag-it inputs

1.1 How much work would it be to fix what breaks?

Autocomplete

The autocomplete input is built as a jquery-ui custom widget extension

This could be replaced w/ a 100% vanilla solution using <datalist> + AJAX fetch but browser compatibility for that element is spotty at best (https://caniuse.com/#feat=datalist)

The awesomeplete lib could be used as a non-vanilla solution.

The source for the autocomplete widget definition is located in /kuma/static/js/moz-jquery-plugins.js

On evaluation, the widget is attached to the global $ namespace. It gets called as part of a $ chain, for example...

kuma/static/js/dashboard.js

$('#id_topic').mozillaAutocomplete({
    minLength: 3,
    labelField: 'label',
    autocompleteUrl: '/' + currentLocale + '/dashboards/topic_lookup',
    buildRequestData: function (req) {
        // Should add locale value here
        req.locale = getFilterLocale();
        req.topic = req.term;
        return req;
    }
});

Datepicker

The datepicker input is a built-in feature of jquery-ui

It could be replace w/ <input type="date"> but again, browser support isn't 100% (https://caniuse.com/#search=input-date)

The datepicker is bound to a HTML element as part of a $ call chain. Ex...

kuma/static/js/dashboard.js

$('#id_start_date, #id_end_date').datepicker();

Tag-It

The tag-it input is a built-in feature of jquery-ui

There is no vanilla HTML/JS feature that mimics a 'list of tags w/ autocompletion' input.

The awesomeplete lib will work as an alternative.

The tagit is bound to a HTML element as part of a $ call chain. Ex...

kuma/static/users.js

$('#tagit-interests').tagit({
    availableTags: window.INTEREST_SUGGESTIONS,
    allowSpaces: true,
    singleField: true,
    singleFieldNode: $('#id_user-interests'),
    onTagAdded: rebuildExpertiseTaglist,
    onTagRemoved: rebuildExpertiseTaglist,
    onTagClicked: rebuildExpertiseTaglist
});

---

kuma/dashboards/jinja2/dashboards/revisions.html

Bound Elements

• #id_user - mozillaAutocomplete
• #id_topic - mozillaAutocomplete
• #id_start_date - datepicker
• #id_end_date - datepicker

The elements are bound in kuma/static/js/dashboard.js

kuma/users/jinja2/users/ban_user_and_cleanup_summary.html

No jquery-ui element bindings found, no .ui-* styles used

kuma/users/jinja2/users/ban_user_and_cleanup.html

No jquery-ui element bindings found, no .ui-* styles used

kuma/users/jinja2/users/user_detail.html

No jquery-ui element bindings found, no .ui-* styles used

kuma/users/jinja2/users/user_edit.html

Bound Element

• #tagit-interests - tagit

The element is bound in kuma/static/js/users.js

kuma/wiki/jinja2/wiki/create.html

Bound Element

• #tagit_tags - tagit

The element is bound in kuma/static/js/wiki-tags-edit.js

Note: This uses a redundant version of tag-it, see Appendix A for details

kuma/wiki/jinja2/wiki/edit.html

Bound Element

• #tagit_tags - tagit

The element is bound in kuma/static/js/wiki-tags-edit.js

Note: This uses a redundant version of tag-it, see Appendix A for details

kuma/wiki/jinja2/wiki/move.html

Bound Element

• #parent-suggestion - mozillaAutocomplete

The element is bound in kuma/static/js/wiki-move.js

kuma/wiki/jinja2/wiki/translate.html

Bound Element

• #tagit_tags - tagit

The element is bound in kuma/static/js/wiki-tags-edit.js

Note: This uses a redundant version of tag-it, see Appendix A for details

---

Appendix A - Redundant Tag-It lib

As I was digging though the source searching for references to jquery-ui, I round that the wiki pages that include a tags listing are using a completely separate and redundant import of the tag-it extension. It can be found in kuma/static/js/libs/tag-it.js.

kuma/settings/common.py*

    'wiki-edit': {
        'source_filenames': (
            'js/wiki-edit.js',
            'js/wiki-edit-draft.js',
            'js/libs/tag-it.js', # <-- redundant import
            'js/wiki-tags-edit.js',
        ),
        'output_filename': 'build/js/wiki-edit.js',
    },

Since, tag-it is already included in the jquery-ui bundle it should be possible to remove this copy altogether.

[schalkneethling]

Wow, thanks so much for all of this @evanplaice 👍 really, really appreciate it. I will have a detailed read through all of this.

[evanplaice]

Sure thing. It's a lot of fun to dig through git history. I considered linking to relevant commits but it's a bit of a mess; the history goes back 6 years w/ multiple refactors.

I'd start working on the refactor but I had issues getting a local admin login running. Followed the directions to a t but I'm getting '403 Forbidden' when I actually try to login.

[schalkneethling]

Hey @evanplaice, could you provide some error logs? Thanks so much

[evanplaice]

Of course.

Here's a screencast of the process. Cloning the repo finishes at 4:30.
https://youtu.be/n1pp9cBvfzk

Here are the logs

• docker.log is the docker-compose logs -f output
• setup.log shows the CLI stdout

https://gist.github.com/evanplaice/48838e986cc88f50ee6b2bd530b95fc1

[evanplaice]

I managed to login to the SQL container. Looks like the super user account was created successfully.

mysql> SELECT username, email, password, is_superuser FROM auth_user WHERE username = "evan";
+----------+----------------------+-------------------------------------------------------------------------------+--------------+
| username | email                | password                                                                      | is_superuser |
+----------+----------------------+-------------------------------------------------------------------------------+--------------+
| evan     | [email protected] | pbkdf2_sha256$36000$n5rvnkPrUT3J$Ctut1zMtYBqsrmXHdLl7nUnUJAQ3TBCazSoiGQnqa0s= |            1 |
+----------+----------------------+-------------------------------------------------------------------------------+--------------+
1 row in set (0.00 sec)

[schalkneethling]

Thanks, @evanplaice, I will have a look.