editor: warn that a reply too short to earn points will not count

[feruzm]

Closes #3473. Mirrors ecency/vision-web#1394, now that the SDK it needs is released and bumped here in #3478.

The gap

The points backend drops a comment whose body is at or under a minimum length once URLs are stripped, so "Thank you", an emoji, or an image-only reply earns nothing and never reaches the daily comment quest. Deliberate anti-spam rule, entirely invisible in the app. Over 7 days it accounted for about a third of all comment activity submitted, which makes it the single biggest source of "quests do not show my action" reports.

The reply composer now says so before the user submits. It does not block submitting: short replies are fine, they just do not pay, and the user should be able to see that before they hit send rather than an hour later on Perks.

Replies only, matching the website. An edit never earns again (the original already claimed the reward), a logged-out user has nothing to earn, and an untouched composer is not worth nagging about.

Where the rule comes from

QUEST_MIN_CONTENT_LENGTH and earnsQuestContentCredit come from the shared quest catalog in @ecency/sdk, so the app cannot drift from the rule the backend applies. That measurement counts code points rather than UTF-16 units, because the backend measures with Python's len(): measuring locally would score 13 emoji as 26 and the composer would promise points that were then refused.

Not re-rendering per keystroke

This editor is uncontrolled on purpose, and the comment on _changeText is explicit that a per-keystroke re-render is the Android typing race the uncontrolled redesign removed. So:

• the only new state is a single earns-credit boolean
• it is recomputed on the existing 500ms debounce, which already calls setIsEditing
• React bails out when the value has not flipped, so the hint costs no extra renders

The predicate is a pure shouldShowShortReplyHint helper (same shape as questChip.ts) so it can be tested without standing up the editor. It takes the caller's already-computed verdict, which is what keeps the component from measuring the body again on every render.

The body is read from the ref rather than falling back to draftBody, so clearing a reply drops the hint instead of continuing to nag about text that is no longer there.

Verification

yarn test:ci    54 passed, 1 skipped (55 suites), 773 passed, 1 skipped (774 tests)
yarn typecheck  0 errors (baseline 0)
yarn lint       0 errors

Ran against the real published @ecency/sdk 2.3.79 rather than the older copy in the shared install.

New tests cover the short replies the backend refuses, the link-only case, a reply long enough to earn, an untouched composer, the non-reply/edit/logged-out gates, and that a caller-supplied verdict wins over measuring the body again.

Not covered by tests: the rendering itself, which needs the full editor. Worth a quick manual look that the hint appears under a short reply, disappears as it gets longer, and never shows on a post or an edit.

Follow-up worth considering

Waves are comments too, so the same rule silently applies to a short wave, and the wave composer says nothing. Out of scope here (the website has the same gap) but probably worth its own issue.

[coderabbitai]

Warning

Review limit reached

@feruzm, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 5 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: f67223b4-c33b-4bba-9867-247ffe51ddce

📥 Commits

Reviewing files that changed from the base of the PR and between c3314c9 and 720e1b1.

📒 Files selected for processing (5)

• src/components/markdownEditor/styles/markdownEditorStyles.ts
• src/components/markdownEditor/view/markdownEditorView.tsx
• src/config/locales/en-US.json
• src/utils/shortReplyHint.test.ts
• src/utils/shortReplyHint.ts

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}