TT-7335 Improve aesthetics of racetrack UI#314
Conversation
There was a problem hiding this comment.
Pull request overview
Improves the mobile racetrack (workflow step) UI: enlarges the parallelogram step indicators, adds a placeholder passage-navigation dropdown beside them, and adjusts layout so the racetrack stays centered on wider screens via a mirroring spacer.
Changes:
- Resize step indicators to 80×30 with a
clipPathparallelogram, overlap edges, and reformat the centered label/tip. - Add a passage-selection
Button+Menu(book/reference) that, when an item is chosen, persists the current passage and navigates viausePassageNavigate. - Track the dropdown width with
useLayoutEffect+ResizeObserverand render a matching spacer somx:autocenters the parallelograms.
gtryus
left a comment
gtryus
left a comment
There was a problem hiding this comment.
I also put some devin.ai comments into the code but here is one that doesn't fit in this module.
devin.ai reports this issue:
Cypress testing rule file references outdated SVG-based rendering
The .cursor/rules/cypress-testing-takeaways.mdc states: "WorkflowStepsMobile renders SVG stages (no visible text nodes). Assert on structure (svg, svg g)." The component no longer uses SVG — it now uses CSS clipPath on ButtonBase elements. The existing Cypress tests in MobileWorkflowSteps.cy.tsx correctly use data-cy selectors and don't rely on SVG structure, so they should still pass. However, the rule file is now stale and should be updated to reflect the new rendering approach (CSS clip-path parallelograms, passage dropdown). Similarly, the advice about dispatching a resize event after mount may no longer be needed since the width-driven step list was replaced with a flex/scroll layout.
| const passRecIds = related(section, 'passages'); | ||
| if (!Array.isArray(passRecIds)) return []; | ||
| return passRecIds | ||
| .map((p) => findRecord(memory, 'passage', p.id) as PassageD) |
There was a problem hiding this comment.
sectionPassages includes publishing titles unlike nextPassageRecord
The sectionPassages memo at lines 53-59 includes all passages from the section. In contrast, nextPassageRecord in nextPasId.ts:21-26 filters out publishing titles via isPublishingTitle(). This means the passage dropdown will show publishing title entries (e.g., section headers used for publishing) as selectable items. This may be intentional for the dropdown use case (showing all passages for navigation) or may be an oversight.
| rememberCurrentPassage(memory, remId); | ||
| passageNavigate(`/detail/${prjId}/${remId}`); | ||
| setPassageMenuAnchor(null); | ||
| }} |
There was a problem hiding this comment.
Passage dropdown always visible regardless of workflow progression mode
The PassageDetailMobileFooter at PassageDetailMobileFooter.tsx:65-66 conditionally hides passage prev/next navigation when orgDefaultWorkflowProgression === 'step' (showing step-based navigation instead). The new passage dropdown in the header is always shown regardless of the progression mode setting. This means in 'step' progression mode, the footer hides passage navigation but the header now provides it. This may be intentional (providing a way to switch passages even in step mode) or may be an inconsistency worth confirming with the team.
Another issue:
Passage dropdown does not guard against active recording state
The handleSelect function at line 66-73 blocks workflow step changes when recording || commentRecording is true. However, the new passage dropdown's onClick handler at lines 149-153 does not check these states before navigating to a different passage. If a user taps a different passage while actively recording audio, the navigation could interrupt the recording without warning.
That said, this is consistent with the existing pattern: PassageDetailMobileFooter.tsx:117-130 also does not check recording state before passage navigation, and PassageDetailChooser.tsx:55-67 similarly omits this check. The passageNavigate flow goes through checkSavedFn (UnsavedContext), which may provide some protection, but recording state and unsaved-changes state are tracked separately. This appears to be a pre-existing design gap rather than a regression.
Changes:
Before:
After:
