-
Notifications
You must be signed in to change notification settings - Fork 196
Taxonomy table QA fixes #3000
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
brian-smith-tcril
merged 12 commits into
openedx:master
from
jesperhodge:taxonomy-qa-fixes-3
Apr 17, 2026
Merged
Taxonomy table QA fixes #3000
Changes from all commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
588b7be
fix: taxonomy alignment and error message
jesperhodge 4217c26
fix: lint and cleanup
jesperhodge 400240c
fix: UsageCountDisplay
jesperhodge 3c5d4e6
fix: tests
jesperhodge a44a221
fix: test
jesperhodge 600a01c
fix: lint
jesperhodge a30768e
fix: test accuracy
jesperhodge 0bb89a1
fix: typecheck for AxiosError
jesperhodge 98b5cf9
fix: PR comments
jesperhodge 4d6fa4a
fix: Apply suggestions from code review
jesperhodge 58ba86f
fix: lint
jesperhodge 6803971
fix: types
jesperhodge File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| import { | ||
| Bubble, | ||
| } from '@openedx/paragon'; | ||
| import type { Row } from '@tanstack/react-table'; | ||
| import type { | ||
| TreeRowData, | ||
| } from '@src/taxonomy/tree-table/types'; | ||
| import { getTagListRowData } from './utils'; | ||
|
|
||
| const UsageCountDisplay = ({ row }: { row: Row<TreeRowData>; }) => { | ||
|
brian-smith-tcril marked this conversation as resolved.
|
||
| const count = getTagListRowData(row).usageCount ?? 0; | ||
|
|
||
| if (count <= 0) { | ||
| return null; | ||
| } | ||
|
|
||
| return ( | ||
| <Bubble expandable> | ||
| {count} | ||
| </Bubble> | ||
| ); | ||
| }; | ||
|
|
||
| export default UsageCountDisplay; | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| import type { TreeRowData } from '@src/taxonomy/tree-table/types'; | ||
|
|
||
| export interface TagListRowData extends TreeRowData { | ||
| depth: number; | ||
| childCount: number; | ||
| usageCount?: number; | ||
| isNew?: boolean; | ||
| isEditing?: boolean; | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| import { Row } from '@openedx/paragon'; | ||
| import { TreeRowData } from '@src/taxonomy/tree-table/types'; | ||
| import { TagListRowData } from './types'; | ||
|
|
||
| /** getTagListRowData | ||
| * | ||
| * Minimal getter function for `row.original`. Mainly because the naming of `original` is not expressive, | ||
| * and it needs to be cast to the correct type. | ||
| */ | ||
| export const getTagListRowData = (row: Row<TreeRowData>): TagListRowData => ( | ||
| row.original as unknown as TagListRowData | ||
| ); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is moving away from the catch/rethrow pattern desired for more than just these functions? Not something I would want to block this PR on, but if we're moving away from that it'd be good to make a follow-up issue to rework the rest of the places the catch/rethrow pattern is used in this file and no longer need to import
getApiErrorMessage.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pattern may be fine in other places where we don't want to display a part of a backend response body to the user. Also backend responses are inconsistent right now (there's a backend ADR working on that), so they may be handled differently in different places.
In this case the display string we want to show is in an array in
err.response.data[field_key]. We have to extract this in our try catch block higher up anyway, depending on whether this is an AxiosError.Throwing an
Erroris firstly not great (it should be specific) and secondly it does not have the fields with the information, so this is removing necessary information.Rethrowing the AxiosError as a generic error here creates a loss of information, where just surfacing the AxiosError is completely fine. And a line like
catch (err) { throw err }serves no purpose.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the use case for it, it's more of a question of where the error message formatting should live. This PR is moving the formatting for the errors from happening inside this
data/apiHooks.tsfile intotag-list/hooks.ts. I like that change, and think it likely makes sense to do something similar for some of the other hooks in this file likeuseImportPlan.As I mentioned before, this isn't a blocking thing, just something that seems like it'd be worth looking into as a follow-up issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! I think so too.
If the error responses are becoming standardized on the backend, do you think it makes sense to wait for that so that we can handle them in the same way throughout the authoring frontend? Or do you think it's a smaller issue that should be done before then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion on the timing. If it'll be easier to move away from the catch/rethrow pattern after the backend errors are standardized then waiting likely makes sense. I just want to make sure moving away from the pattern is tracked somewhere if it's something we plan on doing.