Skip to content

fix: Text input fields on ModalBlockView fail to accept user input.#6980

Open
OtavioStasiak wants to merge 10 commits intodevelopfrom
fix.modal-block-input-not-working
Open

fix: Text input fields on ModalBlockView fail to accept user input.#6980
OtavioStasiak wants to merge 10 commits intodevelopfrom
fix.modal-block-input-not-working

Conversation

@OtavioStasiak
Copy link
Contributor

@OtavioStasiak OtavioStasiak commented Feb 12, 2026

Proposed changes

Text input fields on ModalBlockView fail to accept user input.

Issue(s)

How to test or reproduce

  • open the app (open server);
  • Go to a room and type /poll and click on send;
  • type on input;

Screenshots

Types of changes

  • Bugfix (non-breaking change which fixes an issue)
  • Improvement (non-breaking change which improves a current function)
  • New feature (non-breaking change which adds functionality)
  • Documentation update (if none of the other choices apply)

Checklist

  • [X ] I have read the CONTRIBUTING doc
  • I have signed the CLA
  • Lint and unit tests pass locally with my changes
  • I have added tests that prove my fix is effective or that my feature works (if applicable)
  • I have added necessary documentation (if applicable)
  • Any dependent changes have been merged and published in downstream modules

Further comments

Summary by CodeRabbit

  • New Features

    • Added an interactive modal example allowing users to add input fields dynamically with per-field value tracking.
  • Refactor

    • Simplified modal component behavior to improve stability and preserve input focus while typing, reducing unexpected remounts when modal content changes.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 12, 2026

Walkthrough

Refactors the modal wrapper from a curried factory to a single-component export, updates the modal view to use the refactor with a computed modalKey for controlled remounting, and adds a story demonstrating dynamic input fields with add-field functionality and per-field state.

Changes

Cohort / File(s) Summary
Modal Component Refactoring
app/containers/UIKit/MessageBlock.tsx, app/views/ModalBlockView.tsx
Renamed and converted modalBlockWithContext (curried) → ModalBlockWithContext (single-component props). Provider now receives props directly (value={props}) and inner ModalBlock receives ...props. ModalBlockView imports the new export and introduces a computed modalKey to drive remounts; changeState now calls this.setState({}) after mutating this.values.
New Interactive Story
app/containers/UIKit/UiKitModal.stories.tsx
Adds ModalInputWithAddField story: initial input blocks, changeState to track per-field values, addField to append inputs with generated actionIds/labels, and a computed modalKey used when rendering the modal; exposes an "Add field" button to add inputs at runtime.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 A hop, a prop, a single pass,
The modal sheds its curried past.
Fields sprout up with joyous cheer,
Keys keep focus, state is near.
I nibble bugs and dance on screen—hooray! 🥕

🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection ✅ Passed ✅ No merge conflicts detected when merging into develop
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately reflects the primary bug fix in the changeset: addressing text input field failures in ModalBlockView that prevent user input.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


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

Comment @coderabbitai help to get the list of available commands and usage tips.

@OtavioStasiak OtavioStasiak temporarily deployed to experimental_android_build February 13, 2026 02:24 — with GitHub Actions Inactive
@OtavioStasiak OtavioStasiak marked this pull request as ready for review February 13, 2026 15:57
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@app/views/ModalBlockView.tsx`:
- Around line 259-261: The modalKey computation in ModalBlockView uses
`${data.viewId}-${blocks.length}-${blocks.map((b: any) => b.blockId ||
b.type).join('-')}` which fails to detect reordering or same-type replacements
because it falls back to b.type for blocks without blockId; update the key
generation (modalKey) to include more specific identifiers such as
b.element?.actionId (and/or other unique element IDs) as an additional fallback
alongside b.blockId and b.type so that input blocks and reordered/replaced
blocks produce distinct key segments and force the tree to remount when
structure changes.
🧹 Nitpick comments (3)
app/containers/UIKit/UiKitModal.stories.tsx (1)

787-798: Stale closure: use prev instead of blocks inside the updater callback.

Lines 788 and 794 reference the outer blocks state variable inside setBlocks(prev => ...). If addField were called in quick succession, blocks.length would be stale. Use prev.length instead for correctness.

Proposed fix
 const addField = () => {
-	const nextId = `input-${blocks.length + 1}`;
 	setBlocks(prev => [
 		...prev,
 		{
 			type: 'input',
-			element: { type: 'plain_text_input', actionId: nextId },
-			label: { type: 'plain_text', text: `Field ${blocks.length + 1}`, emoji: true },
+			element: { type: 'plain_text_input', actionId: `input-${prev.length + 1}` },
+			label: { type: 'plain_text', text: `Field ${prev.length + 1}`, emoji: true },
 			placeholder: { type: 'plain_text', text: 'Type here…', emoji: true }
 		}
 	]);
 };
app/containers/UIKit/MessageBlock.tsx (1)

15-19: value={props} leaks all caller props into KitContext.

Every prop passed to ModalBlockWithContext (e.g. blocks, language, viewId, etc.) becomes part of the context value consumed by all KitContext consumers. This works today because of any typing, but it's fragile — any new prop added by the caller silently enters the context. Consider constructing an explicit context object from the relevant props instead.

That said, this is consistent with the existing codebase patterns, so this is a low-priority nit.

app/views/ModalBlockView.tsx (1)

245-251: this.setState({}) is needed but deserves a comment.

Since this.values is a mutable instance field (not React state), calling this.setState({}) is the only way to force a re-render so that the updated values ref is passed down to ModalBlockWithContext. This is correct but non-obvious — a brief inline comment would help future readers understand the intent.

Suggested comment
 	changeState = ({ actionId, value, blockId = 'default' }: IActions) => {
 		this.values[actionId] = {
 			blockId,
 			value
 		};
+		// Force re-render so updated this.values is passed as a prop to ModalBlockWithContext
 		this.setState({});
 	};
📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 757ea73 and 83d2152.

⛔ Files ignored due to path filters (1)
  • app/containers/UIKit/__snapshots__/UiKitModal.test.tsx.snap is excluded by !**/*.snap
📒 Files selected for processing (3)
  • app/containers/UIKit/MessageBlock.tsx
  • app/containers/UIKit/UiKitModal.stories.tsx
  • app/views/ModalBlockView.tsx
🧰 Additional context used
🧬 Code graph analysis (3)
app/containers/UIKit/MessageBlock.tsx (1)
app/containers/UIKit/utils.ts (1)
  • KitContext (17-17)
app/views/ModalBlockView.tsx (1)
app/containers/UIKit/MessageBlock.tsx (1)
  • ModalBlockWithContext (15-19)
app/containers/UIKit/UiKitModal.stories.tsx (2)
app/containers/UIKit/utils.ts (2)
  • KitContext (17-17)
  • defaultContext (10-15)
app/containers/UIKit/index.tsx (2)
  • UiKitComponent (214-214)
  • UiKitModal (212-212)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: E2E Build Android / android-build
  • GitHub Check: E2E Build iOS / ios-build
  • GitHub Check: Build Android Experimental / Build
🔇 Additional comments (1)
app/views/ModalBlockView.tsx (1)

265-275: Looks good — the React.Fragment key-based remount is the right approach for the hooks-count mismatch fix.

When blocks are added/removed, the key changes and forces a full remount of ModalBlockWithContext, ensuring the internal hook count of the UIKit parser stays consistent. Typed values won't change the key, so input focus is preserved during typing.

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.

@OtavioStasiak OtavioStasiak had a problem deploying to experimental_android_build February 13, 2026 16:41 — with GitHub Actions Error
@OtavioStasiak OtavioStasiak changed the title fix: input saving the text typed and breaking the app on add a new op… fix: Text input fields on ModalBlockView fail to accept user input. Feb 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant