New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aichat: replace retry action on rate-limit prompt #22695
Conversation
A Storybook has been deployed to preview UI for the latest push |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
strings
++
c2b9d1c
to
138f58e
Compare
A Storybook has been deployed to preview UI for the latest push |
A Storybook has been deployed to preview UI for the latest push |
mojom::ConversationTurnPtr turn = chat_history_.back().Clone(); | ||
chat_history_.pop_back(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of cloning, can't we just move the entry, since we're getting rid of it anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, you can, but before sending it to the IPC, you'd have to convert it into a mojo::StructPtr<T>
so, there's no point in returning a move-only value here because we will end up cloning anyways.
most mojo bindings code expects to deal with MyStructPtr version and i think it was a rookie mistake from my side to use MyStruct version for the history vector. i.e std::vector<mojom::ConversationTurn> chat_history_;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note to self: put a todo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, let's put a TODO in the header file for the vector class member
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added TODO
@@ -183,6 +183,7 @@ interface PageHandler { | |||
ClearConversationHistory(); | |||
RetryAPIRequest(); | |||
GetAPIResponseError() => (APIError error); | |||
ClearErrorAndGetFailedMessage() => (ConversationTurn turn); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...and removes it from the history... (not clear from the function name)
@@ -205,7 +208,7 @@ function Main() { | |||
<PageContextToggle /> | |||
</div> | |||
)} | |||
<InputBox /> | |||
<InputBox inputText={failedInputText} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ergonomics of both this inputText
prop and the onFailed
function prop doesn't seem quite right to me. The behavior is not consistent with how we would normally expect a prop with the name "inputText" to be handled. How about we move the current input text state from InputBox to the context, and handle the submission to the conversation there, as well as the resetting of the input text when it fails. So that we have all that logic in the context instead of in the UI coimponents?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i did think about lifting the inputText state to the context, but since it's a high-frequency updated value, the whole context tree would re-render and can lead to side effects. the current approach in the PR takes the minimal route because of that. now, you'd say i could create a whole new context for input-related states, and i'd tell you 'maybe,' but then, is it worth adding another layer when this is used only for one specific scenario? also, redux shouldn't be the answer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, so there will be upcoming use cases where we will need to control the inputText therefore i have lifted the state to context.
ed3936e
to
9814336
Compare
A Storybook has been deployed to preview UI for the latest push |
9814336
to
6305043
Compare
A Storybook has been deployed to preview UI for the latest push |
@@ -213,6 +214,7 @@ class ConversationDriver { | |||
|
|||
// TODO(nullhook): Abstract the data model | |||
std::string model_key_; | |||
// TODO(nullhook): Change this to mojo::StructPtr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: mojo = mojom
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's no such thing as mojom::StructPtr. its part of the mojo namespace. actually, the right notation should be: "Change this to mojo::StructPtr<T>
"
const handleMaybeLater = () => { | ||
getPageHandlerInstance().pageHandler.clearErrorAndGetFailedMessage() | ||
.then((res) => { context.setInputText(res.turn.text) }) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably best that all this logic is contained in the context (via a function), no? In my mind, that was the advantage of moving the state up to the context...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moved to context
if (isCharLimitExceeded) return | ||
if (context.shouldDisableUserInput) return | ||
|
||
getPageHandlerInstance().pageHandler.submitHumanConversationEntry(inputText) | ||
setInputText('') | ||
getPageHandlerInstance().pageHandler.submitHumanConversationEntry(context.inputText) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should probably also move these calls to the context, shouldn't we?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moved to context
6305043
to
e51c49f
Compare
A Storybook has been deployed to preview UI for the latest push |
A Storybook has been deployed to preview UI for the latest push |
Resolves brave/brave-browser#36235
This PR replaces the redundant 'Retry' action, which appears when a user hits a rate limit error, with 'Maybe Later.' This new action dismisses the prompt and returns the failed message to the input box.
Submitter Checklist:
QA/Yes
orQA/No
;release-notes/include
orrelease-notes/exclude
;OS/...
) to the associated issuenpm run test -- brave_browser_tests
,npm run test -- brave_unit_tests
wikinpm run presubmit
wiki,npm run gn_check
,npm run tslint
git rebase master
(if needed)Reviewer Checklist:
gn
After-merge Checklist:
changes has landed on
Test Plan: