Correct topic count when node kind is not found in clipboardNodesMap

[LianaHarris360]

Summary

Description of the change(s) you made

This pull request modifies the computed property topicAndResourceCount() to address instances where items in the clipboardNodesMap may be missing the node kind. It introduces the use of contentNodesMap to retrieve the kind when it is not present in the clipboardNodesMap.

---

Reviewer guidance

How can a reviewer test these changes?

1. Select folder/resource in the clipboard
2. Click on the Move button
3. Observe the title with the correct count when the moveModal opens

References

Fixes #3744

Comments

---

Contributor's Checklist

PR process:

• If this is an important user-facing change, PR or related issue the CHANGELOG label been added to this PR. Note: items with this label will be added to the CHANGELOG at a later time
• If this includes an internal dependency change, a link to the diff is provided
• The docs label has been added if this introduces a change that needs to be updated in the user docs?
• If any Python requirements have changed, the updated requirements.txt files also included in this PR
• Opportunities for using Google Analytics here are noted
• Migrations are safe for a large db

Studio-specifc:

• All user-facing strings are translated properly
• The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
• All UI components are LTR and RTL compliant
• Views are organized into pages, components, and layouts directories as described in the docs
• Users' storage used is recalculated properly on any changes to main tree files
• If there new ways this uses user data that needs to be factored into our Privacy Policy, it has been noted.

Testing:

• Code is clean and well-commented
• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Any new interactions have been added to the QA Sheet
• Critical and brittle code paths are covered by unit tests

---

Reviewer's Checklist

This section is for reviewers to fill out.

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[nucleogenesis]

I tested this locally and it worked perfectly and moved things where I wanted them. I'm happy that this solution ended up being a bit less complicated than I thought when we were looking at it together 😄

I left one non-blocking code comment where I may be making incorrect assumptions to begin with so if that's the case feel free to ignore.

[nucleogenesis]

Non-blocking question: did you find that the ?. was necessary here because kind and/or source_node_id was missing on some contents or was it to just avoid unhandled errors just in case?

I ask because if we should expect kind on every contentNode (which I think we should?) then using the ?. might result in hard-to-debug issues when it isn't because it'll just count broken nodes as "resources" in any case here.

It's not crucial here, but in the if/else below it might be worth making the second condition like this (shortened for GH formatting).

if(kind === 'topic) { topicCount++  }
else if (kind) { resourceCount++ }  // it's not undefined or null, so we know it's a non-topic resource
else { console.error("`kind` missing from content...")  }

But, again, this only really matters if we should be able to expect kind to always be defined in this context -- which may not be the case?

[LianaHarris360]

Yes, we should be able to expect kind on every contentNode, the ? is in place to avoid any potential errors, but you are right about potential difficulties with debugging so I will make this change.

[rtibbles]

Requested change was made - code updates look good to me.