-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Global Styles: refactor how we iterate over the tree #30801
Conversation
Size Change: -30 B (0%) Total Size: 1.43 MB
ℹ️ View Unchanged
|
This is ready for review. |
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 personally don't like the fact that we rely on intermediary objects like "$metadata", one person reading the code reading the code need to wrap its head around these and understand these structures while a function to retrieve css_variables from theme.json is more straightforward. It just requires one to know the input "theme.json" and the output "css variables".
I also don't like that we actually test internal implementation details because it prevents folks from doing refactoring. Do we expect users of the class to call get_setting_nodes
and get_style_nodes
from the outside or are these constructions just internal implementation details in which case in which case the unit test is not really a good idea for me unless we want to test something critical?
I guess this is me saying that I'd prefer if we remove the arguments and block_metadata
entirely.
I also say this acknowledging that it's not that important. In other words
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.
Despite my opinion on how to architecture code, this doesn't bother me much, the important right now is that we implement the new schema rapidly and if this is a step towards that, I'm fine with it.
I guess it's safer to go with the intermediate approach where we use those lower-level functions that are easier to test. However, on principle, I totally agree that in the end, we should have a much higher-level API that tests everything integrated together. |
Yes to revisit the higher-level APIs after the new shape is in place ― and with the help of an extensive test suite I feel way more comfortable 🙂
I'm also uncomfortable making I'm going to merge this one to continue the work. |
#31224 made the utility methods private and removed the tests as well. |
Extracted from #30541 so it can land in pieces and make reviews easier/quicker.
This PR refactors the existing
WP_Theme_JSON
methods so they operate over nodes and so are independent of the theme.json structure. The logic about which paths to iterate over (the structure of theme.json) is centralized in two methods:get_style_nodes
andget_setting_nodes
. After this change, #30541 only has to update theget_style_nodes
andget_setting_nodes
logic to compute the paths based on the new structure ― the other methods will remain unchanged.Perhaps the quickest way to review this PR is going commit by commit and compare the before/after changes. It doesn't change any behavior, only the internal logic of the methods ― I tried to keep each commit isolate for ease of review.
How to test
npm run test-unit-php /var/www/html/wp-content/plugins/gutenberg/phpunit/class-wp-theme-json-test.php