[UEPR-8] feat: add categories to tutorial page

[KManolov3]

Resolves

https://scratchfoundation.atlassian.net/browse/UEPR-8

Proposed Changes

Adds a category prop to the deck components and uses it to group them in categories in the case when "?tutorial=all" filter is selected.

Reason for Changes

Test Coverage

[KManolov3]

@cwillisf Had to make a few changes to the order of the decks to achieve the order defined in the task and decided to still use the current ordering mechanism - which is the order they are defined in the decks/index.jsx file. This has lead to a few order changes when one of the other tags is selected, wherever the order had to be changed for a category (for example, in Animation, Record a Sound was previously after Use Arrow Keys, now it's before) (see images below). To be clear, this only affects the deck order within a category - we first explicitly group by and sort the decks by category. I think it makes sense to have it like that, since this way the relative order of items within a category remains consistent between tags.
Let me know if we need to implement a separate ordering for the all category.

Old:

New:

[cwillisf]

Looks reasonable to me. The groupBy / sort / map part is a little more complex than I expected, but I think that's an indication that decks/index.jsx is more complex than it should be, and we can consider fixing that separately :)

[cwillisf]

Could you say more about this? Just want to make sure I understand the comment.

[KManolov3]

I think if anything it shows I don't understand very well at what point defineMessages is called. What I tried to do was have a: (at that point CATEGORIES' values were the message we wanted to visualise)
const categoryMessagesInfo = Object.entries(CATEGORIES).reduce(([key, message], acc) => { acc[...] = { id:gui.library.${key}, defaultMessage: message, description: Label for ${message} category}, {}); const messages = { ...*currentMessages*, ...categoryMessagesInfo }
so that the category message construction is a bit more programmatic and we don't have to define, for example, the category id in two places, but that led to categoryMessagesInfo evaluating to an empty value inside messages. After some experimenting I "felt my way" to the conclusion that any time defineMessages is called with anything other than a statically constructed object, the messages aren't evaluated properly.

I searched for an explanation in the docs now and yeah - https://formatjs.io/docs/getting-started/message-declaration/#pre-declaring-using-definemessage-for-later-consumption-less-recommended - it says pretty clear that the strings need to be static. Though I'm not sure whether

But I suppose my comment is wrong - it seems likely that in our case the message definition happens on compile time, not on runtime - will update it - https://formatjs.io/docs/guides/advanced-usage/#pre-compiling-messages.

I apologize if the above is common knowledge to you :D

Are you okay with leaving the messages explicitly defined as they are right now?