[Bug] Incorrect Display of Role Setting Input After Second Edit in Assistant Chat Interface

[wjsoj]

📦 Environment

Docker

📌 Version

1.31.5

💻 Operating System

Other Linux

🌐 Browser

Chrome, Firefox

🐛 Bug Description

In the Assistant chat interface, there is an issue where editing the Role Setting a second time results in incorrect content being displayed in the input box.

📷 Recurrence Steps

1. Add a new Assistant.
2. In the new chat interface, click the Edit button in the Role Setting at the top right corner.
3. Modify the content and click OK. The content appears to be updated.
4. Click the Edit button again and notice that the input box is empty and has not updated. (If there was a value in the Role Setting before modification, the input box will show the previous value instead of the new one after clicking Edit.)

🚦 Expected Behavior

I expected the input box to show the updated content after editing the Role Setting a second time.This will be helpful for people who want to Modify the Role Setting again after click OK.

📝 Additional Information

I have noticed that the issue is caused by the implementation in the lobe-ui component. The EditableMessage component internally specifies defaultValue to create a MessageInput component, but in the MessageInput component, defaultValue is handled as follows:

const [temporaryValue, setValue] = useState<string>(defaultValue || '');

This implementation retains the previous value in the input box, making it inconvenient for users to edit again.

Possible Solutions:

• Modify the lobe-chat main repository by adding a key to the EditableMessage component in /src/app/(main)/chat/(workspace)/@topic/features/SystemRole/SystemRoleContent.tsx to trigger a re-render (this would cause the Modal to flicker).
• Modify the lobe-ui implementation by adding a listener for changes to defaultValue in the MessageInput component, but this could make the UI component library unnecessarily complex.

I hope a better solution can be found, and I would be happy to submit a PR.

[lobehubbot]

👀 @wjsoj

Thank you for raising an issue. We will investigate into the matter and get back to you as soon as possible. Please make sure you have given us as much context as possible.\ 非常感谢您提交 issue。我们会尽快调查此事，并尽快回复您。 请确保您已经提供了尽可能多的背景信息。

[dosubot[bot]]

Hey @wjsoj! I'm here to help you with any bugs, questions, or contributions. Let's work together to solve this issue.

The issue you're experiencing with the EditableMessage component in the Assistant chat interface seems to be related to how the defaultValue is handled in the MessageInput component. The current implementation retains the previous value, which causes the input box to not reflect the updated content after a second edit.

Here are a couple of potential solutions:

1. Modify the EditableMessage Component:

   • You could add a unique key prop to the EditableMessage component in the SystemRoleContent.tsx file. This would force a re-render of the component whenever the key changes, ensuring that the input box displays the updated content. However, this approach might cause the modal to flicker, which could affect the user experience.

2. Update the MessageInput Component:

   • Another approach is to modify the MessageInput component in the lobe-ui library to listen for changes to the defaultValue prop. This would involve updating the state whenever defaultValue changes, ensuring that the input box reflects the latest content. While this solution might add complexity to the UI component, it would provide a more seamless user experience.

Both solutions have their trade-offs, and the best approach depends on the desired user experience and the complexity you're willing to introduce into the codebase. If you're comfortable with the potential flicker, the first solution might be simpler to implement. Otherwise, updating the MessageInput component to handle defaultValue changes could provide a more robust solution.

To continue talking to Dosu, mention @dosu.

[darxreborn]

I submitted a similar issue at #4686

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

I submitted a similar issue at #4686

[wjsoj]

I submitted a similar issue at #4686

I am unable to reproduce your issue in the local development environment. Your reported issue seems to be related to the logic of the tRPC interface and I don't understand why.