feat: Add 2 variables: defaultInputValue is used to control the defau…

[LeesinChen]

feat: Add 2 variables: defaultInputValue is used to control the default value of the input box, and inputValueFormat is used to control whether the text in the input box needs to be processed with line breaks.

Description

Please include a brief summary of the change and include the relevant issue(s).

Closes #(issue)

What change does this PR introduce?

Please select the relevant option(s).

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Documentation update (changes to docs/code comments)

What is the proposed approach?

Please give a short overview/explanation on the approach taken to resolve the issue(s).

Checklist:

• [ ] The commit message follows our adopted guidelines
• [ ] Testing has been done for the change(s) added (for bug fixes/features)
• [ ] Relevant comments/docs have been added/updated (for bug fixes/features)

[tjtanjin]

Hey @LeesinChen, thanks for the PR. I can see what the suggested variables are suppose to achieve. Just a few thoughts:

defaultInputValue: Seems strange to support always having a default value within the input textarea. I imagine even if this was required, it would only be scoped to a conversation block. Do you have a use case for this?

inputValueFormat: The variable name itself is a little unclear on what it's doing. Can I propose renaming this to preserveNewline?

Let me know your thoughts!

[LeesinChen]

@tjtanjin Hey~ I'm very happy to have received your response.

When I use this component, I enter the following:

Doctor: Hello Ms. Meyer. What can I do for you today? Patient: My lower back hurts. Doctor: OK. Can you please show me exactly the location of the pain? Patient: (Patient pointing/touching the part that hurts) Doctor: When did it start?

Then I will wait for the AI's answer。

The text contains the '\n' newline character, but is replaced with a single line,

[tjtanjin]

Hey @LeesinChen, thanks for getting back quickly. I can see how inputValueFormat can be useful (though renaming it to preserveNewline will provide more clarity).

That said, how about the global defaultInputValue? Is there a particular use case for it being global as opposed to scoping to a block? On second thoughts, rather than a default value, would using options not be sufficient?

[LeesinChen]

@tjtanjin I understand options to be a robot answer, and I have a usage scenario where I need to enter the default text again within the textarea.

like this picture

Of course, not everyone will have this usage scenario, but I think it makes sense to provide an entry point for setting defaults like this 😄

[tjtanjin]

Hey @LeesinChen, I see what you mean and have pondered over possible approaches. Sharing my thoughts below:

• For inputValueFormat, I am leaning towards renaming it to allowNewline (clearly conveys to users that this option deals with allowing newline in chat input).

• For defaultInputValue, it's a rather niche use case. I am not opposed to supporting it, but if this was to be a feature, then perhaps it should be done on a block level (users can specify default values based on blocks instead of only on start).

That said, I am also a little apprehensive of adding a new attribute to blocks just to support default values. This is something I don't want to rush an approach to only to regret in future. It is likely I will need more time to think over it (there are some re-architecting plans down the road as well that could influence how this idea pans out).

Finally, here's what I propose we do for now:

• If you're still keen to work on this, can I trouble you to revert the changes for defaultInputValue and rename inputValueFormat to allowNewline? I understand if it's too much hassle for you and I'll be happy to do the changes instead.

Do let me know and thank you once again!

[LeesinChen]

@tjtanjin I think your thinking is more comprehensive, I have removed the defaultInputValue parameter and changed the inputValueFormat to allowNewline, I look forward to your continued refinement of more powerful components, thank you very much!

[tjtanjin]

Hey @LeesinChen, thank you for taking the effort to make the requested changes, appreciate it!

On a side note, you have actually brought to my attention that the chat input currently submits even when user holds shift and press enter. One would actually expect to go to a newline with that keyboard action. This is not the best behavior, especially when users want to send a more formatted response.

That said, it is starting to feel like a poor choice was made when enforcing replacing of newlines by default. It slips my mind why I did it in the first place, when after all the textarea's default behavior did allow for newlines 😰 Now that we're providing an option in the form of allowNewline, I'm inclined to set its default value to true.

Edit: Please excuse my indecisiveness, I've recalled that preventing newline by default was chosen as it suited majority of the basic use cases where chatbots just want to take in simple input from users. Allowing newline for users to enter bullet points, format messages etc is more relevant for LLM inputs, live chat etc which are use cases that the chatbot only started supporting this year. With that in mind, then allowNewline falls into a non-basic use case, which means the status-quo can be preserved and allowNewline can default to false. There's also the added benefit that there won't be any changes required of existing users which is great (I hate breaking changes, don't we all 😰).