Template error: Missing module import for PrimeNG AutoComplete
0 reputation · 01 Dec 2024, 03:00 UTC
0 reputation · 01 Dec 2024, 03:00 UTC
In a low-traffic Angular application, reducing the initial JavaScript payload is a primary goal to minimize client-side load costs. PrimeNG supports granular, per-component imports to facilitate tree-shaking and reduce the final bundle size.
While importing only the necessary components (such as AutoCompleteModule) prevents the inclusion of unused library code, this approach increases the risk of template errors if a component is used without its corresponding module being declared in the standalone imports or the NgModule.
There is currently no documented standard for balancing the developer overhead of granular imports against the bundle size benefits for low-traffic scenarios. It remains unclear whether a shared internal PrimeNG module or individual component imports provide the optimal trade-off for build performance and maintenance.
34775 reputation · 01 Dec 2024, 09:09 UTC
To maximize tree-shaking in standalone Angular applications, PrimeNG recommends importing only the specific modules required for your components. For the AutoComplete component, you should import AutoCompleteModule directly from its specific entry point.
import { AutoCompleteModule } from 'primeng/autocomplete';
In a standalone component, add this to your imports array:
@Component({
standalone: true,
imports: [AutoCompleteModule, ...],
template: `<p-autoComplete [(ngModel)]="value" [suggestions]="suggestions" (completeMethod)="search"></p-autoComplete>`
})
export class MyComponent { }
The impact on initial load time is directly tied to the bundle size. Because PrimeNG is shipped as ES2015 modules with sideEffects: false, the Angular compiler (Ivy) can effectively remove unused code during the production build process.
| Import Strategy | Tree-Shaking Impact | Bundle Size Effect |
|---|---|---|
| Direct Component Import | Optimal | Minimum; only the specific component and its dependencies are included. |
| Shared Wrapper (Selective) | High | Negligible difference if the wrapper only re-exports used modules. |
| Shared Wrapper (Bulk) | Poor | Increased; importing a large library bundle can bloat the main JS payload. |
Using a shared wrapper that imports the entire PrimeNG library defeats tree-shaking, potentially increasing the main bundle size by several hundred kilobytes. Direct imports ensure that only the AutoComplete logic is shipped to the client.
To quantify the impact on your specific application, follow these steps:
ng build --configuration production.source-map-explorer or webpack-bundle-analyzer.main.js bundle when using direct imports versus a shared wrapper.Diagnostic Detail: Are you currently using a shared module that exports the PrimeNG modules, or are you importing the entire PrimeNG` library from a single index file?
Use comments to ask for clarification. Post a solution as an answer.
5,540 reputation · 01 Dec 2024, 09:31 UTC
If p-autoComplete is used in a template but the component’s import is absent—whether AutoCompleteModule in an NgModule or the standalone component import in Angular 14+—Angular reports a template compilation error for an unknown element. This happens at compile time and is independent of whether production tree-shaking would later remove unused library code.
To assess bundle impact, compare main.js between a direct import and a shared PrimeNG wrapper module, then search the bundle for p-autoComplete. Build flags such as --prod vary by Angular CLI version, so check the installed CLI documentation before running production builds.