You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a taxonomy/tag author
The user wants the taxonomy tag list to support pagination
So that large taxonomies can be viewed and managed efficiently
Pagination is displays 50 items on first load
Given the taxonomy contains more than 50 tags
When the user views the taxonomy tags table
Then pagination controls are displayed
And 20 items are displayed
And the remaining tags are displayed on additional pages
Pagination is displayed when the tag list exceeds the page limit
Given the taxonomy contains more tags than can be displayed on a single page
When the user views the taxonomy tags table
Then pagination controls are displayed
And the tag list is divided across multiple pages
Pagination controls allow navigation between pages
Given the taxonomy tags table contains multiple pages of results
When the user selects a pagination control
Then the table updates to display the tags for the selected page
Parent tag and all nested subtags appear on the same page
Given a parent tag contains one or more nested subtags
When pagination is applied to the taxonomy tags table
Then the parent tag and all of its nested subtags appear on the same page
Pagination maintains the hierarchical structure of tags
Given tags are displayed in a hierarchical structure
When pagination is applied
Then the structure of the parent and child tags is preserved
And nested tags remain visually associated with their parent tag
Pagination updates after tag changes
Given the taxonomy contains multiple pages of tags
When tags are added, renamed, or deleted
Then pagination updates to reflect the current number of tags
I wanted to explain how the backend API implements pagination now.
Normally, the page size would be 100 or 1,000, but let's say for example purposes it's merely 4. Then when you first loaded the taxonomy, you'd see something like this:
Obviously clicking "load more" will load additional "top-level" tag pages (4 more top-level tags), and clicking on the circled chevron icon will load the first page of the child tags of "Administration":
(seems like I only showed it loading 3 child tags, whoops - pretend it was 4).
At this point, you can click on the upper "Load more" to load the second page of child tags under "Administration", or the lower "Load more" to load the second page of top-level tags, or click on any ⌄ down chevron icon to load the first page of child tags under any other tag.
But, we'd like to make things fast for the user. So, as an optimization, we have the full_depth_threshold parameter. If the total number of tags+children in the current request is below that threshold, it will pre-load the descendant tags and return them. That way, you can click on the ⌄ down chevron icons and get an instant response. But, if you're dealing with a huge taxonomy, we just return one level at a time and you have a very minor loading delay as you expand each level of the tree. even with a huge taxonomy, if the full_depth_threshold is say, 100, you're probably going to get all the descendant tags loaded at once as soon as you click on any one top-level tag. So it should still generally be quite fast.
So the key points are:
There is no "page number" overall. Each tag's children can be paginated, as can the top-level tags.
Generally we try to pre-load all the tags, but the UI should be able to handle it either way, getting only one level at a time from the backend and then showing "Load more" where needed, or getting all the descendant tags beneath any one tag, or getting all the tags in the whole taxonomy at once, depending on the size of the taxonomy.
I think the criteria you've described above, with an overall "page number" is going to be a lot more complicated to implement.
We also have to think about search. There should be a search bar where you can enter keywords and it will filter the results. I would argue that's almost more important than pagination. I don't see an issue for it though?
Hi @bradenmacdonald , thanks for the insightful feedback. Let me try to address these concerns!
In our implementation of the new table I've moved away from this flow of click chevron down -> new API request loads child tags and deeper nested tags. Mainly because:
on "Expand all", this would result in a large number of API requests, which is bad for performance. (Similar to N+1 queries -> if you have 50 parent tags with children, this results in 50 backend calls and 50 database queries, instead of just 1.)
This unnecessarily worsens user experience: if we have the option to display data instantly instead of waiting data to load every time a user expands a row, that's a lot better UX.
Loading tags recursively worsens performance (see point 1), so there's no performance reason to not load everything together.
Taxonomy tags are very small data points, so even loading a huge taxonomy all at once will not be a significant performance load (unless loaded recursively.)
It's nice to keep the API option of loading a specific tag's subtags, but I don't see any reason to load things recursively from the frontend.
There is no "page number" overall. Each tag's children can be paginated, as can the top-level tags.
Pagination is very standard in OpenEdx, and since we need a way to load all tags - not just "only the parent tags" or "only child tags", this should have pagination capability as well, and that's usually done on the backend.
Pagination is already in place, but if you specify "full_depth_threshold" it will randomly put a fixed number of tags on the first page and some of its children on the first page, and some on the second. I assume it does that even if you specify a specific tag as parent. That's unexpected behavior, so I'd classify it as a bug.
If no pagination is specified, expected behavior is to return all tags (either including descendants or not.)
I think introducing a "include_descendants" parameter will solve this. If that's false, you just get let's say the first 50 parent tags on page 0. If it's true, it includes all descendants of these 50 parents also on page 0. That's also pretty standard way to do things.
I'm not sure what you mean with "page number".
Generally we try to pre-load all the tags, but the UI should be able to handle it either way, getting only one level at a time from the backend and then showing "Load more" where needed, or getting all the descendant tags beneath any one tag, or getting all the tags in the whole taxonomy at once, depending on the size of the taxonomy.
That does not take into account pagination, even though pagination is already in place in the backend.
The first point with "Load more" is not needed anymore in the frontend, as explained above.
The second point (getting all tags at once) should be possible either paginated or unpaginated. If paginated, child tags of a tag shouldn't be split across multiple pages.
In terms of how complicated this is to implement - it seems relatively simple to me. The backend supports pagination, just needs this fix about children being on the same page. The frontend via tanstack react-table also supports pagination. I have also had pagination working already and just had to disable it because of this backend issue.
I agree, I don't see any problem with search. The AC for search is to just disable pagination when you search and load everything that matches on one page.
Before we implement this or even confirm the ACs, I'd like to see a mockup of how it's supposed to look. Particularly in the case where there are >50 top-level tags and some of them have >100 direct sub-tags.
Per discussion with Jenna, we are not proceeding with this work at this time. We will re-evaluate if this becomes a problem.
If this ticket is deemed necessary, want to ensure alignment on problem(s) trying to solve & ensure community PR reviewers as well as Axim are aligned.
Per Jesper, if we do not do pagination, there is a small performance optimization required. We need to ensure that the front end does not render the entire table all at once. Begins with what is visible (virtualization). Example, 10K tags, performance will be slow if rendering all at once. (10-20 second load order of magnitude. Concern when several thousand tags + are involved).
Jesper can test & provide additional details on performance and we can decide where to go from there (e.g. new ticket for Willow)
Notes on performance (Lightcast example 3.5K)
Minor performance concern (.5 second lag to do fairly rare operation)
Continue to track as we add more features.
Activity
thelmick-unicon commentedon Mar 10, 2026
Acceptance Critera
Feature: Pagination for taxonomy tags table
As a taxonomy/tag author
The user wants the taxonomy tag list to support pagination
So that large taxonomies can be viewed and managed efficiently
Pagination is displays 50 items on first load
Given the taxonomy contains more than 50 tags
When the user views the taxonomy tags table
Then pagination controls are displayed
And 20 items are displayed
And the remaining tags are displayed on additional pages
Pagination is displayed when the tag list exceeds the page limit
Given the taxonomy contains more tags than can be displayed on a single page
When the user views the taxonomy tags table
Then pagination controls are displayed
And the tag list is divided across multiple pages
Pagination controls allow navigation between pages
Given the taxonomy tags table contains multiple pages of results
When the user selects a pagination control
Then the table updates to display the tags for the selected page
Parent tag and all nested subtags appear on the same page
Given a parent tag contains one or more nested subtags
When pagination is applied to the taxonomy tags table
Then the parent tag and all of its nested subtags appear on the same page
Pagination maintains the hierarchical structure of tags
Given tags are displayed in a hierarchical structure
When pagination is applied
Then the structure of the parent and child tags is preserved
And nested tags remain visually associated with their parent tag
Pagination updates after tag changes
Given the taxonomy contains multiple pages of tags
When tags are added, renamed, or deleted
Then pagination updates to reflect the current number of tags
bradenmacdonald commentedon Mar 25, 2026
@jesperhodge CC @thelmick-unicon
I wanted to explain how the backend API implements pagination now.
Normally, the page size would be 100 or 1,000, but let's say for example purposes it's merely 4. Then when you first loaded the taxonomy, you'd see something like this:
Obviously clicking "load more" will load additional "top-level" tag pages (4 more top-level tags), and clicking on the circled chevron icon will load the first page of the child tags of "Administration":
(seems like I only showed it loading 3 child tags, whoops - pretend it was 4).
At this point, you can click on the upper "Load more" to load the second page of child tags under "Administration", or the lower "Load more" to load the second page of top-level tags, or click on any ⌄ down chevron icon to load the first page of child tags under any other tag.
But, we'd like to make things fast for the user. So, as an optimization, we have the
full_depth_thresholdparameter. If the total number of tags+children in the current request is below that threshold, it will pre-load the descendant tags and return them. That way, you can click on the ⌄ down chevron icons and get an instant response. But, if you're dealing with a huge taxonomy, we just return one level at a time and you have a very minor loading delay as you expand each level of the tree. even with a huge taxonomy, if thefull_depth_thresholdis say, 100, you're probably going to get all the descendant tags loaded at once as soon as you click on any one top-level tag. So it should still generally be quite fast.So the key points are:
I think the criteria you've described above, with an overall "page number" is going to be a lot more complicated to implement.
We also have to think about search. There should be a search bar where you can enter keywords and it will filter the results. I would argue that's almost more important than pagination. I don't see an issue for it though?
jesperhodge commentedon Mar 26, 2026
Update to AC:
jesperhodge commentedon Mar 26, 2026
Hi @bradenmacdonald , thanks for the insightful feedback. Let me try to address these concerns!
In our implementation of the new table I've moved away from this flow of click chevron down -> new API request loads child tags and deeper nested tags. Mainly because:
It's nice to keep the API option of loading a specific tag's subtags, but I don't see any reason to load things recursively from the frontend.
In terms of how complicated this is to implement - it seems relatively simple to me. The backend supports pagination, just needs this fix about children being on the same page. The frontend via tanstack react-table also supports pagination. I have also had pagination working already and just had to disable it because of this backend issue.
Does this answer your questions?
jesperhodge commentedon Mar 26, 2026
I agree, I don't see any problem with search. The AC for search is to just disable pagination when you search and load everything that matches on one page.
bradenmacdonald commentedon Mar 26, 2026
Before we implement this or even confirm the ACs, I'd like to see a mockup of how it's supposed to look. Particularly in the case where there are >50 top-level tags and some of them have >100 direct sub-tags.
Jennifer-Oxborough commentedon Apr 8, 2026
Per discussion with Jenna, we are not proceeding with this work at this time. We will re-evaluate if this becomes a problem.
If this ticket is deemed necessary, want to ensure alignment on problem(s) trying to solve & ensure community PR reviewers as well as Axim are aligned.
Per Jesper, if we do not do pagination, there is a small performance optimization required. We need to ensure that the front end does not render the entire table all at once. Begins with what is visible (virtualization). Example, 10K tags, performance will be slow if rendering all at once. (10-20 second load order of magnitude. Concern when several thousand tags + are involved).
Jesper can test & provide additional details on performance and we can decide where to go from there (e.g. new ticket for Willow)
Jennifer-Oxborough commentedon Apr 8, 2026
Notes on performance (Lightcast example 3.5K)
Minor performance concern (.5 second lag to do fairly rare operation)
Continue to track as we add more features.