Depend on php to identify elements and depth

[wordpressfan]

Description

This PR is a reflect of the changes of that PR: wp-media/rocket-scripts#26

Explain how this code impacts users.
It'll not impact users, that's an enhancement.

Type of change

• Enhancement (non-breaking change which improves an existing functionality).

Detailed scenario

Everything is mentioned in the issue itself and grooming discussion.

Technical description

Documentation

We will depend on php to identify elements and depth.

New dependencies

No

Risks

No

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ -0.02% (target: -0.10%)	✅ 100.00% (target: 50.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (d7a5719)	37925	16540	43.61%
Head commit (01ae76e)	37908 (-17)	16525 (-15)	43.59% (-0.02%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#6929)	21	21	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[jeawhanlee]

Would it not be a good idea to pass [data-rocket-location-hash] to the element array here

But just in case you don't think the same, we should remove this whole block then since [data-rocket-location-hash] is now hard coded in the script.

[wordpressfan]

That's a good idea @jeawhanlee

[Mai-Saad]

Working as expected. (includes validation for #6904)

• we can have enhancement later https://wp-media.slack.com/archives/CUKB44GNN/p1725008472171879?thread_ts=1724992642.140039&cid=CUKB44GNN
• if nothing is needed for this now https://wp-media.slack.com/archives/CUKB44GNN/p1725009496716359 then we can merge

[DahmaniAdame]

@MathieuLamiot we will need to revert back to calculating the distance relative to the viewport.

    _getElementDistance(element) {
      const rect = element.getBoundingClientRect();
      const scrollTop = window.pageYOffset || document.documentElement.scrollTop;
      return Math.max(0, rect.top + scrollTop - (window.innerHeight || document.documentElement.clientHeight));
    }

What @Mai-Saad reported here will be complicated to handle as we can't restrict customers to a specific value and it will require a lot of customer education to not cost support time and efforts - https://wp-media.slack.com/archives/CUKB44GNN/p1725009496716359

Sorry for the oversight.

[MathieuLamiot]

@DahmaniAdame to avoid further confusion, I'd prefer we have a dedicated GH issue: not only JS must be changed but also the default threshold value (PHP side).
So we would need the details about this in a dedicated issue (what value exactly? Same for mobile & desktop?, etc.)

Note that this means results will be dependent on the screensize of the person visiting the page. So someone with a small screen might pickup some LRC elements that will be lazy rendered while being in the viewport of another user with taller screen. I am not sure this is the best solution as results won't be always reproducible.

[DahmaniAdame]

Got it. I will create a separate GH issue.

Note that this means results will be dependent on the screensize of the person visiting the page. So someone with a small screen might pickup some LRC elements that will be lazy rendered while being in the viewport of another user with taller screen.

That was the thinking behind it. But it will cause more trouble and confusion for customers.

The relative distance to the viewport is still usable though and should work fine with the constraint that we have now.

Having a couple of elements toggling content-visibility on page load on different screen size is acceptable. We have the same behavior between browsers where the threshold is different as well, and it's acceptable there as well. The 1800 threshold initially had that difference in mind.