fix: error when setting text color

[spartan-vutrannguyen]

Description

• When selected a custom color for text, the classname have not been updated.

Related Issues

Type of Change

• Bug fix
• New feature
• Documentation update
• Release
• Refactor
• Other (please describe):

Testing

Screenshots (if applicable)

Additional Notes

---

Important

Fixes text color setting for custom colors and improves file writing error handling.

• Behavior:
  • Fixes text color setting for custom colors in twTranslator/index.ts by updating the color property mapping to handle isCustom flag.
• Error Handling:
  • Adds file path validation and improves base64 content validation in writeFile() in files.ts.
  • Enhances error messages for file writing failures in files.ts.
• UI:
  • Normalizes color names in ColorBrandPicker.tsx using toNormalCase() function.

^{This description was created by for 6a6b1f0. It will automatically update as commits are pushed.}

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 72aef8b in 58 seconds

More details

• Looked at 35 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 7 drafted comments based on config settings.

1. apps/studio/src/routes/editor/EditPanel/StylesTab/single/ColorInput/ColorBrandPicker.tsx:56

• Draft comment:
  Using toNormalCase for group titles is helpful. Ensure that it handles all edge cases for non-string inputs.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

2. apps/studio/src/routes/editor/EditPanel/StylesTab/single/ColorInput/ColorBrandPicker.tsx:76

• Draft comment:
  Applying toNormalCase to color names ensures consistency. Confirm behavior for non-standard color names.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

3. apps/studio/common/helpers/twTranslator/index.ts:981

• Draft comment:
  Nice update: the color mapper now accepts an optional isCustom flag. This makes the logic more flexible. Consider refactoring the nested ternary (or adding comments) for readability.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

4. apps/studio/src/routes/editor/EditPanel/StylesTab/single/ColorInput/ColorBrandPicker.tsx:56

• Draft comment:
  Using toNormalCase to format the group name (and later the color name) improves readability. This change looks clean.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

5. apps/studio/src/routes/editor/EditPanel/StylesTab/single/ColorInput/ColorBrandPicker.tsx:75

• Draft comment:
  Applying toNormalCase on the displayed color names standardizes text formatting. Looks appropriate.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

6. apps/studio/common/helpers/twTranslator/index.ts:1034

• Draft comment:
  Typographical error: In the mapping for 'counter-increment', the output string is written as [content-increment:${getCustomVal(val)}], but it seems it should use 'counter-increment' instead to be consistent with the property name and expected Tailwind class name.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

7. apps/studio/src/routes/editor/EditPanel/StylesTab/single/ColorInput/ColorBrandPicker.tsx:3

• Draft comment:
  Check the import path on line 3: 'ColorPalletGroup'. If this is intended to be 'ColorPaletteGroup' (which is the standard spelling for a collection of colors), please update it for clarity.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_4wZT1BxFi2FBz8pT

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[Kitenite]

Great, thanks Vu!

[ellipsis-dev]

❌ Changes requested. Incremental review on 6a6b1f0 in 1 minute and 28 seconds

More details

• Looked at 70 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 8 drafted comments based on config settings.

1. apps/studio/electron/main/code/files.ts:26

• Draft comment:
  Good addition checking that filePath is provided. Consider also validating that content isn’t undefined if writing empty files is not desired.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

2. apps/studio/electron/main/code/files.ts:35

• Draft comment:
  The base64 branch now properly strips any data URL prefix and validates the data. Consider trimming the base64Data to avoid false negatives from whitespace.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

3. apps/studio/electron/main/code/files.ts:52

• Draft comment:
  Passing an options object with { encoding } to writeFileAtomic is neat; please ensure this matches the expected API of write-file-atomic.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

4. apps/studio/electron/main/code/files.ts:58

• Draft comment:
  Enhanced error handling now logs a detailed message before rethrowing. This is helpful, though ensure the original error isn’t overly masked.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

5. apps/studio/electron/main/code/files.ts:65

• Draft comment:
  The isValidBase64 helper works, but for stricter validation you might consider trimming the input and accounting for edge cases (like extra padding).
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

6. apps/studio/electron/main/code/files.ts:26

• Draft comment:
  Clarify removal of empty content check: Was the check for empty content removed intentionally? If empty files are allowed, please document this behavior.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The comment is asking for clarification/documentation about an intentional change. This violates our rules - we shouldn't ask authors to confirm their intentions or add documentation unless there's a clear issue. Empty files are valid in most filesystems, so allowing them isn't inherently problematic. If empty files caused issues, it would likely be caught in testing.
  Maybe empty files could cause issues in some specific use cases of this module that we're not aware of? The previous check might have been there for a good reason.
  Even if there were specific use cases where empty files are problematic, those should be handled by the calling code, not this general-purpose file writing utility. The function's job is to write files, not enforce content policies.
  Delete the comment. It's asking for clarification/documentation without identifying a clear issue, which violates our review rules.

7. apps/studio/electron/main/code/files.ts:35

• Draft comment:
  Verify base64 handling: Ensure that writeFileAtomic correctly handles Buffer inputs when { encoding: 'base64' } is passed.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  The comment is asking the PR author to verify the behavior of a function, which violates the rule against asking for confirmation or verification of behavior. It does not provide a specific suggestion or point out a clear issue with the code.

8. apps/studio/electron/main/code/files.ts:1

• Draft comment:
  PR title mismatch: The title mentions a text color fix, but the diff only alters file writing logic. Please confirm that these changes address the intended issue.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_KYQY1bV2QTBWFGit

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

Preserve error details: Consider chaining or preserving the original error stack when rethrowing in the catch block.

Suggested change

	throw new Error(errorMessage);
	throw error;