feat(chat): add welcome view when no LM provider is connected - #175
Merged
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The LM chat panel used to show a single gray line ('No messages yet.')
when the user had no connected provider. With no provider, sending a
message would fail with a generic LLM error and there was no obvious
next step.
The new <ChatWelcome /> component replaces the empty state in two
cases:
- the user has never set up a provider
- the user had providers and disconnected them all
It explains what the chat can do, then routes the user to the provider
settings dialog with a single CTA. A small disclaimer under the button
makes it clear that, once a provider IS connected, the video's
transcript will be sent to it.
The composer at the bottom is also disabled in this state (textarea +
send button + placeholder swapped) so the user does not type a message
that will be rejected. A guard in send() still bounces the user to
the settings modal in case the disabled state is bypassed (Enter via
shortcut, etc.).
Localized in all 13 supported locales (en, fr, es, it, pt-BR, de via
zh family, ru, tr, ar, vi, ko-KR, ja-JP, zh-CN, zh-TW) under
chat.welcome.* and chat.composerDisabledNoProvider.
…cted
The original welcome condition only fired when \connectedProviders\ was
empty. That's correct for a fresh install, but a user who had a provider
connected, then clicked Disconnect, ends up in a different state:
- the active config still references that provider (until they pick a
new one)
- \connectedProviders\ is now empty because the credentials are gone
Net effect: the welcome didn't show, the composer stayed enabled, and
the user could still type a message and watch the LLM call fail with a
generic error.
This commit refactors the gate into a tiny pure helper, \canSendChat\,
that returns true only when both:
- \llmConfig.provider\ is non-empty
- that provider is in \connectedProviders\
The four call sites in <LeftPanel /> (panel body, send guard, textarea
placeholder/disabled, send button title/disabled) all switch to that
helper, so the welcome triggers in both flavors of 'no usable provider':
nothing set up, OR set up but disconnected.
…ad prompts Follow-up to the welcome view and the active-provider gate. Four fixes on top of `canSendChat`, all in the same failure family: the UI treated "we do not know yet" as "nothing is connected". - `connectedProviders` started as `[]` and was filled by an async `llmGetSnapshot()`, so the first render of every mount claimed no provider: the welcome card and the disabled composer flashed at users who do have one. Worse, `refreshLlm()` swallows its errors, so a failed snapshot left that state forever and the panel had no way back. It is now `string[] | null`, and `canSendChat` stays optimistic while null — a failed snapshot degrades to the old behaviour (type, send, get the real error) instead of an undismissable welcome card. - The welcome card outranked the message list, so disconnecting a provider mid-project hid the whole conversation. It now only replaces the empty state; an existing history stays on screen with the composer disabled. - The timeline's Auto-enhance hands its prompt straight to `send()`, which consumed it and bounced to the settings modal with no explanation. The guard now raises the same string the composer shows. Also: the welcome card no longer double-pads (`.panelBody` already insets), its region is labelled by its own heading rather than a duplicate `aria-label`, and the CTA test queries the button by role like the other panes' tests instead of a `data-testid`.
…line guessing Auto-enhance → "Smart zooms + cuts (With AI)" toasted success the moment it handed its prompt to the chat prompt-bus, before anything had accepted it. With no usable provider the chat now bounces the prompt to the settings modal, so the user got two toasts contradicting each other: "Asked the AI agent to enhance this recording" "Set up a provider to start chatting." Submitting is not the same as being accepted, and only the consumer knows which happened, so the confirmation moves to the prompt-bus effect in <ChatStripPanel /> and fires only when the prompt is actually taken. The producer just submits. Exactly one toast now fires per click: the confirmation on the happy path, the "set up a provider" error (plus the settings modal) otherwise.
EtienneLescot
force-pushed
the
feat/auto-20260727-d25774eb
branch
from
July 27, 2026 18:39
2461612 to
6b74a49
Compare
Ponytail pass over the diff. No behaviour change; the composer gating and the toast routing are untouched. - three copy-pasted <li> blocks collapse into a map over the feature keys - the bullets were `list-style: none` plus a hand-rolled dot span per row; native markers do it, so the spans and their 9-line rule are gone (the ul/li must stay non-flex or they stop being list-items, and the global reset means `list-style: disc` has to be set back explicitly) - the Sparkles glyph loses its 40x40 tinted tile, keeps its colour - role="region" + useId + aria-labelledby wrapped a transient empty state in a named landmark the <h2> already announces - the es and ja-JP test cases repeated the fr one against 2 arbitrary locales of 13; localeParity.test.ts already enforces key presence, and fr keeps the English-fallback assertion parity cannot see - comment blocks that restated the code, or restated each other, cut back to the parts that are not obvious from the lines below them - dead `background` in the CTA transition (its background never changes) net: -93 lines.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The LM chat panel used to show a single gray line ('No messages yet.') when the user had no connected provider. With no provider, sending a message would fail with a generic LLM error and there was no obvious next step.
The new <ChatWelcome />\ component replaces the empty state in two cases:
It explains what the chat can do (cut silences, add captions, rewrite sections), then routes the user to the provider settings dialog with a single CTA. A small disclaimer under the button makes it clear that, once a provider IS connected, the video's transcript will be sent to it.
The composer at the bottom is also disabled in this state (textarea + send button + placeholder swapped) so the user does not type a message that will be rejected. A guard in \send()\ still bounces the user to the settings modal in case the disabled state is bypassed (Enter via shortcut, etc.).
Related issue
Fixes #
Type of change
Release impact
Desktop impact
How it looks
\
┌────────────────────────────────┐
│ ✨ (green halo) │
│ Bring your own AI │
│ The chat edits your video... │
│ ┌────────────────────────────┐ │
│ │ • Cut silences, tighten... │ │
│ │ • Add captions, zoom on... │ │
│ │ • Rewrite a section, ... │ │
│ └────────────────────────────┘ │
│ [ Set up a provider → ] │
│ ⓘ Your video's transcript... │
└────────────────────────────────┘
\\
QA
pm run test\ (ai-edition): 56 passed
px tsc --noEmit: clean
pm run lint: clean
ode scripts/i18n-check.mjs: no new missing keys
Note on the release branch
Targeting
elease/1.8.0\ per maintainer request. The AGENTS.md says only bugfix cherry-picks land on a release branch during the RC window; this is being pushed as a deliberate exception so the welcome view ships in 1.8.0.