Skip to content

Conversation

@zweatshirt
Copy link
Contributor

@zweatshirt zweatshirt commented Jan 30, 2026

Description

  • View mode should lead to the summary page, edit mode should lead to step one.
  • View mode can be assumed to be !isEdit, I didn't see useful reason to use dedicated view logic.
  • Routing now uses the calculation id.
    Jira ticket

Setting complete to be !isEdit is useStepList is not needed since the steps list won't render in view mode, so I can remove that if needed.

Testing

  • Go to the Pending Landing of Salary Calculator
  • Click the View button and ensure it only takes you to the Summary and the side panel is not displayed.
  • Check that the Edit button takes you to the beginning of the form and allows editing.

Checklist:

  • I have given my PR a title with the format "MPDX-(JIRA#) (summary sentence max 80 chars)"
  • I have applied the appropriate labels (Add the label "Preview" to automatically create a preview environment)
  • I have run the Claude Code /pr-review command locally and fixed any relevant suggestions
  • I have requested a review from another person on the project
  • I have tested my changes in preview or in staging
  • I have cleaned up my commit history

@zweatshirt zweatshirt self-assigned this Jan 30, 2026
@zweatshirt zweatshirt added the Preview Environment Add this label to create an Amplify Preview label Jan 30, 2026
@github-actions
Copy link
Contributor

github-actions bot commented Jan 30, 2026

Bundle sizes [mpdx-react]

Compared against 5939d0e

Route Size (gzipped) Diff
/accountLists/[accountListId]/reports/salaryCalculator/[calculationId] 159.74 KB added
/accountLists/[accountListId]/reports/salaryCalculator/edit no change removed

@github-actions
Copy link
Contributor

Preview branch generated at https://MPDX-9204-updated.d3dytjb8adxkk5.amplifyapp.com

@zweatshirt zweatshirt marked this pull request as ready for review January 30, 2026 20:56
@zweatshirt zweatshirt marked this pull request as draft January 30, 2026 21:02
@zweatshirt zweatshirt marked this pull request as ready for review January 30, 2026 21:27
@zweatshirt zweatshirt marked this pull request as draft January 30, 2026 21:37
@zweatshirt zweatshirt marked this pull request as ready for review January 30, 2026 21:57
@zweatshirt zweatshirt requested a review from canac January 30, 2026 21:57
Copy link
Contributor

@canac canac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks really good! Just a couple thoughts on ways you could consider refactoring the viewing vs editing logic.

}
router.push({
pathname: `/accountLists/${accountListId}/reports/salaryCalculator/${calculation.id}`,
query: { mode: 'edit' },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way we have this now, the user could add mode=edit to the URL (or go back to a page in their history) and the UI would let them try to edit a pending or approved request (although the server would block updates changes). I think we should flip it and set mode=view when the user wants to view an action-required request instead of editing it.

Then the context can set the editing flag to "(status is in-progress OR status is action-required) AND mode is not view".


const iconPanelItems = useIconPanelItems(isDrawerOpen, toggleDrawer);

return (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it work to change MainContent to render the view step instead of CurrentStep if we are in view-only mode? Then I think you might not need the changes to useStepList. I haven't tried it though - maybe that doesn't work.

@zweatshirt zweatshirt requested a review from canac February 2, 2026 18:09
}) => (
<LandingTestWrapper hasLatestCalculation onCall={onCall}>
<PendingRequestActions calculation={calculation} />
<LandingTestWrapper hasLatestCalculation onCall={onCall} router={router}>
Copy link
Contributor Author

@zweatshirt zweatshirt Feb 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

router={router}>
Realized I forgot to remove this from LandingTestWrapper here, I'll do that (just can't push without using --no-verify at the moment and I'd rather not do that if I can help it)

Copy link
Contributor

@canac canac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work implementing my suggestions! Once staging is back up, I'd like to test the UI. But thanks for the updates here! Really solid work.

const calculation = calculationData?.salaryRequest ?? null;
const [isDrawerOpen, setDrawerOpen] = useState(false);

useEffect(() => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of an effect, you could return something like drawerOpen: editing ? true : drawerOpen from the context (I'm not sure if that conditional is exactly what you were trying to accomplish). It might be better though to remove this useEffect and handle drawerOpen where it's used in SalaryCalculator.

Here's a section in an article about the pattern: https://react.dev/learn/you-might-not-need-an-effect#adjusting-some-state-when-a-prop-changes. The third code block (the "Best" one) is the approach I'm recommending here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice article, it was a helpful reference thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Preview Environment Add this label to create an Amplify Preview

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants