Suggestion: split up "state management" into more specific sub-types.

[phryneas]

By the broad definition of "state management", currently many tools in the "data fetching" as well as all "forms" and router libraries would fall into that category - all of them manage some kind of state, be it "server-side state", "form state" or "routing state".

That leads to the weird situation where React Query is listed under "state management" even though it is a single-purpose tool to manage server-side state, while all other tools currently in that category are meant for the swiss army knife use case of "client-side global state management" (Apollo client does not have that as it's main purpose, but ships with primitives meant explicitly for that purpose) - the authors or React Query rightfully claim to be a "state management" tool, albeit a single-purpose one.

Would it maybe make sense to get rid of the "state management" tag and add more specific tags like "client-side state" (or "global state"), "server state" (or "async state"), "form state" (or just, like right now, "forms") and "routing state" (or just "routing")?

That would also add a nice distinction between "server state" tools like React Query and SWR and "data fetching" tools like axios and ky which do not the same job, but complement each other.

[tannerlinsley]

This is a great idea and will only help visitors understand the nature of these libraries even more.

[dustinsgoodman]

Great suggestion @phryneas! The broad "state management" section was to help create a pivot on the data without generating a large number of navigation options. A concern is bloating the navigation and making it too specific making it more difficult for users to explore the data. Would better-tagging help resolve this so the search suggestions are stronger and point to these better-defined sub-categories?

[jesus4497]

Hey @tannerlinsley @phryneas! we appreciate this suggestion and we think that we definitely should implement a solution for it - Before that we want to hear your feedback about the approach we have in mind. Our idea is that better-tagging will help define the libraries in a stronger way making them easy to differentiate from each other and to search them without losing the easiness of exploring new data by just clicking at the sidebar "State Management" section. So we thought on:

• Adding more specific tags for each resource cataloged as "state management" while still leaving the tag "state management" so people could still do a general search as they can do right now, without generating a large number of navigation options.

If you guys have in mind a better approach or a way to improve the previously described proposal, we would be more than glad to hear it!