-
Notifications
You must be signed in to change notification settings - Fork 11
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
fix(dashboard): nested parents #1317
Conversation
id: ids[0], | ||
} | ||
} | ||
const wfRunId: WfRunId = ids.reduce((wfRunId, id, i) => (i === 0 ? { id } : { id, parentWfRunId: wfRunId }), {} as WfRunId); |
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 list must be reversed, please use the previous implementation.
const wfRunId: WfRunId = ids.reduce((wfRunId, id, i) => (i === 0 ? { id } : { id, parentWfRunId: wfRunId }), {} as WfRunId); | |
const wfRunId = ids | |
.reverse() | |
.reduceRight<WfRunId | undefined>((parentWfRunId, id) => ({ id, parentWfRunId }), undefined) |
Also, this should be done in the calling function. you can pass the string array from this page, so the receiver has the logic to generate the valid WfRunId.
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 previous implementation negates the reverse
by immediately after doing reduceRight
.
reverse().reduceRight()
is the same as reduce
.
https://stackoverflow.com/a/20753610
Additionally, the old implementation doesn't work in this scenario because the initial value for the reduce function becomes improperly inserted in the first index. This is why the new implementation uses the i === 0
conditional.
Since this is a server component, I do agree that it should be ran in the client component. I'll make that change.
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.
Also, this should be done in the calling function. you can pass the string array from this page, so the receiver has the logic to generate the valid WfRunId.
This is not mandatory, having it here is fine as well. It's just a preference. If we use the WfRunId in the component for multiple purposes, then we should have a utility function.
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.
Also, this should be done in the calling function. you can pass the string array from this page, so the receiver has the logic to generate the valid WfRunId.
This is not mandatory, having it here is fine as well. It's just a preference. If we use the WfRunId in the component for multiple purposes, then we should have a utility function.
I think it's better practice to include it in the client component as you suggest, so we avoid potentially slowing down the server with any unnecessary operations (even though this operation is so simple that it would never slow anything down here, it's just good practice I suppose 😂 ).
No description provided.