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

Release Notes

• Bug Fixes
  • Textarea inputs now display for text-based columns (text, mediumtext, longtext) and varchar fields exceeding 255 characters for improved data entry experience.

[appwrite]

Console (appwrite/console)

Project ID: 688b7bf400350cbd60e9

Sites (1)

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

Tip

Sites support three domain rule types: Active deployment, Git branch, and Redirect

[coderabbitai]

Walkthrough

A single file was modified to introduce a new computed flag forceTextarea that evaluates to true for text-type columns (text, mediumtext, longtext) or varchar fields exceeding 255 characters. This flag was added to the textarea rendering condition, allowing textarea inputs to be displayed for these larger text-like columns in addition to existing criteria.

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 'Render text/mediumtext/longtext (and large varchar) as textarea' clearly and specifically describes the main change: updating how certain text column types are rendered in the 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.

[Meldiron]

even short varchars sohuld have textarea.

Suggested change

	(column.type === 'varchar' && columnSize > 255)
	column.type === 'varchar'