Fixed the element color refresh to default color when color is deleted from brand panel

[SoloDevAbu]

Description

Fixed element color refresh to it's default value when the color is deleted from brand panel

Related Issues

fixes #1789

Testing

Tested by running locally

Screenshots (if applicable)

Screencast.from.2025-04-27.15-17-23.webm

---

Important

Fixes element color reverting to default when deleted from brand panel and ensures UI refresh in StyleManager, ThemeManager, and ColorInput.

• Behavior:
  • Fixes element color reverting to default when deleted from brand panel in StyleManager.update() in style/index.ts.
  • Ensures UI refreshes after color deletion in ThemeManager.delete() in theme/index.ts.
• UI:
  • Adds effect in ColorInput in ColorInput/index.tsx to update color state when a color is deleted and not found in theme.

^{This description was created by for daf2f83. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to daf2f83 in 2 minutes and 4 seconds. Click for details.

• Reviewed 66 lines of code in 3 files
• Skipped 0 files when reviewing.
• Skipped posting 5 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. apps/studio/src/lib/editor/engine/style/index.ts:84

• Draft comment:
  Using if (!value) might catch unwanted falsy values. Consider explicitly checking for an empty string if that’s the intended condition.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. apps/studio/src/lib/editor/engine/theme/index.ts:336

• Draft comment:
  Consider awaiting scanConfig() before reloading webviews to ensure the refreshed config is applied.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The scanConfig() method does contain async operations but isn't marked as async, which means it won't return a Promise to await. Simply adding await wouldn't work without also making scanConfig() async. Additionally, there's no clear evidence that the order of operations matters here - both operations are just refreshing different parts of the UI. The comment might have a valid concern about race conditions between config scanning and webview reloading. The async nature of scanConfig's internals could mean the webviews reload before new config is ready. Without clear evidence that this causes actual issues, and given that scanConfig() isn't even set up to be awaitable, this suggestion would require larger architectural changes that may not be necessary. Delete the comment. The suggested change would require larger refactoring and there's no clear evidence it's needed.

3. apps/studio/src/routes/editor/EditPanel/StylesTab/single/ColorInput/index.tsx:112

• Draft comment:
  The useEffect uses sendStyleUpdate but it isn’t in its dependency array. Consider adding it to ensure the effect always has the latest version.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% sendStyleUpdate is a memoized function that will only change when its dependencies change. The useEffect is specifically watching for theme color changes to reset invalid colors. If sendStyleUpdate changes, we don't necessarily want to re-run this effect since it's focused on theme changes. The current dependencies seem intentionally chosen to match the purpose. The comment raises a valid point about React hooks best practices. Missing dependencies can lead to stale closures. While technically correct about hooks rules, the current dependency array appears intentionally designed to only run when theme colors change, which matches the effect's purpose. The comment, while technically accurate about React hooks, may be suggesting a change that goes against the intended behavior of the effect. The current implementation seems deliberate.

4. apps/studio/src/lib/editor/engine/style/index.ts:84

• Draft comment:
  Consider adding an inline comment here explaining that when the value is empty, the targets are remapped to explicitly reset the style. This clarifies the intent for future readers.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

5. apps/studio/src/routes/editor/EditPanel/StylesTab/single/ColorInput/index.tsx:112

• Draft comment:
  The new useEffect uses 'sendStyleUpdate' but does not list it in the dependency array. Consider adding 'sendStyleUpdate' (and possibly elementStyle if mutable) to the dependency list to avoid stale closure issues.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is technically correct - these dependencies are used but not listed. However, sendStyleUpdate is memoized with useCallback, so including it would be redundant since it only changes when its own dependencies change. elementStyle is a prop that's used for accessing stable properties (getValue method and defaultValue), which are unlikely to change during the component's lifecycle. I might be wrong about the stability of elementStyle - if it's frequently recreated or its methods/properties change, this could cause issues. The getValue method could potentially be unstable. While elementStyle's stability is a concern, the useEffect is specifically watching theme-related changes (colorGroups and colorDefaults) to reset invalid colors. The current dependency array captures the main intent. The comment, while technically correct, is suggesting changes that aren't necessary for the effect's purpose and could make the code more complex without clear benefits.

Workflow ID: wflow_hJpegwFy5kyXu32G

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}