Cds Angular Component Imports

[siddharth1903]

Hi,
I would like to know the correct and the most performant way of importing core components into my angular app.
While the documentation states, the import of CdsModule from cds/angular library, the demo app and the story book doesnt seem to import it like that and adds CUSTOM_ELEMENTS_SCHEMA with the usage of deep imports like this
import '@cds/core/accordion/register.js';

On the website,
imports: [BrowserModule, CdsModule],

I believe the second approach enhances the developer experience since editors, intellisense and compilers are going to be able to understand this component now, but does it negatively impact performance (Build time and tree shaking)???
I like the first approach and would assume it doesnt pull the entire cds module in to my builds and is optimised for the components i'm using and would also result is lighter build times. I did notice a 10kb(gzipped) difference with just one component using both the approaches.
Did
import { CdsSearchModule, CdsFormsModule } from '@cds/angular';
instead of
import { CdsModule } from '@cds/angular';

Is this technically the same as import
'@cds/core/search/register.js'; ??

What would you guys suggest?

Sid

[bbogdanov]

Hi @siddharth1903,

The best way is to just use CdsModule. Basically CdsModule holds directives that we generated and published under @cds/angular. It also registers every component we have in @cds/core -> CdsModule

The directives have a selector and define @Inputand @Output of each component that has inputs and outputs. -> Directive template

Tree shaking should be fine but if face any unexpected behaviour let us know.

[siddharth1903]

Okay @bbogdanov ... What do you think about

import { CdsSearchModule, CdsFormsModule } from '@cds/angular';
instead of
import { CdsModule } from '@cds/angular';

We have libraries using clarity presenters, where we wanna keep the bundle sizes and the build times optimal. The library we have holds components that are built on single responsibility principle. Does the use of individual feature modules like the one i have pointed above help in optimization?
Quoting an example from bootstrap
https://ng-bootstrap.github.io/#/getting-started#imports

Material:
https://material.angular.io/guide/getting-started#display-a-component

[gnomeontherun]

The basic question of using CdsModule or not depends on if you want to get the compiler guarantees that come with our Angular wrappers. If you import the web components directly, Angular doesn't know their binding options and so you have to basically disable template checking when using CUSTOM_ELEMENTS_SCHEMA. I believe this is worse than a few kb extra to include CdsModule, but it is a tradeoff. CdsModule also is tree shakeable, so if you don't use a component Angular CLI will drop it from the bundle. CdsModule (and all of the individual subcomponents) handle registering the icons used by these components as well, which again helps the developer experience.

If you want full control over the optimizations, then you can go with the raw web component imports. Angular can use them just fine if you also use CUSTOM_ELEMENTS_SCHEMA. You'll loose type checking, intellisense, and automatic icon registration.

There is no real benefit to importing CdsSearchModule or other component modules like this since the Angular CLI tree shakes out any unused ones, unless again at scale you determine that your build times are faster. I'm not sure how to quantify the time the tree shaking takes specifically in the build, but perhaps you can determine the value of that in your project.

Generally speaking, CdsModule ensures that Angular CLI can process the components, that developers can get intellisense while building, and still keep get what you need.

[siddharth1903]

@gnomeontherun we have a huge modular web application and we have noticed incredibly high build time with production builds.. The application also is expected to grow over a period of time. Our current builds using ClrModule(Angular) in full using a shared module ranges between 35-40 mins. Hence we expect CdsSearchModule and other feature module imports to avoid tree shaking problems with memory. I find this also more efficient, since as a developer i know what my module wants and do not expect the compiler to clean up my mess. I understand, CdsSearchModule and other smaller feature modules register the components, typings etc for that module alone, when compared to CdsModule that is going to register everything! Is it not theoretically faster for spa's that are huge?

[gnomeontherun]

CdsModule doesn't register everything unless it is used. It is just a single module holding all of the individual component modules (like CdsSearchModule) and the components only register if they are used in the scope of the application (and specifically within the scope of the feature/routing modules). Webpack will still have to understand the dependency map of the modules used by various part of the application, so defining just the modules you need may help but if you are using virtually all of the modules in the app somewhere I don't know if you would see much real world improvement in speed. I have no objections to using just the specific component modules if you so choose, or directly registering the Core modules yourself, so long as you understand how things work and how you'll maintain it. We know teams have also moved to using Bazel for their tooling which can offer improvements but its non-trivial to implement and maintain. To that end though, Clarity doesn't document it but does let you import just the modules you need when you need it and if that does improve your build experience then you're welcome to use that approach and not CdsModule.

[siddharth1903]

Thanks @gnomeontherun this is very clear... we will also check the bazel approach to see if it improves the overall experience.. thanks again