Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-data, which targets the jQuery data function.

Steps to reproduce

Proposed resolution

Remaining tasks

See #9 for questions about direction.

  • In core/.eslintrc.jquery.json Change "jquery/no-data": 0, to "jquery/no-data": 2, to enable eslint checks for uses of jQuery .data(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
  • Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
    # @todo Remove the next chunk of lines before committing. This script only lints
    #  JavaScript files that have changed, so we add this to check all files for
    #  jQuery-specific lint errors.
    cd "$TOP_LEVEL/core"
    node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
    
    CORRECTJQS=$?
    if [ "$CORRECTJQS" -ne "0" ]; then
      # No need to write any output the node command will do this for us.
      printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
      STATUS=1
      FINAL_STATUS=1
    fi
    cd $TOP_LEVEL
    # @todo end lines to remove

    Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

  • If it's determined to be feasible, refactor those uses of jQuery .data() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
#21 3239535-nr-bot.txt3.9 KBneeds-review-queue-bot

Issue fork drupal-3239535

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Theresa.Grannum created an issue. See original summary.

Theresa.Grannum’s picture

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mstrelan made their first commit to this issue’s fork.

mstrelan’s picture

Status: Active » Needs work

Might need some guidance from the big brains on this one. jQuery's data function has two purposes, one for getting and setting data attributes on elements and another for getting and setting arbitrary bits of data in an internal cache for an element. It seems the former can be addressed using the dataset property (as per ajax.js) whereas the latter may can use a WeakMap object (as per tabbingmanager.js). Is this the right approach?

quietone’s picture

Issue summary: View changes
Issue tags: +Needs architectural review

Since this needs some input on direction, I am adding the 'Needs architectural review' tag and changing to NR. Added and item to the remaining tasks to get answers to those questions.

shubh_’s picture

checking this issue..

nod_’s picture

To reply to #9 Let's first make the changes for the getting/setting data attributes using dataset, let's leave the second use case alone (like vertical tabs) because it'll need something else than a straight replacement of the jquery call (probably some new architecture for these things).

@shubh511 I think you're still working on it but please make sure to test the code before setting this to Needs review, as-is the code is not going to work, jquery doesn't have a setAttribute function. Also with data attributes let's use element.dataset.someThing = 'value'; instead of element.setAttribute('data-some-thing', 'value');

shubh_’s picture

raised a MR for this issue but the problem is that it is failing pipeline and when fixing one test case will result in failing another test case and viceversa..

kostyashupenko’s picture

Assigned: Unassigned » kostyashupenko

Gonna kill this task

kostyashupenko’s picture

Still on it

kostyashupenko’s picture

Assigned: kostyashupenko » Unassigned

There are still several existing data() methods:

% yarn lint:core-js-passing

core/misc/ajax.js
  1104:17  error  Prefer WeakMap to $.data  jquery/no-data
  1111:31  error  Prefer WeakMap to $.data  jquery/no-data
  1580:7   error  Prefer WeakMap to $.data  jquery/no-data

core/misc/autocomplete.js
  224:13  error  Prefer WeakMap to $.data  jquery/no-data

core/misc/dialog/dialog.ajax.js
   59:31  error  Prefer WeakMap to $.data  jquery/no-data
   60:13  error  Prefer WeakMap to $.data  jquery/no-data
  105:24  error  Prefer WeakMap to $.data  jquery/no-data

core/misc/tabbingmanager.js
  297:25  error  Prefer WeakMap to $.data        jquery/no-data
  302:9   error  Prefer WeakMap to $.data        jquery/no-data
  314:25  error  Prefer WeakMap to $.data        jquery/no-data
  332:13  error  Prefer WeakMap to $.removeData  jquery/no-data
  340:13  error  Prefer WeakMap to $.data        jquery/no-data

✖ 12 problems (12 errors, 0 warnings)

1. regarding ajax.js and 3 remaining errors - i think all 3 errors can be fixed, but need to research (i just don't have available time anymore for this, so skipped)

2. regarding autocomplete and dialog - there are some data methods which are still exist, which are related to the libraries itself (jquery autocomplete, jquery dialog). I didn't touch those 2 files at all, i think the better way is to wait for replacement of jquery autocomplete in core, and replacement of jquery dialog to native dialog element functionality.

3. regarding tabbingmanager - i didn't understand how to reproduce it in Drupal for making local tests. From what i saw in tabbingmanager.js - this file is fixable in terms of replacing jquery data() method

4. Also i prefer to use getAttribute() instead of dataset, coz getAttribute works seems at least 2x faster https://www.measurethat.net/Benchmarks/Show/14432/0/getattribute-vs-dataset

Sam Phillemon made their first commit to this issue’s fork.

Gauravvvv made their first commit to this issue’s fork.

Gauravvvv’s picture

Status: Needs work » Needs review
needs-review-queue-bot’s picture

Status: Needs review » Needs work
FileSize
3.9 KB

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.