fix(MessageComposer): make textarea full-width in custom composer layouts#3241
Conversation
…outs Scope the .str-chat__textarea sizing rules to the TextareaComposer's own elements instead of the .str-chat__message-composer-controls wrapper, so a custom composer that renders <TextareaComposer> without the default MessageComposerUI still gets a full-width textarea rather than the bare <textarea> falling back to its intrinsic cols width (~160px).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe textarea styling block was moved and explicitly scoped in ChangesTextarea composer styling
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
|
Size Change: +1 B (0%) Total Size: 880 kB 📦 View Changed
ℹ️ View Unchanged
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3241 +/- ##
==========================================
+ Coverage 85.18% 85.21% +0.03%
==========================================
Files 505 505
Lines 15784 15784
Branches 5010 5010
==========================================
+ Hits 13446 13451 +5
+ Misses 2338 2333 -5 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/components/MessageComposer/styling/MessageComposer.scss (1)
247-272: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider using
.str-chat__textarea__textareaclass selector instead of baretextareafor robustness.Relocating the block from
.str-chat__message-composer-controlsto the top level reduces the nestedtextareaselector's specificity from (0,0,3,1) to (0,0,2,1). Using the class.str-chat__textarea__textarea— whichTextareaComposeralready applies — would raise specificity to (0,0,3,0) and make targeting more intentional, compensating for the parent specificity drop.♻️ Proposed refactor
textarea { + .str-chat__textarea__textarea { background: transparent;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/MessageComposer/styling/MessageComposer.scss` around lines 247 - 272, Update the nested selector inside .str-chat__textarea to target the existing .str-chat__textarea__textarea class instead of the bare textarea element, preserving the current input styles while restoring intentional specificity after moving the block to the top level.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/components/MessageComposer/styling/MessageComposer.scss`:
- Around line 247-272: Update the nested selector inside .str-chat__textarea to
target the existing .str-chat__textarea__textarea class instead of the bare
textarea element, preserving the current input styles while restoring
intentional specificity after moving the block to the top level.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 54571bb1-c367-4869-85c7-680a61b00705
📒 Files selected for processing (1)
src/components/MessageComposer/styling/MessageComposer.scss
… fix Loosening the .str-chat__textarea selector dropped its specificity from (0,3,1) to (0,2,1), which let the global `.str-chat *:focus-visible` outline rule (base.scss, (0,3,0)) override the textarea's `outline: none` and show a focus ring. Re-assert the reset on :focus-visible so it lands at (0,3,1) and keeps outranking the global outline.
## [14.9.0](v14.8.0...v14.9.0) (2026-07-16) ### Bug Fixes * custom doUploadRequest permission adjustments ([#3243](#3243)) ([fa67adf](fa67adf)), closes [GetStream/stream-chat-js#1800](GetStream/stream-chat-js#1800) * **MessageComposer:** make textarea full-width in custom composer layouts ([#3241](#3241)) ([05236db](05236db)) ### Features * expose internal contexts and composer components in the public API ([#3242](#3242)) ([6b6a828](6b6a828)), closes [GetStream/docs-content#1431](https://github.com/GetStream/docs-content/issues/1431)
|
🎉 This PR is included in version 14.9.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
3 participants
🎯 Goal
The message composer
<textarea>does not fill its container when the SDK is integrated into a custom composer layout — it collapses to ~160px — even though it stretches correctly in our own example apps.Root cause: the rules that give the composer textarea its width live only inside the
.str-chat__message-composer-controlswrapper, scoped as:.str-chat__textareaand its<textarea>are rendered byTextareaComposer, but a custom composer that renders<TextareaComposer>without the defaultMessageComposerUInever produces the.str-chat__message-composer-controlswrapper. So the selector never matches, nowidthis applied, and the bare<textarea>falls back to its intrinsiccols=20width (~160px). Our example apps use the defaultMessageComposerUI, so the wrapper is present and the bug is invisible there.This is a recurring integration pain point, hence fixing it in the SDK rather than asking each integrator to re-add the width rule.
🛠 Implementation details
Lifted the
.str-chat__textareablock out of the.str-chat__message-composer-controlswrapper inMessageComposer.scssso it is scoped to theTextareaComposer's own elements (.str-chat .str-chat__textarea/.str-chat .str-chat__textarea textarea) instead of the composer-controls layout wrapper.Why this is safe:
.str-chat__textareaand its<textarea>are rendered only byTextareaComposer, and no other rule targets.str-chat__textarea, so lowering selector specificity from(0,3,1)to(0,2,1)conflicts with nothing.flex: 1on the wrapper is ignored when its parent isn't a flex container (custom composers) and continues to work in the default composer where the parent isdisplay: flex.MessageComposerUIalready had all of these declarations applied, so its rendering is unchanged.Net effect: any composer that renders
<TextareaComposer>now gets a full-width textarea, with or without the defaultMessageComposerUI.🎨 UI Changes
Verified live in a custom (Slack-style) composer that renders
<TextareaComposer>withoutMessageComposerUI:<textarea>computed width = 160px (intrinsiccols=20fallback).<textarea>computed width = 1059px — fills the composer container; the placeholder spans the full width.No visual change in the default composer (
MessageComposerUI), which already carried these styles.Summary by CodeRabbit