bug: feed fidget settings wiped when clicking between fidgets in customization mode

[willyogo]

Occasionally when clicking one fidget after another in customization mode, the settings for a fidget will be wiped. So far I've only noticed this with the feed fidget. Please ensure that this issue is fixed for all fidgets that are affected.

note: we've fixed similar issues with settings being wiped or copied over before (i believe we dealt with this with the text and links fidgets).

Steps to repro:

1. In customization mode, click any other fidget, and then click a feed fidget. Notice that the feed fidget's settings are wiped.

AC:

1. The underlying issue causing fidget settings to be wiped when clicking from one fidget to another is solved. In all fidget's cases, settings are no longer wiped when clicking from one fidget to another.

[willyogo]

@CodeRabbit create a plan

[coderabbitai]

Coding Plan

Approach

Fix an issue where Feed fidget settings are occasionally wiped when clicking from one fidget to another in customization mode.

Observations

This is a React application using Zustand for state management. Fidgets are modular UI components managed by the Grid component in customization mode. When a fidget is selected, the Grid renders a FidgetSettingsEditor that manages the editing UI with local state synchronized to the incoming settings prop via useEffect. Each fidget is also rendered through a FidgetWrapper that manages settings with defaults and backfilling. The Feed fidget is unique in having a useEffect that depends on the entire settings object to manage internal navigation state.

Assumptions

Assumption 1: Is the overly sensitive useEffect in Feed.tsx the root cause of settings being wiped?

Options Considered:

• Refine the dependency array to only depend on specific settings that affect navigation (feedType, username, channel, etc.)
• Add a flag to prevent the effect from firing during fidget initialization/transition
• Stabilize the settings object reference to prevent unnecessary effect triggers

Chosen Option: Refine the dependency array to only depend on specific settings that affect navigation (feedType, username, channel, etc.)

Rationale: Refine the dependency array to depend only on the specific settings fields that genuinely affect the feed navigation state (feedType, username, channel, filterType, keyword). This is the most surgical fix that addresses the root cause - the effect firing too frequently - without adding complexity or defensive code. Other fidgets don't have this issue because they don't have effects that depend on the entire settings object. This change makes Feed behave more like other fidgets while preserving the navigation-clearing behavior when it's actually needed.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Fix Feed Fidget Settings Sensitivity

Modify the Feed fidget's useEffect to depend only on the specific settings that affect navigation state, preventing it from firing unnecessarily during fidget transitions and settings synchronization.

Task 1: Refine Feed useEffect Dependencies

Update the useEffect in Feed.tsx to depend only on navigation-relevant settings instead of the entire settings object.

• Modify the useEffect at lines 452-457 in src/fidgets/farcaster/Feed.tsx
• Destructure the specific settings fields that affect feed navigation: feedType, username, channel, filterType, keyword
• Replace settings in the dependency array with these individual fields
• Keep the clear() and push() logic unchanged - only the dependency array changes
• This ensures the effect only fires when navigation-relevant settings actually change, not on every settings update

Task 2: Verify No Other Fidgets Have Similar Issues

Check other fidget implementations to ensure no other fidgets have useEffect hooks that depend on the entire settings object.

• Search through src/fidgets/ for useEffect hooks that include settings in their dependency arrays
• For any fidgets with [settings, ...] dependencies, evaluate whether the entire settings object is necessary or if specific fields would be more appropriate
• Document any findings but only modify fidgets if they are also experiencing the settings-wiping issue
• Focus on fidgets in the farcaster, token, and community categories as they tend to be more complex

🤖 Prompt for AI agents

Fix the Feed fidget's useEffect to prevent unnecessary re-renders during
settings synchronization.

In `src/fidgets/farcaster/Feed.tsx`:
- Locate the useEffect that clears navigation and pushes initialHash
- Destructure specific navigation-relevant fields from settings: feedType,
username, channel, filterType, keyword
- Replace `settings` in the dependency array with these individual destructured
fields
- Keep the clear() and push() logic unchanged

Search `src/fidgets/` for other useEffect hooks depending on entire settings
object and document findings.

Phase 2: Add Validation to Prevent Future Issues

Add a lightweight validation check in FidgetSettingsEditor to prevent saving settings that don't match the currently selected fidget, protecting against any remaining edge cases without adding significant complexity.

Add Fidget ID Consistency Check Before Save

Modify FidgetSettingsEditor to verify settings and fidgetId are synchronized before allowing saves.

• Update src/common/components/organisms/FidgetSettingsEditor.tsx
• In the field onChange handler at lines 152-160, add a check that the current fidgetId matches the expected fidgetId for these settings
• Store the fidgetId in a ref when settings are first loaded in the useEffect (lines 178-183)
• Only call onSave if the current fidgetId matches the ref value
• This provides a safety net without adding complexity, ensuring we never persist mismatched settings

🤖 Prompt for AI agents

Add a safety check in FidgetSettingsEditor to prevent saving mismatched
settings.

In `src/common/components/organisms/FidgetSettingsEditor.tsx`:
- Create a ref to store the fidgetId when settings are initially loaded
- Update the useEffect that syncs settings to also store the current fidgetId in
the ref
- In the field onChange handler, add a check before calling onSave
- Only call onSave if the current fidgetId matches the ref value
- This ensures settings are never saved for the wrong fidget

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Fix the Feed fidget's useEffect to prevent unnecessary re-renders during
settings synchronization.

In `src/fidgets/farcaster/Feed.tsx`:
- Locate the useEffect that clears navigation and pushes initialHash
- Destructure specific navigation-relevant fields from settings: feedType,
username, channel, filterType, keyword
- Replace `settings` in the dependency array with these individual destructured
fields
- Keep the clear() and push() logic unchanged

Search `src/fidgets/` for other useEffect hooks depending on entire settings
object and document findings.
===============================================================================

Task: 2

Add a safety check in FidgetSettingsEditor to prevent saving mismatched
settings.

In `src/common/components/organisms/FidgetSettingsEditor.tsx`:
- Create a ref to store the fidgetId when settings are initially loaded
- Update the useEffect that syncs settings to also store the current fidgetId in
the ref
- In the field onChange handler, add a check before calling onSave
- Only call onSave if the current fidgetId matches the ref value
- This ensures settings are never saved for the wrong fidget

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[willyogo]

@CodeRabbit this plan seems potentially excessive and/or could be a bandaid rather than solving the underlying issue(s). please try again to create a plan that focuses on solving the underlying issue and minimizes unnecessary complexity. the defensive fallbacks for feed fidget is a good idea since fidgets already include support for defaults, but I believe the feed fidget already has defaults, and I don't think adding defaults will help since the issue appears to be related to existing settings (which could be the default) getting wiped.

note that the issue could be limited to feed fidgets since I wasn't able to reproduce with any other fidgets I tested but can consistently repro with the feed fidget.

[coderabbitai]

I've updated the plan above based on your feedback. Ready to proceed when you are!

[Jhonattan2121]

#1646