Store Chat Prompt Input Value in Local Storage

[angelplusultra]

Pull Request Type

• ✨ feat
• 🐛 fix
• ♻️ refactor
• 💄 style
• 🔨 chore
• 📝 docs

Relevant Issues

resolves #4604

What is in this change?

This PR implements a small feature to save the state of the workspace chat input value in local storage and will be applied as the initial state for all workspace chats if truthy. It also clears this value when in multi-user mode and the current users signs out. It also clears this value in every other auth clearing situation.

Additional Information

Developer Validations

• I ran yarn lint from the root of the repo & committed changes
• Relevant documentation has been updated
• I have tested my code functionality
• Docker build succeeds locally

[angelplusultra]

@timothycarambat Let me know if you would like each chat thread to have it's own stored prompt input state, I can refactor to do that instead if you prefer.

[timothycarambat]

A couple comments about UX and scope:

• Since this is a convenience feature we should treat it like LAST_VISITED_WORKSPACE as opposed to something critical like AUTH_TOKEN

• This input should also be workspace/thread specific. If I type an input on workspace 1 and go to workspace 2, I should be able to go back to workspace 1 and see my old prompt that was unsent. Scoping this to workspace/thread would be even better and make more sense. Is this currently the case?

• How do we clear the session variable when the input is finally sent? What about when the user deletes all text that was in that input?

• Since the input value can change often it may make sense to put the setItem/update into a debounce handler and just run it after 300ms or some other timeframe has settled. This will keep us from spamming updates to localstorage in the event loop - especially if we are going to scope by workspace/thread since there may be a lookup

Considering the above, it may make sense to move all of this to a util so it has a common interface we can import or wrap around the prompt input as a context or provider. Whichever is cleaner.

In terms of UX, it is unlikely we have users on one machine login as another user on the same machine, but an easy way around this is to just removeItem the cached prompt storage item on all login actions. That way we dont need to remove them on all logouts since there are only a small handful of ways to login.

Tangentially, we do have a lot of code duplicated for removeItem of login methods, might be worth visiting that in another future PR as a refactor to make that a common interface so we are not manually managing these storage items in every place we care about them.

[angelplusultra]

@timothycarambat

• “Since this is a convenience feature…”
I reverted most of the localStorage removal calls that were happening in the more aggressive auth flows. The value now clears only when actions.unsetUser() is invoked or when a user explicitly logs out from the avatar dropdown.

• “This input should also be workspace/thread specific.”
I’ll refactor it so the stored input is scoped properly. Right now it uses a single global state, but I can switch it to a workspace-level or thread-level key—whichever you prefer. My plan is to store a simple JSON map keyed by conversation/thread ID with the prompt value as the entry. Reading/writing stays O(1).

• “How do we clear the session variable when the input is finally sent?”
This is already handled automatically. The effect listening to the input state clears the value whenever a message is sent (since the input itself resets), so the localStorage entry resets accordingly.

• “It may make sense to move all of this to a util…”
No strong opinion either way. The actual code footprint is small (just two lightweight useEffect hooks), but I understand wanting to keep the prompt input area as clean as possible given how complex that part of the app already is.

If you want me to pull it out, I’d recommend creating a small custom hook (usePromptStorage) rather than a context provider. Since we’re not trying to solve prop-drilling here, a hook keeps it simpler and avoids unnecessary abstraction.

Let me know which direction you’d prefer and I’ll implement it.

[timothycarambat]

I’ll refactor it so the stored input is scoped properly. Right now, it uses a single global state, but I can switch it to a workspace-level or thread-level key—whichever you prefer. My plan is to store a simple JSON map keyed by conversation/thread ID with the prompt value as the entry. Reading/writing stays O(1).

Let's do this for sure, as long as we can manage and look up the dict, we should be fine.

• “It may make sense to move all of this to a util…”
No strong opinion either way. The actual code footprint is small (just two lightweight useEffect hooks), but I understand wanting to keep the prompt input area as clean as possible given how complex that part of the app already is.

Once the first point is implemented, I think the footprint may be larger, since now we are CRUD'ing records in a local storage item where we have to stringify/parse JSON over and over. Once the above is implemented, it is worth looking into if this is breaking out into a util - just so management of this functionality is easier to parse. The prompt input is already so complex so making these kinds of things self-contained at least makes the code more readable.

[angelplusultra]

@timothycarambat

Let me know what you think of this approach.

• Prompt input values are now saved on the thread level (1da8003).
• Logic related to this has been mostly abstracted to a custom hook (1da8003).
• Writing to local storage has been debounced 500ms (4228c6b)

[timothycarambat]

Looks good, just some minor changes to use some existing widely used utils for JSON parsing. Additionally, lets remove some verbosity in the comments so its code-readable for the easy stuff