Fetching a total category tree (a list of all categories and their sub-categories) v.s fetching each branch as it is needed?

I'm not sure if my terminology is completely correct, but my question revolves around the goal of displaying lists of categories,sub-categories, and sub-sub categories.

The complete number of categories, sub-categories, and sub-sub categories is around 100 (each having a unique name). The highest number of nodes in any branch of this complete tree of categories is around 10. I only need to display the names of each node in any one of these branches as well as an image.

In the type of UI I am developing, these different lists will never appear simultaneously.

For instance, when you click on a category from a list of categories, the list of categories goes away and you should then see a list of that category's sub-categories. When you click on a sub-category, the list of sub-categories goes away and you then see a list of sub-sub-categories belonging to the recently clicked sub-category and so on.

Knowing this, my question is:

Are there any downsides to making one initial fetch of a 'category-tree' that basically could be an array of JSON objects, each containing the names and sub-category's of each category and so on? (And just hold on to this category-tree data to render any list I need)

OR

Should I make an initial fetch for just the initial categories, and then make another fetch for a list of sub-categories once they click a category and so on? (Fetching only what I need, when I need it)

array of JSON objects, each containing the names and sub-category's of each category and so on

first: Names are shallow, may change (over time), may not be unique, ...

Use some (to be forever unique) IDs. A list of nodes, each one containaing it's name (wich may change or repeat or whatever) an unique ID, and it's parentID, and whatever additional data you need. With this data you can easily build your tree.

"forever to be unique", because I've also seen people changing/cleaning up IDs after updates in the structure to "remove gaps", "IDs resemble the new order" of nodes, and further BS. All this risking to mess up the structure and also actually messing up, and having to manually fix it.

The complete number of categories, sub-categories, and sub-sub categories is around 100 (each having a unique name). The highest number of nodes in any branch of this complete tree of categories is around 10. I only need to display the names of each node in any one of these branches as well as an image.

This calculation doesn't add up for me, based on my experiences.

At a first glance, a total of 100 nodes doesn't sound like too much data to fetch in a single bulk, but this still depends on how much additional data your nodes contain.

The part that doesn't add up/sounds weird to me:

• 100 total nodes / 10 nodes per category
  -> where are the sub-sub-nodes you mentioned?

• Or, if you really have that deep nesting as it sounded to me, and you have only 100 nodes total
  -> an average of probably 3-5 nodes per category (gut based numbers)
  from a usability/users standpoint this sounds like too much nesting for too few nodes. And therefore too much clicking (and waiting) till I reach my destination. You should consider reorganizing/flattening your structure.

So basically:
either there should be more than 100 nodes total at (up to) 10 nodes per category ^{>2 levels}
or you rarely use the mentioned 10 nodes and there is too much nesting.

• And last, the assumption that it will always stay 100 nodes in total. From my own experience, these kind of things tend to "expand" beyond the inintially defined "absolute" ;) limits.
  I had a project where I had to build an UI to manage rights to a tree of such categories for a bunch of groups. Initially this had been designed for like 10 groups and like 30 (nested) categories total. So (read+change right) 600 values as an (will almost never be met) "absolute" limit for the UI.
  The whole concept, implementation and usability, totally failed when we reached 100 nested categories and 30+ groups and by average had to render almost 1000 checkboxes in that view.
  
  Long story short, keep in mind that even absolute limits may not be that absolute, and may be exceeded by orders of magnitude in the future, wich may blow up whatever concept you choose at this point.

Maybe all this seems off topic, but it may influence the way you decide to approach your problem, as you know best the topic of your project, the potential for expansion, how decisions are made with your customer, ...

---

And just to repeat my initial comment:

• you could inject a first bulk of data into the markup, so you don't need to load it by an additional call. (as JSON, not as pre-rendered HTML)

• you can preload sub-categories in the background, so they are available as soon as the user clicks on the link/button

• you can bulk-load multiple categories or level to reduce the amount of requests made

• and you can combine all this, and your initial approaches to whatever fits your needs

And as already mentioned by Bergi, all this heavily depends on your special use-case and can't be answered generally. That's why I wrote so much of my thoughts, to help you make reflected decisions.