fix: textArea is disabled after chatHistory is loaded

[yaminmomo15]

Description

setTextAreaDisabled(settings.chatInput?.disabled) is not called when the chatHistory is loaded.

Closes #172

What change does this PR introduce?

• Added a useState variable in BotStatesContext.tsx to track chatHistory being loaded.
• Added a function call setIsChatHistoryLoaded(true) after setIsLoadingChatHistory(false).
• Added useEffect() to call setTextAreaDisabled(false) after chatHistory is done loading.

Please select the relevant option(s).

• Bug fix (non-breaking change which fixes an issue)
• 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?

• Implement checking when chatHistory is done loading with a useState variable.
• Enable textArea when chatHistory is done loading.
• isChatHistoryLoaded stays remain true because there is no feature to hide the chat history.
• isChatHistoryLoaded can be set to false with hide chat history button (possible feature).

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)

[yaminmomo15]

@tjtanjin This is strange. Cypress test is passed on my machine with React 19 RC. Please let me know what I can do. 😅

[tjtanjin]

@tjtanjin This is strange. Cypress test is passed on my machine with React 19 RC. Please let me know what I can do. 😅

Test cases are a little flaky. A re-run fixed it. With regard to your PR, I believe this will re-introduce the bugs fixed in v2.0.0-beta.15 🥹 Your current approach means that when chat history is loaded, the text area will be enabled/disabled based on settings. This is not always the case, because a conversation block also allows a chatDisabled attribute, which takes precedence over settings (i.e. follows order of specificity).

[tjtanjin]

Hey @yaminmomo15, I think it's worth considering the context of this feature:

Firstly, the behavior we want to achieve is for text area to be disabled when chat history is loading, and then for it to resume its previous state once loading is done. This is so users don't end up sending stuffs into the chat window while chat history messages are also being added, which may have implications on scroll behavior. This was true in the early days of the library, but it has been a long time since then.

Regardless, it is important to note that the previous state of the text area can be enabled or disabled, and this depends on the following:

1. Whether chatDisabled is specified for the current block
2. Settings (if the block has no chatDisabled)

This is why this existing PR will break, as it only relies on point 2.

---

I've said a bunch above but instead of the existing solution, let's think over it again. What we're trying to achieve here is this:

• Users cannot send anything into the chat while chat history messages are being loaded/added

To achieve this, we don't actually have to disable the text area. It suffices for us to prevent the users from sending input into the chat. There are currently 4 kinds of input (checkbox, options, text area and file uploads). Instead of disabling the text area (which is not a great experience if the user wants to just continue typing without sending yet), we catch and block submission actions (mainly via checking of isLoadingChatHistory). More specifically, the submission actions are:

• Clicking checkbox
• Clicking options
• Clicking send button
• Clicking file upload

The checks can be targeted at blocking the above actions, but this involves looking into them which may be a fair bit of work if you are unfamiliar with the repository. That said, this is a cleaner and less intrusive approach, because a user should still be allowed to type even while chat history is loading. Let me know if you're still keen to explore this, because it will take some effort. Otherwise I can take this up as well. Appreciate the bug report!

[yaminmomo15]

I've said a bunch above but instead of the existing solution, let's think over it again. What we're trying to achieve here is this:

• Users cannot send anything into the chat while chat history messages are being loaded/added

To achieve this, we don't actually have to disable the text area. It suffices for us to prevent the users from sending input into the chat. There are currently 4 kinds of input (checkbox, options, text area and file uploads). Instead of disabling the text area (which is not a great experience if the user wants to just continue typing without sending yet), we catch and block submission actions (mainly via checking of isLoadingChatHistory). More specifically, the submission actions are:

• Clicking checkbox
• Clicking options
• Clicking send button
• Clicking file upload

The checks can be targeted at blocking the above actions, but this involves looking into them which may be a fair bit of work if you are unfamiliar with the repository. That said, this is a cleaner and less intrusive approach, because a user should still be allowed to type even while chat history is loading. Let me know if you're still keen to explore this, because it will take some effort. Otherwise I can take this up as well. Appreciate the bug report!

@tjtanjin There are other things worth noting.

ChatHistoryButton will only appear after user refreshed the page. At the moment, refreshing the page will also reset the conversation path to "start" so the new approach only makes sense if there is a feature to continue the conversion.

If you want to go with the new approach, it is best if I hand this back to you as it needs other features.

[yaminmomo15]

I tested again and got your point now. I overlooked that fact that the ChatHistoryButton can also be clicked when the user is half way through a new conversion. chatDisabled also needs to be considered.

I think it is better to go with the new approach. I will try it first before handing back to you. @tjtanjin

[tjtanjin]

I tested again and got your point now. I overlooked that fact that the ChatHistoryButton can also be clicked when the user is half way through a new conversion. chatDisabled also needs to be considered.

I think it is better to go with the new approach. I will try it first before handing back to you. @tjtanjin

Hey @yaminmomo15, before you try the new approach, can you do me a favor:

• Try disabling this behavior entirely (i.e. keep everything enabled while chat history messages are being loaded/added
• Then try loading chat history messages while sending new messages at the same time (might be easier to test if you increase the 500ms delay to a few seconds for loading chat history messages)

I say this because the decision to have this disable behavior with chat history was taken a long time ago and I frankly can't recall the actual reason for it. If there are no buggy behaviors, this might not even be necessary anymore.

Edit: I'm happy to talk more on discord if this warrants a deeper discussion, if you have yet to join the discord and would prefer to talk there, feel free to reach out.

[yaminmomo15]

I tested again and got your point now. I overlooked that fact that the ChatHistoryButton can also be clicked when the user is half way through a new conversion. chatDisabled also needs to be considered.
I think it is better to go with the new approach. I will try it first before handing back to you. @tjtanjin

Hey @yaminmomo15, before you try the new approach, can you do me a favor:

• Try disabling this behavior entirely (i.e. keep everything enabled while chat history messages are being loaded/added
• Then try loading chat history messages while sending new messages at the same time (might be easier to test if you increase the 500ms delay to a few seconds for loading chat history messages)

I say this because the decision to have this disable behavior with chat history was taken a long time ago and I frankly can't recall the actual reason for it. If there are no buggy behaviors, this might not even be necessary anymore.

Sure, I will disable that behavior and test to see if it can be removed without having bugs.

[yaminmomo15]

I tested with the textAreaDisabled feature removed when chat history is loading. User interaction can continue normally and doesn't affect the loading chat history.

And, loading the chat history doesn't interfere with the user interaction(typing, checkbox, options, sending, and file upload) either, so it makes sense to remove the feature to disable the user actions when chat history is loading.

I have updated the PR with the changes. Please take a look and let me know. @tjtanjin

[yaminmomo15]

@tjtanjin it's ready for review now.

[tjtanjin]

LGTM, thank you for taking the time to check 😊