User::load calls should be avoided in classes, use dependency injection instead in jsonapi module

This would be a great novice patch :)

Why is this marked 9.0.x?

Thanks @swatichouhan012 for creating the issue.
Here is the patch for the same. Please review.

1. +++ b/core/modules/jsonapi/src/Controller/EntryPoint.php
   @@ -51,9 +59,10 @@ class EntryPoint extends ControllerBase {
       * @param \Drupal\Core\Session\AccountInterface $user
       *   The current user.
       */
   -  public function __construct(ResourceTypeRepositoryInterface $resource_type_repository, AccountInterface $user) {
   +  public function __construct(ResourceTypeRepositoryInterface $resource_type_repository, AccountInterface $user, EntityTypeManagerInterface $entityTypeManager) {
   

   This is updating the constructor, but not its documentation. Could you update that too? :)

2. +++ b/core/modules/jsonapi/src/Controller/EntryPoint.php
   @@ -51,9 +59,10 @@ class EntryPoint extends ControllerBase {
   +    $this->entityTypeManager = $entityTypeManager;
   

   In Drupal core, we don't camelcase function arguments. So it should not be $entityTypeManager, but $entity_type_manager.

#7 I think it can go in 8.9.x too — I think it can be committed to both 8.9.x and 9.0.x 😊

1. +++ b/core/modules/jsonapi/src/Controller/EntryPoint.php
   @@ -43,6 +43,13 @@ class EntryPoint extends ControllerBase {
   +  protected $entity_type_manager;
   

   The naming here is incorrect. This should be $entityTypeManager. (I know, it's weird and confusing, but all of Drupal does it this way for historical reasons!)

2. +++ b/core/modules/jsonapi/src/Controller/EntryPoint.php
   @@ -50,10 +57,13 @@ class EntryPoint extends ControllerBase {
   +   * @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager
   

   The naming here is correct. That's indeed what I asked in #8.2 :)

3. +++ b/core/modules/jsonapi/src/Controller/EntryPoint.php
   @@ -50,10 +57,13 @@ class EntryPoint extends ControllerBase {
   +    $this->entityTypeManager = $entity_type_manager;
   

   This is correct too :)

Just one more reroll! 🤞

Perfect! :)

Thank you, and thanks for your patience, @swatichouhan012!

+++ b/core/modules/jsonapi/src/Controller/EntryPoint.php
@@ -50,10 +57,13 @@ class EntryPoint extends ControllerBase {
-  public function __construct(ResourceTypeRepositoryInterface $resource_type_repository, AccountInterface $user) {
+  public function __construct(ResourceTypeRepositoryInterface $resource_type_repository, AccountInterface $user, EntityTypeManagerInterface $entity_type_manager) {
     $this->resourceTypeRepository = $resource_type_repository;
     $this->user = $user;
+    $this->entityTypeManager = $entity_type_manager;
   }

@@ -104,7 +115,7 @@ public function index() {
+      $current_user_uuid = $this->entityTypeManager->getStorage('user')->load($this->user->id())->uuid();

We need to account for backwards compatibility - ie. we need to allow passing in a NULL for $entity_type_manager... but this is extending ControllerBase - so we could avoid this and do $this->entityTypeManager()->getStorage('user')->load() instead.

Also I think we need to think about scope here. Given that you're using a code scanner and coder rule to find this I don;t think a scope of 1 issue per warning is the way to go.

Hey @alexpott, Thanks for pointing out the ControllerBase class. I have chnage the code keeping in mind this class.
Please review.

Forgot to remove a comment from the code.
Uploading new patch. Please review this.
Thanks.

#14:
Oh, hah, didn't realize it already lived on ControllerBase 😅🙈 Agreed with using that instead. (Now irrelevant, but I disagree with the need for BC for EntryPoint's constructor: it's a controller owned by the JSON:API module and marked as @internal.)

Marking RTBC for the code changes.

Also I think we need to think about scope here. Given that you're using a code scanner and coder rule to find this I don;t think a scope of 1 issue per warning is the way to go.

Agreed — but in this case they didn't file dozens of issues for dozens of core modules. So … I think this is okay. But you're used to dealing with this much more often, so I obviously defer to you. Feel free to un-RTBC over this and ask to expand the scope to all of core of course.

OK, that turned out to be very simple. :)

It's a very small cleanup, and usually I would prefer to see this done as a part of the coding standards cleanup initiative, where we replace the various load() calls across all of core according to the type of issue. In order to fix core coding standards in a maintainable way, all our coding standards issues should be done on a per-rule basis across all of core, rather than fixing standards in individual modules or files. We should also separate fixes where we need to write new documentation from fixes where we need to correct existing standards. This all should be done as part of #2571965: [meta] Fix PHP coding standards in core. A good place to start is the child issues of #2572645: [Meta] Fix 'Drupal.Commenting.FunctionComment' coding standard.

For background information on why we usually will not commit coding standards fixes that aren't scoped in that way, see the core issue scope guidelines, especially the note about coding standards cleanups. That document also includes numerous suggestions for scoping issues including documentation coding standards cleanups.

Contributing to the overall plan above will help ensure that your fixes for core's coding standards remain in core the long term.

So, usually I would mark this as a duplicate of a large issue, but this one time I'll go ahead and commit it, since it's done. And since the change should be purely transparent, it's safe to backport during beta, so backporting as far as 8.9.x.

Thanks! I encourage you to submit complete fixes in the future, rather than one-line fixes.