-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Script Loading Strategy - ML2 #13 - Add get_eligible_loading_strategy
method
#35
Script Loading Strategy - ML2 #13 - Add get_eligible_loading_strategy
method
#35
Conversation
…get_eligible_loading_strategy-ML2-12
…get_eligible_loading_strategy-ML2-12
get_eligible_loading_strategy
method
…enhancement/do_item-ML2-13
get_eligible_loading_strategy
methodget_eligible_loading_strategy
method
…enhancement/do_item-ML2-14
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving feedback (mostly formatting related).
As a process note, I'm find it a bit difficult to follow the way you have PRs set up to merge into milestone branches before merging to the main feature branch. Given that this is meant to be a continuation from #34, I'd love to see us get that merged into the base feature branch you've set up and then set each of these M2 branches to merge into the main feature branch, rather than waiting for all of it to land "at once" as part of a milestone. That way, we're also getting the benefit of seeing the test coverage increase over time, with each PR and will more likely avoid merge conflicts at the end.
src/wp-includes/class-wp-scripts.php
Outdated
} | ||
|
||
// Handling async strategy scenarios. | ||
if ( empty( $this->registered[ $handle ]->deps ) && empty( $this->get_dependents( $handle ) ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd love to see some more test cases set up to confirm that each scenario you're accounting for in this logic tree is working as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joemcgill Test cases are the main reason I had to set a base milestone branch. The way our milestone tasks are, we normally have to get to the last task to test out all the other prior tasks in the milestone.
In milestone 2, get_eligible_strategy
can only be tested via do_item
method ( #38 ) which is a part of different task in same milestone. In milestone 2 all test cases are in PR #38.
Just to be certain that everything in a single milestone works as intended before it goes to the base branch, i created a separate milestone base branch.
…enhancement/do_item-ML2-14
…enhancement/do_item-ML2-14
…enhancement/do_item-ML2-14
src/wp-includes/class-wp-scripts.php
Outdated
return 'async'; | ||
} | ||
|
||
// Handling defer strategy scenarios. Dependency will never be set async. So only checking dependent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kt-12 Do we need to mention Dependency will never be set async. So only checking dependent.
here? I am not following what this means, did you mean to state that dependencies will never be deferred so you're only checking dependents?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@10upsimon So, per the rules, defer can only have 'defer' or 'blocking' dependencies; it can never be 'async'. ( point 1 )
A decision that a script is to be set to async
, defer
, or nothing is made by get_eligible_loading_strategy
.
But, if you check the rules for async
in this function, a script with dependent will never be set async
. ( point 2 ).
From points 1 and 2, I can say if the current script has some dependency, the dependency script will never have async
strategy (as it has a dependent). So we can avoid a recursion check to find strategy in dependencies.
I hope I still don't sound confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@10upsimon I have removed the extra text here.
For visibility sake, as I myself wondered where the unit tests were that handled the various loading strategies, they've been added to the PR for #14 and can be seen at https://github.com/10up/wordpress-develop/pull/38/files#diff-09a2e7959959d6a08ef07b1849e0178b853f7ef86f7885bbf9be2ed261145b24 |
Co-authored-by: Simon Dowdles <72872375+10upsimon@users.noreply.github.com>
Co-authored-by: Simon Dowdles <72872375+10upsimon@users.noreply.github.com>
Co-authored-by: Simon Dowdles <72872375+10upsimon@users.noreply.github.com>
…enhancement/do_item-ML2-14
Co-authored-by: Simon Dowdles <72872375+10upsimon@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The updates are looking good. I left a couple new questions and will do a final review once we have the tests from #14 merged back here so we can ensure everything is covered.
src/wp-includes/class-wp-scripts.php
Outdated
* Get the strategy mentioned during script registration. | ||
* | ||
* @param string $handle The script handle. | ||
* @return string|bool Strategy in script registration, False if not strategy is mentioned.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @return string|bool Strategy in script registration, False if not strategy is mentioned.. | |
* @return string|bool Strategy in script registration, False if not strategy is mentioned. |
src/wp-includes/class-wp-scripts.php
Outdated
* blocking if explicitly set. | ||
* blocking if script args not set. | ||
*/ | ||
if ( ! isset( $this->registered[ $handle ] ) || 'blocking' === $intended_strategy || ! $intended_strategy ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still confused about why script registration is being checked here after the intended strategy instead of before? Can you explain the use case for me?
I'd also suggest splitting this back to multiple lines for readability, just make sure the operators are at the beginning of each line, like the previous suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct. script registration should be above getting intended script. I have made the change.
Now that the condition have become much smaller I have kept it on the same line.
@joemcgill in case you missed it, noting that the PR at #34 was merged into the same base branch this is going to 👍 |
Co-authored-by: Joe McGill <801097+joemcgill@users.noreply.github.com>
…enhancement/do_item-ML2-14
* @param string $handle The script handle. | ||
* @return array Array of script handles. | ||
*/ | ||
private function get_dependents( $handle ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: This needs to be optimised further. Better way of doing this is creating a dependents list as a hash table (added as a Dependencies to WP_Script) and updated dependents while each script is getting registered. get_dependent
will simply fetch dependent from that hash table.
src/wp-includes/class-wp-scripts.php
Outdated
} | ||
|
||
// Handling async strategy scenarios. | ||
if ( empty( $this->registered[ $handle ]->deps ) && empty( $this->get_dependents( $handle ) ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joemcgill Test cases are the main reason I had to set a base milestone branch. The way our milestone tasks are, we normally have to get to the last task to test out all the other prior tasks in the milestone.
In milestone 2, get_eligible_strategy
can only be tested via do_item
method ( #38 ) which is a part of different task in same milestone. In milestone 2 all test cases are in PR #38.
Just to be certain that everything in a single milestone works as intended before it goes to the base branch, i created a separate milestone base branch.
src/wp-includes/class-wp-scripts.php
Outdated
return 'async'; | ||
} | ||
|
||
// Handling defer strategy scenarios. Dependency will never be set async. So only checking dependent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@10upsimon So, per the rules, defer can only have 'defer' or 'blocking' dependencies; it can never be 'async'. ( point 1 )
A decision that a script is to be set to async
, defer
, or nothing is made by get_eligible_loading_strategy
.
But, if you check the rules for async
in this function, a script with dependent will never be set async
. ( point 2 ).
From points 1 and 2, I can say if the current script has some dependency, the dependency script will never have async
strategy (as it has a dependent). So we can avoid a recursion check to find strategy in dependencies.
I hope I still don't sound confusing.
src/wp-includes/class-wp-scripts.php
Outdated
* blocking if explicitly set. | ||
* blocking if script args not set. | ||
*/ | ||
if ( ! isset( $this->registered[ $handle ] ) || 'blocking' === $intended_strategy || ! $intended_strategy ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct. script registration should be above getting intended script. I have made the change.
Now that the condition have become much smaller I have kept it on the same line.
src/wp-includes/class-wp-scripts.php
Outdated
return 'async'; | ||
} | ||
|
||
// Handling defer strategy scenarios. Dependency will never be set async. So only checking dependent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@10upsimon I have removed the extra text here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is looking good now 👍🏻
Script Loading Strategy - ML2 #14 - Update `do_item` method.
Trac ticket:
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.