Render text/mediumtext/longtext (and large varchar) as textarea

[HarshMN2345]

What does this PR do?

(Provide a description of what this PR does.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

Summary by CodeRabbit

• Bug Fixes
  • Textarea inputs now automatically display for text-like columns (text, mediumtext, longtext) regardless of declared size, in addition to existing rules for large column sizes, arrays, and spatial types—making editing long-form text fields more convenient and consistent across the UI.

[appwrite]

Console (appwrite/console)

Project ID: 688b7bf400350cbd60e9

Sites (1)

Site	Status	Logs	Preview	QR
console-stage 688b7cf6003b1842c9dc	Ready	View Logs	Preview URL

Tip

Every Git commit and branch gets its own deployment URL automatically

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 77ac1d8 and b948cf8.

📒 Files selected for processing (1)

• src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/columns/types/string.svelte

🚧 Files skipped from review as they are similar to previous changes (1)

• src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/columns/types/string.svelte

---

Walkthrough

A single Svelte file was modified to add a computed flag forceTextarea that is true for column types text, mediumtext, or longtext. The rendering condition was changed from {#if columnSize >= 50 || array || isSpatialType(column)} to {#if forceTextarea || columnSize >= 50 || array || isSpatialType(column)}, causing textarea inputs for those text-like column types regardless of declared size. No public/exported API changes were made.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: rendering text/mediumtext/longtext and large varchar as textarea elements in the console UI.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch text-types-textarea

---

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 and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/columns/types/string.svelte (1)

46-51: varchar > 255 arm of forceTextarea is redundant; string type is inconsistently omitted.

Two related observations:

1. Redundancy: Any varchar column with size > 255 also satisfies columnSize >= 50 in the render condition on line 157, so the (column.type === 'varchar' && columnSize > 255) arm of forceTextarea is never the sole trigger. Consider removing it to keep forceTextarea scoped to types that genuinely need special-casing (text/mediumtext/longtext).

2. Consistency gap: Models.ColumnString (column.type === 'string') is treated identically to Models.ColumnVarchar in the maxlength derivation (line 39), yet it is absent from forceTextarea. If the intent is to document that large string-like columns must be textarea, column.type === 'string' with columnSize > 255 should mirror the varchar arm (or both should be removed if relying on columnSize >= 50).

♻️ Proposed minimal `forceTextarea` (removes redundant arm)

 const forceTextarea = $derived(
     column.type === 'text' ||
         column.type === 'mediumtext' ||
-            column.type === 'longtext' ||
-            (column.type === 'varchar' && columnSize > 255)
+            column.type === 'longtext'
 );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/routes/`(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/columns/types/string.svelte
around lines 46 - 51, Remove the redundant "(column.type === 'varchar' &&
columnSize > 255)" arm from the forceTextarea derived value and, for consistency
with the maxlength derivation that treats Models.ColumnString like
Models.ColumnVarchar, either add a corresponding check for column.type ===
'string' (e.g., treat large 'string' columns the same) or omit both
varchar/string size checks and rely on the existing columnSize >= 50 render
condition; update the forceTextarea expression (symbol: forceTextarea,
referencing column.type and columnSize, and keeping text/mediumtext/longtext) so
it matches the maxlength handling for Models.ColumnString/Models.ColumnVarchar.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In
`@src/routes/`(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/columns/types/string.svelte:
- Around line 46-51: Remove the redundant "(column.type === 'varchar' &&
columnSize > 255)" arm from the forceTextarea derived value and, for consistency
with the maxlength derivation that treats Models.ColumnString like
Models.ColumnVarchar, either add a corresponding check for column.type ===
'string' (e.g., treat large 'string' columns the same) or omit both
varchar/string size checks and rely on the existing columnSize >= 50 render
condition; update the forceTextarea expression (symbol: forceTextarea,
referencing column.type and columnSize, and keeping text/mediumtext/longtext) so
it matches the maxlength handling for Models.ColumnString/Models.ColumnVarchar.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@src/routes/`(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/columns/types/string.svelte:
- Around line 46-51: forceTextarea currently includes 'varchar' which forces all
varchar columns (including small ones) into textareas; remove 'varchar' from the
derived condition so only text/mediumtext/longtext are forced, and rely on the
existing columnSize >= 50 check (see forceTextarea and columnSize logic) to
promote large ColumnVarchar fields to textarea instead. Ensure you only change
the condition that builds forceTextarea and do not alter the columnSize >= 50
branch or type names.

[greptile-apps]

Greptile Summary

This PR improves the UX for editing text-like database columns by automatically rendering text, mediumtext, and longtext column types as textareas in the row editor, regardless of their declared size.

Key Changes:

• Added forceTextarea derived value that checks if column type is text, mediumtext, or longtext
• Modified the conditional to use InputTextarea when forceTextarea is true, in addition to existing conditions (large size, array, spatial types)

Impact:

• These column types are designed for long-form text content and always use textarea in the column creation UI (see text.svelte:83)
• This change aligns the row editing experience with the column creation experience
• More intuitive for users working with text fields that can hold thousands of characters

Confidence Score: 4/5

• This PR is safe to merge with minimal risk - it's a focused UX improvement that aligns row editing with column creation behavior
• The change is straightforward and improves consistency across the UI. Text-type columns are semantically designed for long-form content and the column creation UI already uses textarea for these types. The logic is clean and doesn't introduce breaking changes. However, there's a minor inconsistency noted in a previous review comment regarding varchar handling that could be addressed for full consistency.
• No files require special attention

Important Files Changed

Filename	Overview
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/columns/types/string.svelte	Added forceTextarea logic to always render text/mediumtext/longtext columns as textarea regardless of size, improving UX for long-form text fields

_{Last reviewed commit: b948cf8}

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[hmacr]

What about varchar?

[Meldiron]

I would remove columnSzie - always textarea for text