FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Introduce inputModes option for showing score and comment fields by laander · Pull Request #472 · reflagcom/javascript · GitHub

/ javascript Public

Introduce inputModes option for showing score and comment fields - #472

Open
laander wants to merge 13 commits into
mainfrom
buc-3227-dogfooding-dont-require-satisfaction-score-when-asking-for
ConversationCommits (13)ChecksFiles changed
Open

Introduce inputModes option for showing score and comment fields#472
laander wants to merge 13 commits into
mainfrom
buc-3227-dogfooding-dont-require-satisfaction-score-when-asking-for

Conversation

laander commented Sep 9, 2025 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR introduces a new inputMode option to the Reflag feedback UI that allows developers to control which input fields are shown to users when collecting feedback. This addresses the need for more flexible feedback collection scenarios where satisfaction scores may not always be required.

Changes

Core Feature: inputMode Option

  • New inputMode parameter with three options:
    • "comment-and-score" (default) - Shows both comment field and satisfaction score
    • "comment-only" - Shows only the comment field, no satisfaction score required
    • "score-only" - Shows only the satisfaction score, no comment field

API Changes

  • Updated RequestFeedbackOptions to include the new inputMode parameter
  • Simplified FeedbackSubmission interface - both score and comment are now optional
  • Consolidated callback handling - replaced separate onScoreSubmit with unified onSubmit that returns OnSubmitResult
  • Removed deprecated options:
    • requireSatisfactionScore (replaced by inputMode)
    • openWithCommentVisible (replaced by inputMode)

UI/UX Improvements

  • Streamlined feedback form with cleaner conditional rendering based on inputMode
  • Better validation - ensures at least one field (score or comment) is provided
  • Improved user experience - no longer forces satisfaction scores when only comments are needed

Documentation Updates

  • Updated FEEDBACK.md with comprehensive examples of the new inputMode option.
  • Added new screenshots showing different positioning options (modal, dialog, popover)
  • Enhanced development server with better examples and documentation

Preview FEEDBACK.md
Preview README.md

Technical Improvements

  • Input validation for inputMode parameter with clear error messages
  • Type safety improvements with better TypeScript definitions
  • Code cleanup - removed 315 lines while adding 173 lines (net reduction of 142 lines)

Use Cases

This change enables several new feedback collection scenarios:

  1. Comment-only feedback - For collecting general feedback without requiring satisfaction scores
  2. Score-only surveys - For quick satisfaction polls without requiring detailed comments
  3. Flexible collection - Allows the same feedback UI to adapt to different contexts

Breaking Changes

  • requireSatisfactionScore and openWithCommentVisible options have been removed
  • onScoreSubmit callback has been replaced with unified onSubmit callback
  • FeedbackScoreSubmission interface has been removed

Migration Guide

Before:

reflagClient.requestFeedback({
  flagKey: "my-flag",
  requireSatisfactionScore: false,
  openWithCommentVisible: true
});

After:

reflagClient.requestFeedback({
  flagKey: "my-flag",
  inputMode: "comment-only"
});

Testing

  • All existing tests updated to work with new API
  • New validation tests for inputMode parameter
  • UI tests cover all three input modes

laander marked this pull request as ready for review September 10, 2025 08:59

This comment was marked as outdated.

Sign in to view

roncohen reviewed Sep 10, 2025
View reviewed changes
Comment thread packages/browser-sdk/src/feedback/ui/FeedbackDialog.tsx
position,
translations = DEFAULT_TRANSLATIONS,
openWithCommentVisible = false,
inputMode = "comment-and-score",

roncohen Sep 10, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I'm curious about the background here. My thinking is that if someone submits a comment, we'll eventually be able to deduct the sentiment. So it ends up feeling weird to ever have the comment first and then the satisfaction second? I could imagine the options being:

  • comment only
  • satisfaction + comment shows up (default today)
  • satisfaction + comment visible (default today)

I know this is late feedback, apologies.

laander Sep 10, 2025 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

The inspiration was Vercel (from the Linear issue):

@makwarth: Here's how Vercel does it, which is the way to do it, imo:

I'm curious about the background here. My thinking is that if someone submits a comment, we'll eventually be able to deduct the sentiment. So it ends up feeling weird to ever have the comment first and then the satisfaction second

Wouldn't that be an argument for the opposite? Why have the score first if it can be derived from the comment?

There can also be a value in specifying the score manually like Vercel; either to be clear about intent or if you don't have time to write a comment but still want to give a nod up/down.

satisfaction + comment shows up

In general, we're moving away from a primary satisfaction score towards it being additional/optional. Having two out of three options put score front and center is misleading and not useful IMO.

I don't see much use for the sequential screens anymore and it complicates implementation a lot. IF you're looking to gather a score for a bigger audience (like post GA release), I think a score-only UI is fine? For all other cases, the comment field is preferred

roncohen approved these changes Sep 11, 2025
View reviewed changes

roncohen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

OK lets get this in. And let make sure we cut a new major for all the necessary SDKs.

roncohen commented Sep 11, 2025

Copy link
Copy Markdown
Contributor

and needs a note about breaking changes in the README.

laander mentioned this pull request Oct 9, 2025
Closed
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
Show hidden characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

cursor[bot] cursor[bot] left review comments
roncohen roncohen approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

Back | FazBrowse Home | New Git URL