Theme.setLoadedStyleName() is called even when the style load no-ops — one bad first-mount permanently disables a component's CSS for the whole session

[GiorgiLeki]

Environment

• primevue: 5.0.0-rc.2
• @primevue/core: 5.0.0-rc.2
• vue: 3.5.30
• Theme: Aura preset, styled mode (no unstyled, no cssLayer)
• Also observed on 4.5.5 (slightly different symptom — see "v4 vs v5")

Summary

In styled mode, component CSS is injected lazily on first mount. If the theme
CSS for a component resolves empty at that exact moment, BaseStyle.load()
silently returns {} and injects nothing — but _loadThemeStyles() marks the
component's style name as loaded regardless.

Because the flag is global and checked before every subsequent load, no later
instance of that component ever retries. The component then renders with no CSS
for the rest of the session, application-wide — not just in the subtree that
triggered it. There is no error, no warning, and nothing in DevTools except a
missing <style> tag.

Root cause

@primevue/core/basecomponent/index.mjs → _loadThemeStyles():

// component
if (!Theme.isStyleNameLoaded(this.$style?.name) && this.$style?.name) {
  const { css, style } = this.$style?.getComponentTheme?.() || {};

  this.$style?.load(css,      { name: `${this.$style.name}-variables`, ...this.$styleOptions });
  this.$style?.loadStyle({ name: `${this.$style.name}-style`, ...this.$styleOptions }, style);

  Theme.setLoadedStyleName(this.$style.name);   // ← unconditional
}

@primevue/core/base/style/index.mjs → BaseStyle.load():

load(style, options = {}, transform = (cs) => cs) {
  const computedStyle = transform(css`${style}`);
  return isNotEmpty(computedStyle)
    ? useStyle(minifyCSS(computedStyle), { name: this.name, ...options })
    : {};                                     // ← silent no-op, no tag created
}

So the two lines disagree: load() treats "nothing to inject" as a legitimate
no-op and returns {}, while _loadThemeStyles() treats having called it as
proof it succeeded. Once setLoadedStyleName runs, the guard on the next mount
(!Theme.isStyleNameLoaded(name)) is false forever.

_loadCoreStyles() has the same shape (Base.setLoadedStyleName(...) after a
loadCSS() that can no-op the same way).

The empty-CSS condition is the trigger; the unconditional flag is what makes it
permanent and global. Even if the underlying emptiness is a legitimate race,
the next mount should be able to recover — today it cannot.

Impact

• Silent: no error, no warning, no failed network request.
• Global: one poisoned mount removes that component's chrome everywhere for the
  session, including routes that never touch the offending component tree.
• Sticky: only a full page reload clears it.
• Hard to attribute: the component that breaks is usually not the component
  that triggered it, so it reads as "this one screen is unstyled" and is very
  easy to misfile as a CSS/theme bug.

Reproduction (from our app — verified 2026-07-16)

Two fresh sessions, identical build, differing only in which component mounts
the session's first InputNumber:

Fresh session	First InputNumber to mount	style[data-primevue-style-id="inputnumber-style"]	.p-inputnumber computed
Route A (a Dialog with render-time state churn — details below)	that dialog	never created	display:block, position:static — unstyled
Route B (an ordinary Dialog)	that dialog	created, 4,897 chars	display:flex, position:relative — correct

After Route A, navigating anywhere else in the SPA and mounting more
InputNumbers does not recover: the tag is never created, because
inputnumber is already flagged loaded.

Check in DevTools:

// after the bad first mount
document.querySelector('style[data-primevue-style-id="inputnumber-style"]')
// → null, on every route, until a full reload

What churns in our Route A dialog (we believe this is what makes
getComponentTheme()/the computed style resolve empty at that instant, but we
have not proven the emptiness itself — see "What we could not determine"):

1. a <template v-if="syncFn($form)" /> pattern that calls a function during
   render, and that function mutated reactive refs;
2. InputNumbers rendered inside a v-for over a computed derived from those
   same refs — so child count changes during the initial render pass.

We consider (1) our own anti-pattern and have moved that logic into watchers.
We're reporting the framework behaviour regardless: an app-level render
mistake should not be able to permanently disable a component's CSS
process-wide with no diagnostic.

Suggested fix

Only record the style name as loaded when something was actually injected.
useStyle() already returns an isLoaded ref, and load() returns {} on the
no-op path, so the information is available:

const varsSheet  = this.$style?.load(css,      { name: `${this.$style.name}-variables`, ...this.$styleOptions });
const styleSheet = this.$style?.loadStyle({ name: `${this.$style.name}-style`, ...this.$styleOptions }, style);

if (varsSheet?.isLoaded?.value || styleSheet?.isLoaded?.value) {
  Theme.setLoadedStyleName(this.$style.name);
}

Alternatives, in rough order of preference:

1. Make the flag conditional (above). Smallest change; lets the next mount
   self-heal. Same treatment for _loadCoreStyles.
2. Make load() explicit about the no-op — return { isLoaded: ref(false) }
   instead of a bare {}, so callers can't mistake it for success.
3. Warn in dev when getComponentTheme() yields empty CSS for a named
   component. Even without a behaviour change this turns a silent, session-wide
   failure into a one-line clue.

v4 vs v5

• 4.5.5: the <style data-primevue-style-id="inputnumber-style"> tag was
  created, but with empty content.
• 5.0.0-rc.2: the tag is not created at all (consistent with load()
  short-circuiting before useStyle).

Same root cause and same permanence; only the artifact differs. Any workaround
that probes for the tag must therefore check both existence and content.

What we could not determine

• Why the computed style is empty at that moment. We've localised the
  trigger to the render churn above but haven't instrumented Theme/
  getComponentTheme() to show what it returns during the bad pass. If you can
  point at where the theme is expected to be resolvable relative to
  _loadThemeStyles, we're happy to dig further.
• Whether other components are affected. We only hit InputNumber, but nothing
  in the mechanism is InputNumber-specific — any component whose first mount
  lands in a churning subtree should be able to poison itself the same way.

Our workaround (for anyone who lands here)

Re-invoke the loader manually when the tag is missing or empty, using PrimeVue's
own style generator so the output matches what the component would have injected:

import InputNumberStyle from 'primevue/inputnumber/style'

const hasStyle = (name, marker = '') => {
  const el = document.querySelector(`style[data-primevue-style-id="${name}"]`)
  return !!el && (!marker || el.textContent.includes(marker))   // v4 = empty tag, v5 = no tag
}

if (!hasStyle('inputnumber-style', '.p-inputnumber')) {
  const theme = InputNumberStyle.getComponentTheme?.() || {}
  InputNumberStyle.loadStyle({ name: 'inputnumber-style', manual: true }, theme.style).load()
}

This uses primevue/<component>/style + the loader's manual option — both
semi-internal, which is precisely why we'd rather have the fix upstream.

---

Before filing

• Reduce to a minimal StackBlitz: Aura preset + a Dialog that calls a
  ref-mutating function from a <template v-if="fn()" /> + InputNumbers in
  a v-for over a computed of those refs. Confirm the tag is absent and that
  a second InputNumber on another route stays unstyled.
• Confirm against the latest 5.x (we are on rc.2).
• Search existing issues for setLoadedStyleName / isStyleNameLoaded /
  "styles not applied" before opening — the MCP docs mirror carries no issue
  or changelog data, so this needs checking on GitHub directly.

[mertsincan]

Thank you! I'll check it.