Tag Cloud: Add ability to change number of tags shown.

[getsource]

Description

Adds a feature to the Tag Cloud block to allow the user to choose the amount of tags shown in the cloud.

The default number of tags is currently set to 45, because this matches the default currently used in wp_tag_cloud().

Right now there is a minimum of 3, and max of 100 set.
The minimum of 3 was chosen to allow for the block to function as a tag cloud (as with one tag, it'd be unclear it's a tag cloud).

The max matches the one used in latest-comments and the latest-posts/query-controls default. It also avoids potential performance issues with high numbers of tags being requested, or limitless queries.

All of this open for change/discussion, of course!

Fixes: #32173
Fixes: #21951

How has this been tested?

• Add Tag Cloud block
• Confirmed number of tags shown by default
• Change to min and max, and confirmed these show correctly
• Confirmed number of tags also changes in post preview

Screenshots

Screen.Recording.2021-05-25.at.22.54.17.mov

Types of changes

New feature

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[getsource]

Looks like I have a test to update. I'll work on that.

[getsource]

Rebased and updated tests.

[getsource]

Apologies, not completely sure if I updated the tests properly.
Should I update the html files as well, to contain tagsToShow?

Or create a copy of the existing ones, to make sure that it works properly with no tagsToShow specified, and add new tests/files with tagsToShow set?

[getsource]

Okay. I decided to leave the existing test to test the default value, and add a new one, to test attributes created when a number of tags is selected.

Tests updated.

[ntsekouras]

Thanks for your work here @getsource, this looks good!

I don't think we need to create yet another fixture for this block for the new attribute and the base one would be fine to be updated. You have to update core__tag-cloud.html file with <!-- wp:tag-cloud {"taxonomy":"category","numberOfTags":6} /--> for example.

So in order to update the fixtures for the tests you have to edit only the html file (not the .serialized one) and then run npm run fixtures:regenerate.

After these minor changes this will be good to go.

[getsource]

Thanks much @ntsekouras!
I'll remove the additional fixture and regenerate to make sure everything is up to date.

[Mamaduka]

I think we can change the minimum to 1 and let the user decide if they want to display one most used tag. It will also match the minimum number used in other blocks.

[getsource]

@Mamaduka Sounds fine to me!

On one hand, it's not really a cloud with 1.
On the other hand, who am I to keep someone from displaying their favorite tag?
(And if it reduces support, that's good too)

I'll update this in the next pass.

[getsource]

Okay, I updated according to the most recent changes we talked about. Hopefully I caught them all!

I'll note that this PR currently lists #21951 as one of the items it will fix.

It does allow raising the number, but not as high as some users would like:
#21951 (comment)

I'm still thinking that there should be a limit, with the reasons for the current max described in this PR's description, but figured I should mention in case we want to leave that issue open when this is merged / for a second opinion.

[ntsekouras]

I'll note that this PR currently lists #21951 as one of the items it will fix.
It does allow raising the number, but not as high as some users would like:
#21951 (comment)

100 is a sensible max value for now and the issue can be closed. The user in that comment could create a new more specific comment about a max like a 500 or 1000, that would involve UX decisions because such a max number is more of an edge case (at least IMO) and could deteriorate the experience of the RangeControl handling.

Also agree with your decisions about the max value in your PR's description.

[ntsekouras]

Code looks good and tests seem not related. I'll restart again later to have a green CI to land.
Thanks for your work and wanted to mention that your explanations for your decisions were great!

Awesome work !💯

[ntsekouras]

@getsource can you rebase to get a green CI. The issues has been handled in trunk now.

[getsource]

Sure, thank you! Rebased, and looks to be passing now.

[getsource]

Thanks much for your help and kind words!

[getdave]

I've received some feedback that the hard limit of 100 should be possible to filter. I wonder if we could transform the UI into a number field if the limit is filtered above 100?