WordPress
`react` import should not be restricted
What problem does this address?
In #54074 there was a decent amount of consensus about using (a.k.a. importing) react more directly, instead of from @wordpress/element. However, the @typescript-eslint/no-restricted-imports lint rule seems to prevent it.
What is your proposed solution?
The rule should be removed.
Note: I think it might be worth it to go the opposite direction and restrict imports from @wordpress/element. Along with a full grep+replace which shouldn't be too hard (maybe in stages?). However, for the sake of keeping a reasonable scope, let's leave that for a separate issue/conversation.
The same issue came up in the React compiler PR - https://github.com/WordPress/gutenberg/pull/61788#issuecomment-2142159849.
Thanks @Mamaduka, seems like there's even more reason to do something about this then.
Unless I hear different, I will remove the restriction as a first step, then create a different issue to propose a more active transition (which is pretty much just a grep+replace of imports), and if there aren't any big arguments against it I'll start transitioning imports in chunks until done, and they add the restriction in the opposite direction to enforce importing from "react"
Yeah, I'm totally ok with this change but I'm a bit concerned about losing the consistency and if we want to keep the consistency, then it's going to be a huge commit. Maybe a codemod would help.
@youknowriad I think it'll be fine to have a small transition period, and I can do my best to get PRs pumped out in quick succession. It can be done in maybe a week, as long as I can count on someone's (yours? :D) help with fast reviews.
I think a small number of commits is actually better than a big number of PRs. That way we can add these to .git-blame-ignore-revs
But let's gather more opinions here to see if we're not missing anything. cc @gziolo @jsnajdr
What benefits do we expect from these changes that justify updating the entire codebase and documentation to use React directly?
@gziolo I think the linked discussion should be relevant to your question, but to name one thing that directly impacts me: I get routinely annoyed by auto imports of react stuff resulting in eslint complaining, and having to go back and manually change it to the wrapper. I have to interrupt my flow and go and fix it.
I don't see much value in the @wordpress/element wrapper nowadays, it actually adds friction when a new React version comes out, and questions are coming out, like "what happens if a React drops a utility function and we need to continue to support it because of backward compatibility" or "which version of React should I use now"? By working with react APIs directly, we don't have to deal with these problems outside of the @wordpress/element package, and we leave the BC issues to the consumers to deal with. Also, the only way to no longer have to maintain these BC problems is to deprecate @wordpress/element eventually, which can happen only if the entire codebase has been migrated away from it.
To add to this, what @Mamaduka said about React Compiler not appreciating our @wordpress/element wrapper is valid, and I'm not sure they'll provide a mechanism to natively extend it to inform it that @wordpress/element is a react alias.
Also, this will help with consistency - everyone inside the codebase and outside the codebase will be able to use react imports all along. Right now you can see projects that consume both react and @wordpress/element and that's suboptimal.
It's worth noting that we'll still have to support @wordpress/element for a long time (or maybe forever) after such a migration. Also, there will be tons of developer documentation and articles that will need to be updated. With that in mind, there may be a substantial outreach effort necessary if we decide to go that way.
As a wordpress plugin developer newbie I'll just ship my own React and access it directly, I just don't have time to wait for this to happen
