-
Notifications
You must be signed in to change notification settings - Fork 43
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
✨ Add Tasks tab to the Applications table application details drawer #2123
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: EstyBiton <[email protected]>
Signed-off-by: esty <[email protected]> Signed-off-by: EstyBiton <[email protected]>
Signed-off-by: EstyBiton <[email protected]>
Signed-off-by: EstyBiton <[email protected]>
ed6042b
to
fc085f3
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2123 +/- ##
==========================================
+ Coverage 39.20% 41.95% +2.75%
==========================================
Files 146 175 +29
Lines 4857 5635 +778
Branches 1164 1397 +233
==========================================
+ Hits 1904 2364 +460
- Misses 2939 3150 +211
- Partials 14 121 +107
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
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.
The work done is quite good. There are some things that need to be changed.
-
On the side bar table, either drop the priority column or make the initial width of the drawer larger. With the current width of the drawer, the action kebab are not visible. The other option is to make the drawer something like 100px wider initially so the task action kebab is shown.
-
When linking to the task details, the URL is breaking. You can follow the same format as
navigateToAnalysisDetails()
, but it should really be its own path. -
The status column should use the same column style as the tasks-page (status icon, name, and link). See:
tackle2-ui/client/src/app/pages/tasks/tasks-page.tsx
Lines 244 to 257 in 0cfe60b
state: ( <IconWithLabel icon={<TaskStateIcon state={state} />} label={ <Link to={formatPath(Paths.taskDetails, { taskId: id, })} > {t(taskStateToLabel[state ?? "No task"])} </Link> } /> ), -
Need to fix the link that are being generated on task manager table (see specific comment).
I have a few more specific comment in the review.
client/src/app/Paths.ts
Outdated
@@ -41,7 +41,7 @@ export const DevPaths = { | |||
|
|||
dependencies: "/dependencies", | |||
tasks: "/tasks", | |||
taskDetails: "/tasks/:taskId", | |||
taskDetails: "/tasks/:taskId/:isFApplication", |
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.
const tableControls = useTableControlProps({ | ||
...tableControlState, | ||
idProperty: "id", | ||
currentPageItems: currentPageItems, | ||
totalItemCount, | ||
isLoading: isFetching, | ||
selectionState: useSelectionState({ | ||
items: currentPageItems, | ||
isEqual: (a, b) => a.name === b.name, | ||
}), | ||
}); |
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 think a compact table looks better here. Add prop variant: "compact",
and see if you agree.
modifier="nowrap" | ||
{...getTdProps({ columnKey: "status" })} | ||
> | ||
{task.state} |
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.
Make this render like on the task manager page -- status icon with a link to view the task details
item={task} | ||
rowIndex={rowIndex} | ||
> | ||
<Td width={10} {...getTdProps({ columnKey: "taskId" })}> |
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.
The Td
widths are not necessary. All of the patterfly examples put any width values on the Th
tags only. Since I don't see any difference with them here or not, easiest is to remove them.
const [applicationName, setApplicationName] = useState<string | undefined>(); | ||
const [applicationId, setApplicationId] = useState<number | undefined>(); | ||
|
||
useEffect(() => { |
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.
@rszwajko Can you have a look at these changes? I don't remember exactly how these components hang together.
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 missed this comment. I will take a look.
Signed-off-by: EstyBiton <[email protected]>
@sjd78 Thank you for your review! I’ve made the following updates based on your feedback: |
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.
The PR looks pretty impressive! It basically adds the entire feature. We could merge it now however too keep the code DRY we need a follow-up refactorings.
It would be better to merge the main refactoring (extracting base table component) as a prerequisite (different PR), merge it and then use it here. Please let me know if you can work on this (details in the comments). If not we can consider other variants.
@@ -108,4 +109,5 @@ export interface AnalysisDetailsAttachmentRoute { | |||
export interface TaskDetailsAttachmentRoute { | |||
taskId: string; | |||
attachmentId: string; | |||
applicationId: string; |
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.
After this change the interface is the same as AnalysisDetailsAttachmentRoute
(just above).
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.
Note that after the changes the file duplicates the functionality of AnalysisDetails
- in fact analysis details is just a task that is highlighted for user convenience. The code behind is/was generic - if you replace the IDs in the URL you should be able to view any task. Ideally you should be able to re-use this code after extracting to some "base" class - similar how both TaskDetails
and AnalysisDetails
use TaskDetailsBase
. IMHO the refactoring (extracting base functionality) is small enough to do in this PR.
It could look the following
const AnalysisDetails = () =>
<GoodNameForBaseComponent
formatDetailsPath={(applicationId,taskId) => formatPath(Paths.applicationsAnalysisDetails, {
applicationId,
taskId,
});
formatTitle={(taskName) => `Analysis details for ${taskName}`}
// whatever else is needed
/>
const ApplicationTaskDetails = () =>
<GoodNameForBaseComponent
formatDetailsPath={(applicationId,taskId) => ...);
formatTitle={(taskName) => ...}
// whatever else is needed
/>
const tableControlState = useTableControlState({ | ||
tableName: "tasks-apps-table", | ||
persistTo: "urlParams", | ||
persistenceKeyPrefix: TablePersistenceKeyPrefix.tasks, |
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.
it seems we have a collision with TasksPage
@@ -521,3 +554,206 @@ const TabReportsContent: React.FC<{ | |||
</> | |||
); | |||
}; | |||
|
|||
const TabTasksContent: React.FC<{ |
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.
Ideally we should be able to reuse the code from TasksPage
. In the current state this requires a refactoring that would extract the "base" component. The best strategy would be to use a different PR for that and merge it first. This way we (and our test suite) ensure that the refactoring caused no regression.
After the refactoring both TasksPage
and TabTasksContent
should use the base and provide the custom parts. There are few differences:
- identifiers i.e.
tableName
,persistenceKeyPrefix
- visible columns - note that hiding (via
initialColumns
) looks easier then maintaining 2 lists of columns - query params -
implicitFilters
- possibly more
If "base" component variant would be not achievable we can break the TasksPage into smaller parts and try to reuse those.
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.
@rszwajko Thank you for the feedback! I would really like to continue working on this task, but I currently have a challenge. My internship with the company has concluded, and I no longer have access to the computer where the product environment was properly set up. Unfortunately, running Konveyor on Minikube in the Windows operating system presents a significant issue: the local Konveyor UI is inaccessible.
If the issue with installing Konveyor is resolved, I’d be happy to continue working on this task. Please let me know.
Enhancing the application details drawer by adding a "Tasks" tab, displaying a table of tasks associated with the application, implementing filtering, sorting, and pagination functionalities, and including columns for Task ID, Task Kind, Status, and Priority.
Fixes: #1937
screenshot of result: