Solved Issue #764 - BUG: Back button in onboarding steps does not work #766
Solved Issue #764 - BUG: Back button in onboarding steps does not work #766ritigya03 wants to merge 6 commits intoAOSSIE-Org:mainfrom
Conversation
📝 WalkthroughWalkthroughThreaded an optional Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant UI as Onboarding Step Component
participant Store as Redux (onboardingSlice)
participant LS as localStorage
participant Router as React Router
rect rgb(240,248,255)
UI->>LS: read persisted flag (e.g., name/avatar/themeChosen/folderChosen)
UI->>Store: select isEditing
end
alt persisted && not isEditing
UI->>Store: dispatch(markCompleted(stepIndex))
Store-->>UI: state updated (completed)
note right of UI: component may early-return (no render)
else not persisted or isEditing
UI->>UI: render step UI
UI->>Store: (on Back) dispatch(setIsEditing(true))
UI->>Router: navigate previousStep
UI->>LS: (on Next) persist choice (localStorage.setItem)
UI->>Store: dispatch(markCompleted(stepIndex)) when appropriate
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (3)
docs/backend/backend_python/openapi.json (1)
2204-2214: Minor schema clarity consideration: consider keeping explicitadditionalProperties: true.The metadata field's
anyOffirst option was simplified from{ "additionalProperties": true, "type": "object" }to{ "type": "object" }. While both are functionally equivalent (additionalProperties defaults to true in JSON Schema), explicitly stating it improves schema intent clarity for maintainers reading the spec. This is optional to address.frontend/src/components/OnboardingSteps/OnboardingStep.tsx (1)
31-31: Non-standard comment style.The comment prefix
✅ FIX:is non-standard. Consider using conventional comment prefixes likeNote:orFix:without emoji for better compatibility with IDEs and linters.- // ✅ FIX: derive stepName from stepIndex (single source of truth) + // Fix: derive stepName from stepIndex (single source of truth)frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx (1)
45-45: Non-standard comment style.The comment
// ✅ THIS WAS MISSINGuses emoji and all-caps, which is non-standard. Consider using conventional comment style for better tooling compatibility.- navigate(ROUTES.HOME); // ✅ THIS WAS MISSING + navigate(ROUTES.HOME); // Navigate to home after theme selection
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
frontend/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (5)
docs/backend/backend_python/openapi.json(1 hunks)frontend/src/components/OnboardingSteps/AvatarSelectionStep.tsx(2 hunks)frontend/src/components/OnboardingSteps/FolderSetupStep.tsx(3 hunks)frontend/src/components/OnboardingSteps/OnboardingStep.tsx(2 hunks)frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx(5 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx (2)
frontend/src/features/onboardingSlice.ts (2)
markCompleted(31-42)previousStep(43-50)frontend/src/constants/routes.ts (1)
ROUTES(1-12)
🔇 Additional comments (8)
docs/backend/backend_python/openapi.json (1)
1120-1127: Clear API documentation with sensible default.The wrapping of the
InputTypereference in anallOfstructure to add atitleanddefaultvalue improves the OpenAPI specification. This makes it explicit that "path" is the default input type, enhancing API clarity for client developers and documentation generation tools.frontend/src/components/OnboardingSteps/FolderSetupStep.tsx (3)
17-17: Cleanup enables the back button fix.Removing
useEffectfrom imports is correct—the component no longer auto-completes on mount, which allows users to navigate back to this step even after completion.
54-56: Back button implementation is correct and properly wired to Redux state management.The
handleBackfunction dispatchespreviousStep(), which finds the last completed step, marks it as incomplete, and updatescurrentStepIndexto point to the first incomplete step. This ensures correct backward navigation through the onboarding flow.
1-149: No action required—step index handling is already consistent across all onboarding components.All onboarding step components (AvatarSelectionStep, FolderSetupStep, ThemeSelectionStep) use the same indexing formula
(stepIndex / totalSteps) * 100for progress calculation and displayStep {stepIndex} of {totalSteps}identically. The minor difference (AvatarSelectionStep calculates inline while FolderSetupStep and ThemeSelectionStep extract to a variable) does not affect consistency.frontend/src/components/OnboardingSteps/AvatarSelectionStep.tsx (3)
1-1: LGTM! Clean removal of unused import.The
useEffectimport was correctly removed since the auto-completion logic that relied on it has been eliminated as part of the back button fix.
44-50: LGTM! Removal of auto-completion guards fixes the back button issue.The removal of the
useEffectauto-completion logic and localStorage early-return guard (not visible in diff) correctly addresses the root cause described in the PR objectives. Previously, these guards prevented backward navigation by:
- Auto-completing the step on mount
- Hiding the component when localStorage contained data
The current implementation properly preserves forward navigation through
handleNextClickwhile allowing the step to render normally during backward navigation.
58-66: Remove this review comment – the 0-based step indexing is intentional design, not a bug.The onboarding flow uses 0-based step indexing throughout:
currentStepIndexstarts at 0 in the Redux state (onboardingSlice.tsline 15)- All step components (
AvatarSelectionStep,FolderSetupStep,ThemeSelectionStep) display steps using the same pattern:Step {stepIndex} of {totalSteps}- All progress calculations use
(stepIndex / totalSteps) * 100consistently- The
markCompleted(stepIndex)action marks completion by index position, which is 0-basedThis design is consistent across the entire onboarding system and there is no evidence of a refactoring that changed from 1-based to 0-based indexing. While displaying "Step 0" to users is unconventional (most UIs start at "Step 1"), this is an intentional architectural choice, not an accidental regression. Applying the suggested diff would break the system since all state management and array lookups rely on 0-based indexing.
If you believe the UX should display 1-based step numbers to users, that's a valid design improvement discussion – but it would require changing all step components and the state management logic together, not reverting to a non-existent previous state.
Likely an incorrect or invalid review comment.
frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx (1)
42-46: Navigation order is not a concern—the HOME route has no dependencies on onboarding state.The
dispatch(markCompleted)andnavigate(ROUTES.HOME)order is correct. Redux state updates synchronously before the navigation occurs. However, this timing is actually irrelevant because the Home component and Layout do not read or depend on the onboarding state. There are no route guards, conditional renders, or component logic that checks onboarding completion status. The code works correctly as written.
| interface OnboardingStepProps { | ||
| stepIndex: number; | ||
| stepName: string; | ||
| stepName: string; // kept as-is (not removed) |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Remove unused stepName prop.
The stepName prop is declared in the interface and accepted as a parameter but is never referenced in the component body. This is dead code that adds confusion.
Apply this diff to remove the unused prop:
interface OnboardingStepProps {
stepIndex: number;
- stepName: string; // kept as-is (not removed)
} export const OnboardingStep: React.FC<OnboardingStepProps> = ({
stepIndex,
- stepName, // still accepted, but not trusted
}) => {Also applies to: 24-24
🤖 Prompt for AI Agents
In frontend/src/components/OnboardingSteps/OnboardingStep.tsx around lines 13
and 24, the stepName prop is declared in the component's props interface and
accepted as a parameter but never used; remove stepName from the props interface
declaration and from the component's parameter list (and any related
destructuring) so only used props remain, then run TypeScript/ESLint to ensure
no remaining references and adjust any callsites if they explicitly passed
stepName.
There was a problem hiding this comment.
Thanks for pointing this out. The stepName prop is not currently used, but I’m keeping it intentionally as it may be needed in future iterations of the onboarding flow (e.g. for analytics, logging, or step-specific overrides). Retaining it avoids reintroducing the prop later and keeps the component interface flexible.
There was a problem hiding this comment.
@ritigya03, understood! Keeping the prop for future extensibility is a valid approach. I appreciate you explaining the reasoning—it makes sense to maintain interface stability if you anticipate needing it soon.
| localStorage.setItem('themeChosen', 'true'); | ||
| dispatch(markCompleted(stepIndex)); | ||
| navigate(ROUTES.HOME); // ✅ THIS WAS MISSING |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
rg -nP --type=ts --type=tsx -C 3 "themeChosen"Repository: AOSSIE-Org/PictoPy
Length of output: 89
🏁 Script executed:
rg -nP -C 3 "themeChosen" --glob "*.ts" --glob "*.tsx"Repository: AOSSIE-Org/PictoPy
Length of output: 701
Remove unused localStorage.setItem call.
Line 43 sets localStorage.setItem('themeChosen', 'true'), but this key is never read or consumed anywhere in the codebase. This is orphaned logic that should be removed since the PR already removed localStorage guards for back navigation handling.
🤖 Prompt for AI Agents
In frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx around lines
43 to 45, remove the unused localStorage.setItem('themeChosen', 'true') call (it
is orphaned and never read); keep the dispatch(markCompleted(stepIndex)) and
navigate(ROUTES.HOME) lines intact, and run a quick repo-wide search for
"themeChosen" to confirm no other references exist so no further cleanup is
needed.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
frontend/src/components/OnboardingSteps/OnboardingStep.tsx (1)
44-47: Remove unreachable switch cases.The
UPDATE_STEPandSERVER_CHECKcases are now unreachable becausecurrentStepNameis derived fromVISIBLE_STEPS, which only containsAVATAR_SELECTION_STEP,FOLDER_SETUP_STEP, andTHEME_SELECTION_STEP. These cases are dead code that adds maintenance burden and confusion.Apply this diff to remove the unreachable cases:
const renderStepComponent = () => { switch (currentStepName) { case STEPS.AVATAR_SELECTION_STEP: return <AvatarSelectionStep {...sharedProps} />; case STEPS.FOLDER_SETUP_STEP: return <FolderSetupStep {...sharedProps} />; case STEPS.THEME_SELECTION_STEP: return <ThemeSelectionStep {...sharedProps} />; - case STEPS.UPDATE_STEP: - return <UpdateStep {...sharedProps} />; - case STEPS.SERVER_CHECK: - return <ServerCheck {...sharedProps} />; default: return <div></div>; } };
♻️ Duplicate comments (1)
frontend/src/components/OnboardingSteps/OnboardingStep.tsx (1)
13-13: Remove the unusedstepNameprop.The
stepNameprop is declared in the interface and accepted as a parameter but is never referenced in the component body. Even with the "not trusted" comment, this remains dead code that adds confusion and maintenance burden.Apply this diff to remove the unused prop:
interface OnboardingStepProps { stepIndex: number; - stepName: string; }export const OnboardingStep: React.FC<OnboardingStepProps> = ({ stepIndex, - stepName, // still accepted, but not trusted }) => {Also applies to: 24-24
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
frontend/src/components/OnboardingSteps/OnboardingStep.tsx(2 hunks)frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx(5 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx
🔇 Additional comments (1)
frontend/src/components/OnboardingSteps/OnboardingStep.tsx (1)
31-50: Core fix correctly addresses the Back button issue.The explicit derivation of
currentStepNamefromstepIndexestablishes a single source of truth for step rendering, which directly addresses the root cause described in the PR objectives. By no longer relying on step completion state, backward navigation becomes reliable.
|
@ritigya03 Kindly resolve merge conflicts ASAP. |
github-actions
bot
added
bug
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
frontend/src/components/OnboardingSteps/FolderSetupStep.tsx (1)
60-60: Progress and step numbering still use 0-based indexing.This is the same issue flagged in previous reviews. The progress calculation
stepIndex / totalStepsand step labelStep {stepIndex}display 0-based values to users:
- First step (stepIndex=0): shows "Step 0 of 3" with 0% progress
- Second step (stepIndex=1): shows "Step 1 of 3" with 33% progress
- Third step (stepIndex=2): shows "Step 2 of 3" with 66% progress
Users expect 1-based numbering and progress that reflects completion of the current step.
🔎 Apply the previously suggested fix
- const progressPercent = Math.round((stepIndex / totalSteps) * 100); + const progressPercent = Math.round(((stepIndex + 1) / totalSteps) * 100);<span> - Step {stepIndex} of {totalSteps} + Step {stepIndex + 1} of {totalSteps} </span>Also applies to: 68-68
frontend/src/components/OnboardingSteps/OnboardingStep.tsx (1)
34-36: Add lower bound check to prevent negative array index.The
safeIndexclamping only enforces an upper bound. IfstepIndexis negative,VISIBLE_STEPS[safeIndex]returnsundefined, causing the switch statement to render an empty fallback div instead of surfacing the invalid state.🔎 Apply the previously suggested fix
// FIX: derive stepName from stepIndex (single source of truth) - const safeIndex = Math.min(stepIndex, VISIBLE_STEPS.length - 1); + const safeIndex = Math.max(0, Math.min(stepIndex, VISIBLE_STEPS.length - 1)); const currentStepName = VISIBLE_STEPS[safeIndex];frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx (2)
45-45: Remove unused localStorage call.This line sets
localStorage.setItem('themeChosen', 'true'), but as flagged in previous reviews, this key is never read or consumed anywhere in the codebase. It should be removed since the PR already eliminated localStorage-based guards for navigation.🔎 Proposed fix
const handleNext = () => { - localStorage.setItem('themeChosen', 'true'); dispatch(markCompleted(stepIndex)); navigate(ROUTES.HOME); };
54-54: Progress and step numbering still use 0-based indexing.These are the same issues flagged in previous reviews:
Line 54: Progress calculation
stepIndex / totalStepsproduces incorrect percentages:
- Theme step (stepIndex=2, totalSteps=3) shows 66% instead of 100%
Line 62: Step display
Step {stepIndex}shows 0-based numbers:
- Theme step displays "Step 2 of 3" instead of "Step 3 of 3"
Users expect 1-based numbering and progress reflecting completion of the current step.
🔎 Apply the previously suggested fixes
- const progressPercent = Math.round((stepIndex / totalSteps) * 100); + const progressPercent = Math.round(((stepIndex + 1) / totalSteps) * 100);<span> - Step {stepIndex} of {totalSteps} + Step {stepIndex + 1} of {totalSteps} </span>Also applies to: 62-62
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
frontend/src/components/OnboardingSteps/AvatarSelectionStep.tsxfrontend/src/components/OnboardingSteps/FolderSetupStep.tsxfrontend/src/components/OnboardingSteps/OnboardingStep.tsxfrontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- frontend/src/components/OnboardingSteps/AvatarSelectionStep.tsx
🧰 Additional context used
🧬 Code graph analysis (1)
frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx (2)
frontend/src/features/onboardingSlice.ts (2)
markCompleted(31-42)previousStep(43-50)frontend/src/constants/routes.ts (1)
ROUTES(1-12)
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (5)
frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx (3)
45-45: Remove unusedlocalStorage.setItemcall.Line 45 sets
localStorage.setItem('themeChosen', 'true'), but this key is never read or consumed anywhere in the codebase. This is orphaned logic that should be removed.
54-54: Fix incorrect progress calculation.The progress calculation
stepIndex / totalStepsproduces incorrect percentages. For the final step (Theme, stepIndex=2, totalSteps=3), this shows 67% instead of 100%.Examples:
- Avatar (stepIndex=0): 0/3 = 0%
- Folder (stepIndex=1): 1/3 = 33%
- Theme (stepIndex=2): 2/3 = 67% ❌ (should be 100%)
🔎 Proposed fix
- const progressPercent = Math.round((stepIndex / totalSteps) * 100); + const progressPercent = Math.round(((stepIndex + 1) / totalSteps) * 100);
62-62: Fix step numbering for user display.Line 62 displays
Step {stepIndex}using the 0-based index directly. For the Theme step (stepIndex=2), this shows "Step 2 of 3" instead of the expected "Step 3 of 3". Users expect 1-based numbering (Step 1, Step 2, Step 3).🔎 Proposed fix
- Step {stepIndex} of {totalSteps} + Step {stepIndex + 1} of {totalSteps}frontend/src/components/OnboardingSteps/FolderSetupStep.tsx (2)
60-60: Fix incorrect progress calculation.The progress calculation
stepIndex / totalStepsproduces incorrect percentages. For this step when stepIndex=1, it shows 33% instead of 67%.Examples:
- Avatar (stepIndex=0): 0/3 = 0%
- Folder (stepIndex=1): 1/3 = 33% ❌ (should be 67%)
- Theme (stepIndex=2): 2/3 = 67% ❌ (should be 100%)
🔎 Proposed fix
- const progressPercent = Math.round((stepIndex / totalSteps) * 100); + const progressPercent = Math.round(((stepIndex + 1) / totalSteps) * 100);
68-68: Fix step numbering for user display.Line 68 displays
Step {stepIndex}using the 0-based index directly. Users expect 1-based numbering (Step 1, Step 2, Step 3), but this will show "Step 0 of 3" for the first step.🔎 Proposed fix
- Step {stepIndex} of {totalSteps} + Step {stepIndex + 1} of {totalSteps}
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
frontend/src/components/OnboardingSteps/AvatarSelectionStep.tsxfrontend/src/components/OnboardingSteps/FolderSetupStep.tsxfrontend/src/components/OnboardingSteps/OnboardingStep.tsxfrontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx
🧰 Additional context used
🧬 Code graph analysis (2)
frontend/src/components/OnboardingSteps/OnboardingStep.tsx (1)
frontend/src/constants/steps.ts (1)
STEPS(1-7)
frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx (4)
frontend/src/contexts/ThemeContext.tsx (1)
useTheme(66-73)frontend/src/app/store.ts (1)
AppDispatch(24-24)frontend/src/features/onboardingSlice.ts (2)
markCompleted(31-42)previousStep(43-50)frontend/src/constants/routes.ts (1)
ROUTES(1-12)
frontend/src/components/OnboardingSteps/AvatarSelectionStep.tsx
Outdated
Show resolved
Hide resolved
frontend/src/components/OnboardingSteps/AvatarSelectionStep.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx (1)
56-59: Consider resettingisEditingtofalseon forward navigation.Currently,
isEditingis only set totrueon back navigation but never reset tofalseon forward navigation. While this works correctly (initial state resets on page reload), explicitly resetting it inhandleNextwould make the state semantics clearer and prevent potential edge cases if Redux state becomes persisted.🔎 Proposed change
const handleNext = () => { + dispatch(setIsEditing(false)); localStorage.setItem('themeChosen', 'true'); dispatch(markCompleted(stepIndex)); };This same pattern could be applied to
handleNextClickinAvatarSelectionStepandhandleNextinFolderSetupStepfor consistency.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
frontend/src/components/OnboardingSteps/AvatarSelectionStep.tsxfrontend/src/components/OnboardingSteps/FolderSetupStep.tsxfrontend/src/components/OnboardingSteps/ThemeSelectionStep.tsxfrontend/src/features/onboardingSlice.ts
🧰 Additional context used
🧬 Code graph analysis (3)
frontend/src/components/OnboardingSteps/AvatarSelectionStep.tsx (2)
frontend/src/app/store.ts (1)
RootState(22-22)frontend/src/features/onboardingSlice.ts (1)
markCompleted(36-47)
frontend/src/components/OnboardingSteps/FolderSetupStep.tsx (2)
frontend/src/app/store.ts (1)
RootState(22-22)frontend/src/features/onboardingSlice.ts (3)
markCompleted(36-47)setIsEditing(33-35)previousStep(48-55)
frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx (2)
frontend/src/app/store.ts (1)
RootState(22-22)frontend/src/features/onboardingSlice.ts (3)
markCompleted(36-47)setIsEditing(33-35)previousStep(48-55)
🔇 Additional comments (10)
frontend/src/features/onboardingSlice.ts (1)
12-12: Clean addition ofisEditingstate for back navigation support.The new
isEditingflag properly gates auto-completion and early-return logic in step components, enabling backward navigation without steps being skipped. The implementation follows Redux Toolkit conventions correctly.Also applies to: 21-21, 33-35
frontend/src/components/OnboardingSteps/AvatarSelectionStep.tsx (3)
36-45: Good implementation of display index and editing state.The
displayIndexfallback pattern andisEditingselector integration are correctly implemented. Initializing local state from localStorage ensures form values are preserved when navigating back.
47-55: Proper gating of auto-completion and rendering withisEditingcheck.The
!isEditingcondition correctly prevents auto-skipping when the user navigates backward, addressing the root cause of the back button bug.Also applies to: 73-79
87-96: Step numbering and progress calculation are now correct.The 1-based display (
displayIndex + 1) and progress formula((displayIndex + 1) / totalSteps) * 100produce the expected user-facing values.frontend/src/components/OnboardingSteps/FolderSetupStep.tsx (3)
70-73: Correct back navigation implementation.Setting
isEditing(true)before dispatchingpreviousStep()ensures the previous step will render instead of auto-skipping based on localStorage state.
36-47: Consistent editing state integration.The
displayIndexfallback,isEditingselector, and guard conditions match the pattern established inAvatarSelectionStep, ensuring consistent behavior across all onboarding steps.Also applies to: 75-77
79-87: Progress display correctly uses 1-based indexing.The progress percentage and step label now use
displayIndex + 1, showing user-friendly values like "Step 2 of 3" with 67% progress.frontend/src/components/OnboardingSteps/ThemeSelectionStep.tsx (3)
39-50: Consistent implementation of editing state and guard logic.The
isEditingcheck in both theuseEffectand early return correctly prevents the theme step from auto-completing when the user is navigating backward through the flow.
61-64: Back navigation correctly sets editing mode.The
handleBackfunction follows the same pattern as other steps, ensuring consistent backward navigation behavior.
70-78: Progress and step label correctly updated.Using
displayIndex + 1ensures the final step shows "Step 3 of 3" with 100% progress, addressing the previous review concerns.
|
#892 is the new PR for this. |
2 participants
Summary
This PR fixes an issue where the Back button in the onboarding flow was non-functional and did not navigate to the previous step.
Root cause
After reviewing the onboarding logic, the issue was caused by how the current step was resolved:
stepStatus.findIndex)localStorage, which further prevented previous steps from appearingAs a result, Redux state was updated, but the UI did not re-render the expected previous step, making the Back button appear non-functional.
Solution
This PR ensures that backward navigation explicitly updates the active onboarding step instead of relying only on completion state.
localStorageguardsThis results in predictable Back button behavior across all onboarding steps.
What this PR fixes
Short video
PictoPy.mp4
Related Issue
Closes #764
Team Name - EtherX
Summary by CodeRabbit
New Features
Bug Fixes
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.