restore $shouldHideControls signal

[dario-daza]

Proposed Changes

• change 1
• change 2

Checklist

• Tests
• Translations
• Security Implications Contemplated (add notes if applicable)

Additional Info

** any additional useful context or info **

Screenshots

Original	Updated
** original screenshot **	** updated screenshot **

[claude]

Claude finished @dario-daza's task in 2m 16s —— View job

---

Code Review

Root cause is correctly identified and fixed. The linkedSignal was recomputing $shouldHideControls from $contenttypes — which goes transiently empty during loading/searching — so the search bar would disappear mid-search. Replacing it with a plain signal(true) driven by DotPaletteListStatus events is the right approach.

---

Issues

dot-uve.js deletion needs explanation

The deleted file is a build artifact (dotCMS/src/main/webapp/ext/uve/dot-uve.js) produced by the libs/sdk/uve build target. The pre-commit hook in .husky/pre-commit already auto-stages it when present. Removing it from source control is correct practice, but:

• HTMLPageAssetRenderedAPIImpl.java has a regex that matches this path — it strips the <script src="/ext/uve/dot-uve.js"> tag during rendering. That remains intact.
• ema-legacy-script-injection.ts exports SDK_EDITOR_SCRIPT_SOURCE = '/ext/uve/dot-uve.js' and injects it. This still works as long as the SDK build runs before the webapp is deployed.
• Risk: if the SDK is not built before starting dotCMS (e.g. fresh clone, dev env), the /ext/uve/dot-uve.js URL will 404 and the UVE editor script won't load. The PR description should confirm the build pipeline guarantees this file exists at runtime.

#removeFavorite snapshot is fragile

// dot-uve-palette-list.component.ts:339
this.#paletteListStore.removeFavorite(contentType.id);
this.$shouldHideControls.set(this.$contenttypes().length === 0);

This reads $contenttypes() synchronously after removeFavorite. Signal store mutations are synchronous, so the removed item should already be gone from the array — this works today. But it's a snapshot that bypasses the #updateControlsVisibility status-subscription path used everywhere else. A consistency concern, not a bug.

$shouldHideControls initial value of true on view change re-subscription

#updateControlsVisibility uses take(1) and subscribes fresh on every view change. If the view changes while a fetch is in-flight, the new subscription waits for the next EMPTY or LOADED status — this is correct. No issue here, just confirming it was checked.

---

Minor

• JSDoc param rename contentTypeName → selectedContentType is correct and matches the actual parameter name.
• linkedSignal import removal is clean.
• PR description is the default template with no actual content filled in.

---