Global default config for components?

[daicalong]

Does anyone know if it is possible to set a default for all instances of a component such as tooltip delay? It's becoming tedious to have to set certain behaviors over and over and it opens up to inconsistencies across multiple instances. I know Angular Material has default config for their components but I wasn't able to find anything in the PrimeNG documentation. The closest thing I found was theme options, but that also doesn't offer a lot of context for what could be tweaked.

...
        options: {
          prefix: 'p',
          darkModeSelector: '.portal-dark-theme',
          cssLayer: {
            name: 'primeng',
            order: 'tailwind-base, primeng, tailwind-utilities'
          }
          // would be cool to have something like:
          // tooltip: {
            // showDelay: 250
          }
        }

[haggys22]

I'd love to see this feature implemented as well. There are a few component inputs where I want to set default values for consistent behaviour throughout a whole application, e.g.

• Datepicker showIcon
• Table rowsPerPageOptions (so I can just set paginator if I need pagination and get sensible options by default), size, stripedRows, showGridlines

In some cases I know my application uses components mostly in a certain way

• Most of my checkboxes are used for confirmation but rarely multiple choice, so I'd like to set binary by default
• I have a bunch of generic selects that use objects with a label and value property, so I'd like to have optionLabel/optionValue set by default

[erber014]

What we have done in our project is to create "wrapper" components around the PrimeNG ones where we set things like default values, is this something you have decided against?

[haggys22]

I dislike wrapper components for two main reasons:

• I can't automagically expose all inputs/outputs of the wrapped component but have to implement every single one of them in the wrapper
• If an input signal is typed as something (e.g. string) but has a default value of undefined, I can't assign the undefined default value of the wrapper component to the input without type shenanigans (and if I'm not mistaken setting the default value of undefined would trigger ngOnChanges which might have unintended side effects)

[cagataycivici]

This feature is considered for the upcoming modernization of the component internals.

[Joel-Kornbluh]

@cagataycivici is this still actively being worked on? If not, does primeng accept PRs from contributors?

In the age of AI vibe coding, this component wrapper pattern mentioned above (e.g. shadcn/ui + radix) has become ubiquitous. It's the reason IMO why the React ecosystem skyrocketed, it enables developers to create thin wrapper libraries around base component libraries like Radix UI. The pattern works because React's prop forwarding mechanism allows libraries to expose all underlying component inputs without explicitly listing each one—changes to the base library automatically propagate up.

Angular inherently restrains use of his pattern with its lack of a similar prop forwarding mechanism. But PrimeNG further limits it with its lack of global defaults per component type - which in a sense would eliminate the need for wrapper components entirely.

This gap forces Angular developers to either wrap each PrimeNG component individually, or accept the base library's defaults. This represents a significant gap compared to React's capability. providePrimeNG and PrimeNGConfig only support high-level global settings like ripple effects, z-index management, and theme presets. There is no mechanism to configure component-specific input defaults globally. For example, you cannot set all datepicker instances to default to 24-hour time format, or all dropdowns to have a specific filterMatchMode without creating wrapper components.

Proposed Solution:

Extend the providePrimeNG configuration to accept a defaults object where each component can have its input defaults specified. This would act as a fallback layer where component instances could still override any default by explicitly binding inputs.

If this is not already in the works, I'd be happy to fork and implementa PR with the above solution.

[cagataycivici]

No, it is not planned at the moment.