-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Framework: Remove deprecations slated for 3.7 removal #9163
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
Conversation
| 'jest/globals': true, | ||
| }, | ||
| globals: { | ||
| wpApiSettings: true, |
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.
Aside: I was excited for a moment that we'd removed our last global. Then I saw we still have wp in eslint/config.js. Looking at remaining usage, I'm inclined to think we should just update those remaining few to at least point to window.wp so we can remove / discourage any other use of the global.
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.
Actually, it looks like there's no direct wp global usage anymore.
Edit: There is but it's not being caught by eslint when I removed the config
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 still see some wp.oldEditor and wp.codeEditor?
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.
yes, not sure why eslint is not catching them when I remove the global from eslint/config.js
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.
Notice that I removed the global from the config and the test is still passing. Any idea why?
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 it's eslint-config-wordpress:
The false value is a bit misleading. It means that the variable is considered a global, but it's not allowed to be replaced:
https://eslint.org/docs/user-guide/configuring#specifying-globals
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 behavior of false is a bit frustrating as well because it makes it unclear how a project like ours could override the default config to disallow the global. Maybe worth discussing in tomorrow's JS chat?
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.
We already said we'd provide a new eslint package in Gutenberg with the updated guidelines discussed in previous meetings. We can remove these globals entirely from this new package.
We can discuss removing the globals altogether (as part of our new JS coding standards for ESnext)
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.
We already said we'd provide a new eslint package in Gutenberg with the updated guidelines discussed in previous meetings.
It's still an open question as to whether wp would be a global we want to include in the default configuration, assuming a plugin might expect to use those globals rather than import from npm packages.
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.
That's true, maybe we should keep it and just override it in Gutenberg (if possible).
| ( function() { | ||
| var editorSettings = %s; | ||
| window._wpLoadGutenbergEditor = new Promise( function( resolve ) { | ||
| wp.api.init().then( function() { |
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.
Pretty happy about this one :)
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.
Next to eliminate domReady and the promise altogether 😉
components/code-editor/index.js
Outdated
| import Spinner from '../../packages/components/src/spinner'; | ||
|
|
||
| /** | ||
| * Moddule constants |
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.
Typo: "Moddule" -> "Module"
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.
This will be wrongly associated with the variable declaration as its JSDoc.,
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.
"Module constants" demarcations are useless and encourage a bad practice (a pattern to avoid meaningful documentation of top-level variables).
aduth
left a comment
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 Categories block apparently still uses some selectors from core-data and errors with these changes.
packages/components/CHANGELOG.md
Outdated
| @@ -0,0 +1,3 @@ | |||
| ## v3.0.0 (Unreleased) | |||
|
|
|||
| - `withAPIData` has been removed. Please use the Core Data module or `@wordpress/apiFetch` directly instead. No newline at end of file | |||
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.
Correct name is @wordpress/api-fetch
packages/core-data/CHANGELOG.md
Outdated
| - Breaking: `getCategories` resolvers has been deprecated. Please use `getEntityRecords` resolver instead. | ||
| - Breaking: `select("core").getTerms` has been deprecated. Please use `select("core").getEntityRecords` instead. | ||
| - Breaking: `select("core").getCategories` has been deprecated. Please use `select("core").getEntityRecords` instead. | ||
| - Breaking: `select("core").isRequestingTerms` has been deprecated. Please use `select("core").getEntitiesByKind` instead. No newline at end of file |
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 select("core").isRequestingCategories is missing here.
| * | ||
| * @param {string} url Site url. | ||
| */ | ||
| export function unstable__setSiteURL( url ) { // eslint-disable-line camelcase |
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.
Just a thought: I wish there was an easy way to package the unstable pieces in one place, ala python's __future__ module. The more I think about that, the more convinced I am using the unstable__* prefix is the right trade-off, though.
Publishing a @wordpress/unstable package could lead to some potential conflicts due the dependance on other @wordpress packages to implement the unstable features. Publishing @wordpress/components-unstable for every package we maintain is a logistic burden (and suffers from the same problems than @wordpress/unstable approach). Package those APIs in subpaths such as components/unstable, data/unstable, etc would expose them at the root level path anyway.
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.
Just a thought: I wish there was an easy way to package the unstable pieces in one place, ala python's
__future__module.
What would be the proposed advantage of this pattern?
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.
To centralize the unstable APIs in a way that's clearly communicated and maintained. At the moment, we are using different name patterns (unstable__SomeThing, unstableSomething, and can see how in the future someone could also add unstable_SomeThing) which doesn't scale well.
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.
Don't forget __experimentalSomething
😆
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.
Has already happened! 😅
packages/core-data/CHANGELOG.md
Outdated
| ## v2.0.0 (Unreleased) | ||
|
|
||
| - Breaking: `dispatch("core").receiveTerms` has been deprecated. Please use `dispatch("core").receiveEntityRecords` instead. | ||
| - Breaking: `getCategories` resolvers has been deprecated. Please use `getEntityRecords` resolver instead. |
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.
We should get rid of the last usages of getCategories and isRequestingCategories.
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.
Also, should say:
- Breaking:
getCategoriesresolver ...
docs/reference/deprecated.md
Outdated
| - `wp.data.select("core").getTerms` has been deprecated. Please use `wp.data.select("core").getEntityRecords` instead. | ||
| - `wp.data.select("core").getCategories` has been deprecated. Please use `wp.data.select("core").getEntityRecords` instead. | ||
| - `wp.data.select("core").isRequestingCategories` has been deprecated. Please use `wp.data.select("core/data").isResolving` instead. | ||
| - `wp.data.select("core").isRequestingTerms` has been deprecated. Please use `wp.data.select("core").getEntitiesByKind` instead. |
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 guess
wp.data.select("core").isRequestingTermshas been deprecated. Please usewp.data.select("core").getEntitiesByKind
should be modified to
wp.data.select("core").isRequestingTermshas been deprecated. Please usewp.data.select("core/data").isResolving
| - Breaking: `getCategories` resolvers has been deprecated. Please use `getEntityRecords` resolver instead. | ||
| - Breaking: `select("core").getTerms` has been deprecated. Please use `select("core").getEntityRecords` instead. | ||
| - Breaking: `select("core").getCategories` has been deprecated. Please use `select("core").getEntityRecords` instead. | ||
| - `wp.data.select("core").isRequestingCategories` has been deprecated. Please use `wp.data.select("core/data").isResolving` instead. |
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.
Should this say Breaking: wp.data.select ...?
packages/core-data/CHANGELOG.md
Outdated
| - Breaking: `select("core").getTerms` has been deprecated. Please use `select("core").getEntityRecords` instead. | ||
| - Breaking: `select("core").getCategories` has been deprecated. Please use `select("core").getEntityRecords` instead. | ||
| - `wp.data.select("core").isRequestingCategories` has been deprecated. Please use `wp.data.select("core/data").isResolving` instead. | ||
| - Breaking: `select("core").isRequestingTerms` has been deprecated. Please use `select("core").getEntiisResolvingtiesByKind` instead. No newline at end of file |
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.
Please use wp.data.select( 'core/data' ).isResolving instead
docs/reference/deprecated.md
Outdated
|
|
||
| - `wp.components.withAPIData` has been removed. Please use the Core Data module or `wp.apiFetch` directly instead. | ||
| - `wp.data.dispatch("core").receiveTerms` has been deprecated. Please use `wp.data.dispatch("core").receiveEntityRecords` instead. | ||
| - `getCategories` resolvers has been deprecated. Please use `getEntityRecords` resolver instead. |
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.
This should say:
getCategoriesresolver ...
|
Left a few comments about typos. Would it be cool for me to push directly to solve them next time? Don't want to mess with your local changes, but sometimes it feels more work to left the comment that fixing it myself. Tested a few things that involve categories, and also the code editor. Unsure if there's anything else I should test. Let me know if you want any thing specific tested. Other than that this seems ready to ship. |
|
Yes, feel free to make changes, I don't min ;). I already updated though :) |
| categories: getCategories(), | ||
| isRequesting: isRequestingCategories(), | ||
| categories: getEntityRecords( 'taxonomy', 'category', query ), | ||
| isRequesting: isResolving( 'core', 'getEntityRecords', 'taxonomy', 'category', query ), |
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.
Is this the correct usage? Specifically the 'core' argument
| function isResolving( selectorName, ...args ) { |
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.
yes, this is the correct usage because I'm using the root one. The selector in core/data not the selector in core. I wasn't even aware of the existence of the selector in core.
I think I'm against having this selector in core unless it's made generic (added automatically to all stores)
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 my head is made to spin by the fact that core/data is the reducer key for packages/data and core is the reducer for packages/core-data 😖
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.
Ok then so isn't it still being used wrongly because args is expected as an array, not a spread?
| export function isResolving( state, reducerKey, selectorName, args = [] ) { |
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.
Yes, we should probably change that. A graceful transition would be to change core/data and alias it with something like data (or something else) and deprecated core/data and then after sometime do the same thing for core (core-data)
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.
True, it's still wrong, It's not the first time either this difference in passing arguments trick me.
packages/core-data/CHANGELOG.md
Outdated
| @@ -0,0 +1,8 @@ | |||
| ## v2.0.0 (Unreleased) | |||
|
|
|||
| - Breaking: `dispatch("core").receiveTerms` has been deprecated. Please use `dispatch("core").receiveEntityRecords` instead. | |||
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.
It should be:
## v2.0.0 (Unreleased)
### Breaking Change
- `dispatch("core").receiveTerms` has been deprecated. Please use `dispatch("core").receiveEntityRecords` instead.
...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 copied from another package :)
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.
Just saw that there's a bunch of package that don't follow the guidelines :) I'll update them as well.
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.
Thanks, we merged those guidelines a few days back, so I'm sure we need to be more proactive with enforcing what we agreed on :)
packages/data/CHANGELOG.md
Outdated
| @@ -1,4 +1,5 @@ | |||
| ## v2.0.0 (Unreleased) | |||
|
|
|||
| - Breaking: The `withRehdyration` function is removed. Use the persistence plugin instead. | |||
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 same as above:
## v2.0.0 (Unreleased)
### Breaking Change
- The `withRehdyration` function is removed. Use the persistence plugin instead.
...
gziolo
left a comment
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.
Super cool to see so many files removed 👍
|
I updated the changelog files to match our guidelines, I borrowed the "Internal" and "Polish" titles for some items in the changelog from Babel like suggested by @gziolo |
53de1e4 to
96ff92f
Compare
| "dependencies": { | ||
| "@babel/runtime-corejs2": "7.0.0-beta.56", | ||
| "@wordpress/compose": "file:../compose", | ||
| "@wordpress/deprecated": "file:../deprecated", |
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.
package-lock.json needs to be updated.
gziolo
left a comment
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 didn't discover any issues when testing changes introduced in this PR.
Code changes look good. It's great to see all those obsolete code removed 💯
|
🎉 |
|
@aduth Do you have link for |
|
@phpbits There is no provided replacement, as the intent with removing For what it's worth, since it's published as an npm package, |
|
@aduth Thanks for the response. I've decided to use |
This PR removes deprecations scheduled to be removed in the upcoming 3.7.0 release.
wp.components.withAPIDatahas been removed. Please use the Core Data module orwp.apiFetchdirectly instead.wp.data.dispatch("core").receiveTermshas been deprecated. Please usewp.data.dispatch("core").receiveEntityRecordsinstead.getCategoriesresolvers has been deprecated. Please usegetEntityRecordsresolver instead.wp.data.select("core").getTermshas been deprecated. Please usewp.data.select("core").getEntityRecordsinstead.wp.data.select("core").getCategorieshas been deprecated. Please usewp.data.select("core").getEntityRecordsinstead.wp.data.select("core").isRequestingTermshas been deprecated. Please usewp.data.select("core").getEntitiesByKindinstead.wp.data.restrictPersistence,wp.data.setPersistenceStorageandwp.data.setupPersistencehas been removed. Please use the data persistence plugin instead.Since we removed
withApiData, we don't needwp.api.initanymore. And some inline scripts as well.