Porsche Design System

Initialization

Table of Contents

Setup
Mounting
Prop Changes
Unmounting
Optimization

Setup#

The most basic integration of @porsche-design-system/components-angular looks like this.

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule, AppRoutingModule, PorscheDesignSystemModule],
  providers: [],
  bootstrap: [AppComponent],
  schemas: [CUSTOM_ELEMENTS_SCHEMA],
})
export class AppModule {}

Internally PorscheDesignSystemModule is calling load() of @porsche-design-system/components-js since the web components are exactly the same. In fact, the framework specific packages like @porsche-design-system/components-angular only provide thin wrapper components for typing, prop binding and good developer experience just like with any other Angular component.

For more details what happens when load() is invoked, please take a look at the Vanilla JS Setup.

Mounting#

In the example from above we didn't render any component, yet, so let's render a single p-button.

<p-button>Hello</p-button>

Once rendered, this produces a p-button tag in the DOM. From here on the exact same things happen as described at Vanilla JS Preparation and Vanilla JS Connect Lifecycle.

In any JavaScript framework, the available wrapper components' purpose is typing, rendering a web component into the DOM and syncing framework props to the rendered component. Once rendered, the web component has its own lifecycle and is not aware of any framework.

Prop Changes#

In case of a prop change the Angular p-button renders again and synchronizes its properties to the rendered p-button element. What follows is, again, exactly as documented at Vanilla JS Change Lifecycle.

Unmounting#

Once the Angular p-button is not needed anymore, e.g. when conditionally rendered or navigating away, the p-button element is removed from the DOM. What happens additionally can be found at Vanilla JS Disconnect Lifecycle.

Optimization#

Now that it is clear what is happening under the hood when a simple p-button is rendered, let's see how this looks from the perspective of network requests and how to improve them if necessary.

Status Quo

By default, the network traffic looks something like this.

starts with the index.html

then continues with the runtime.js, polyfills.js and main.js bundle of the Angular app

which then loads the core chunk

that injects the component chunk

and last the font file after the styles within the component's Shadow DOM are applied

Preloading font files

By applying the getFontLinks() partial we can preload the font assets. As a default, both regular and semi-bold weights are preloaded since they are most commonly used but this can be customized.

As a result, both font files are additionally loaded in parallel, while earlier this happened not only in sequence but even last and only when a style is present on the page that uses the font-family and that particular font-weight which can lead to a phenomena called Flash of Unstyled Text (FOUT).

Preloading component chunks

The loading experience can be improved further by using the getComponentChunkLinks() partial. Without any configuration it simply preloads the core chunk.

Again, with this improvement, the asset is now being loaded in parallel, too.

For the next step, we also want to preload the component chunk by using the partial like

getComponentChunkLinks({ components: ['button'] });

Now, everything is preloaded in parallel.

Just preloading all component chunks on the page or even every chunk available should be avoided.

Instead, the most performant but also more complicated approach would be to only preload the component chunks (and fonts) that are located above the fold which means visible on page load without scrolling.

Applying the getLoaderScript() partial is pointless since there is no benefit because everything Porsche Design System related is loaded before or at the same time as the Angular app itself. Therefore, the DOM is empty once the preloaded chunks are available.

Important

Hint

Conclusion