Conversation
| <Dialog | ||
| open={isOpen} | ||
| onOpenChange={open => { | ||
| if (!open) handleSkip(); |
There was a problem hiding this comment.
WARNING: Closing the dialog marks the welcome form as completed
onOpenChange calls handleSkip() whenever open becomes false, and handleSkip() calls markWelcomeFormCompleted. That means a user can be persisted as completed_welcome_form=true without ever submitting the Typeform (e.g. clicking the X). If this is intended, consider renaming the mutation/state to reflect “dismissed” rather than “completed”; otherwise, only call the mutation from onSubmit.
| }} | ||
| > | ||
| <DialogContent | ||
| className="h-[50vh] max-w-[90vw] overflow-hidden p-0 sm:h-[400px] sm:max-w-xl [&>button]:rounded-md [&>button]:p-2 [&>button]:text-black [&>button]:transition-colors [&>button]:hover:bg-black/10 [&>button]:hover:text-black/60" |
There was a problem hiding this comment.
WARNING: Close button styling likely breaks dark-mode visibility
The DialogContent class overrides the direct child button styles with [&>button]:text-black / hover:text-black/60. Since the app is dark-mode only, this can make the close (X) control very low-contrast or effectively invisible on a dark dialog background. Consider using text-foreground (and matching hover colors) or removing the forced text color override.
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (10 files)
|
| is_bot: boolean().default(false).notNull(), | ||
| default_model: text(), | ||
| cohorts: jsonb().$type<Record<string, number>>().default({}).notNull(), | ||
| completed_welcome_form: boolean().default(false).notNull(), |
There was a problem hiding this comment.
Should we default to false? This way every user is going to see it, not just new users. 🤔
There was a problem hiding this comment.
hmm, could be useful info but I'm guessing we don't want that for existing users @emilieschario?
if we don't we can just update the migration to set it true for existing users, what do you think?
ALTER TABLE "kilocode_users" ADD COLUMN "completed_welcome_form" boolean DEFAULT false NOT NULL;
UPDATE "kilocode_users" SET "completed_welcome_form" = true;
There was a problem hiding this comment.
let's make sure we only show to new users
There was a problem hiding this comment.
I'll push the migration update to set that field to true for all existing users.
There was a problem hiding this comment.
I think the bot may have a good point about theming
There was a problem hiding this comment.
It's weird because dark mode on the modal wasn't triggering for me until I forced it in the browser console, regardless it should look good now
| <Widget | ||
| id={WELCOME_FORM_ID} | ||
| style={{ width: '100%', height: '100%', minHeight: '400px' }} | ||
| className="my-form" |
There was a problem hiding this comment.
This class seems redundant?
| onPointerDownOutside={e => e.preventDefault()} | ||
| onEscapeKeyDown={e => e.preventDefault()} | ||
| > | ||
| <DialogTitle className="sr-only">Welcome to the app</DialogTitle> |
There was a problem hiding this comment.
| <DialogTitle className="sr-only">Welcome to the app</DialogTitle> | |
| <DialogTitle className="sr-only">Welcome to Kilo</DialogTitle> |
| <DialogTitle className="sr-only">Welcome to the app</DialogTitle> | ||
| <Widget | ||
| id={WELCOME_FORM_ID} | ||
| style={{ width: '100%', height: '100%', minHeight: '400px' }} |
There was a problem hiding this comment.
Styles here and above are a bit weird, but I guess that's what we need to use because of the library?
There was a problem hiding this comment.
it actually works fine without this.
| email: userEmail, | ||
| }} | ||
| onSubmit={handleComplete} | ||
| onClose={handleSkip} |
There was a problem hiding this comment.
WARNING: Closing the Typeform widget also marks the welcome form as completed
Even if you later change the dialog behavior, onClose={handleSkip} currently calls the same completion mutation as submit. If the intent is to only persist completion on submit, consider removing this handler or changing it to record a distinct "dismissed" state.
| @@ -0,0 +1,2 @@ | |||
| ALTER TABLE "kilocode_users" ADD COLUMN "completed_welcome_form" boolean DEFAULT false NOT NULL; | |||
| UPDATE "kilocode_users" SET "completed_welcome_form" = true; No newline at end of file | |||
There was a problem hiding this comment.
WARNING: Migration may mark users created during deploy as completed
UPDATE "kilocode_users" SET "completed_welcome_form" = true; will also affect any rows inserted after the ALTER TABLE but before the update runs (e.g. users signing up during the migration window), so they may not see the welcome modal even though they're "new". If that edge-case matters, a safer pattern is: add the column nullable/no default → backfill existing rows → then set NOT NULL + DEFAULT false.
There was a problem hiding this comment.
This is such an edge case and the only fix (I believe) would be to add a timestamp to make sure we capture users created in-between. I'm okay with this current approach
|
@iscekic might giving this another look? |
| @@ -0,0 +1 @@ | |||
| ALTER TABLE "kilocode_users" ADD COLUMN "completed_welcome_form" boolean DEFAULT false NOT NULL; No newline at end of file | |||
There was a problem hiding this comment.
WARNING: Migration defaults completed_welcome_form to false for all existing users
ALTER TABLE ... ADD COLUMN ... DEFAULT false NOT NULL will make every pre-existing row effectively have completed_welcome_form=false, so the modal will show for everyone until they close/submit it. If the intended behavior is “only new users see this”, the migration likely needs an explicit backfill for existing users (or a separate “dismissed_at/created_at cutoff” approach).
There was a problem hiding this comment.
sorry @iscekic I lost the update on the merge conflict with main...fixing it now
Summary
Changes
Implementation Details