Standardize to using runAbility to call our Abilities#228
Standardize to using runAbility to call our Abilities#228dkotter wants to merge 4 commits intoWordPress:developfrom
runAbility to call our Abilities#228Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #228 +/- ##
=============================================
+ Coverage 56.76% 56.83% +0.06%
Complexity 505 505
=============================================
Files 32 32
Lines 2565 2562 -3
=============================================
Hits 1456 1456
+ Misses 1109 1106 -3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
2 participants
What?
Move from using
apiFetchto using our customrunAbilityutility function (introduced here) to call our Abilities in our UI code.Why?
Ensures our codebase is standardized (no more fractured code that uses
apiFetchin some places andrunAbilityin others.Also ensures the Abilities JS API is used when available, falling back to using
apiFetchotherwise.How?
runAbilityand remove the direct use ofapiFetchpathJS localized dataUse of AI Tools
Used Cursor (running Composer 1.5) to give a first pass on making this change with final changes, plus review and testing, done by me
Testing Instructions