Navigation Layouts

Understand how to use the different navigation layouts

We provide great flexibility by offering four different desktop layouts and one specifically for mobile devices.

A. Highlighted Top Navbar

Layout A - Highlighted Top Navbar

This layout defines a full width top navigation and a secondary vertical navigation less prominent that sits directly on the background of the main content.

B. Highlighted Side Nav

Layout B - Highlighted Side Nav menu

This layout includes a primary vertical side navigation with a highlighted background and a secondary top navigation that sits directly on the background of the main content.

C. Highlighted Combo

Layout C - Highlighted Side Nav menu + Top Navbar

This layout is very similar to the previous one with the difference that the secondary top navigation is a bit more prominent with a highlighted background color.

D. Side Navbar + Side Nav

Layout D - Side Navbar + Side Nav menu

This layout offers an alternative to the more traditional layouts described above. It includes two vertical navigations, a highlighted side navbar and a secondary side nav menu. It leaves less horizontal space for the main content but provides quick abbreviated references to primary actions. It's very useful for wide viewports.

In the src/app/app-routing.module.ts file you may notice we also use an Empty Layout. This one works as a wrapper for routes that do not require navigation components (side menus, top nav bar) like Authentication pages.

Adaptive Layout

We strive to get the most flexibility out of the implementation. That's why we packed a combination of responsive CSS styles (using media queries), and a mechanism to adapt the behavior of the layout to different screen sizes and devices.

Responsive CSS styles

As we mentioned before, we use Bootstrap Sass mixins to ease the implementation of responsive styles. This give us the flexibility to adjust the UI based on different CSS media queries for different viewports.

Responsive Javascript behavior

Using CSS media queries to adjust the UI is great, but sometimes we need to adjust the behavior of our app depending on the different screen sizes. For those situations we need a tool that notify us about screen size changes in our components (Javascript context). Luckily Angular Material CDK provides a BreakpointObserver utility for evaluating media queries and reacting to their changing.

In particular, we use this utility to adjust the different navigation (<mat-sidenav>) modes depending on the current screen size.

Screen Size	Sidenav mode
XL	side
LG	side
MD	push
SM	push
XS	push

Side nav in 'push' mode

Side bar in 'side' mode

By following this approach we improve the responsiveness of the app's main content.

Conditional rendering

Sometimes responsive styles are not enough. Don’t get me wrong, you can achieve a great variety of UI/UX with just CSS media queries. But there are some scenarios where you may require a different structure/layout in order to achieve the desired experience.

That’s why, besides the four different navigation layouts you can choose from, we included a mechanism to change the layout depending on the screen size changes and also the device that’s requesting the app. This means that we render the app with the mobile layout or the default desktop layout depending whether the user is requesting the app from mobile device or not. Also, we re-render the layout if the user shrinks or enlarges the screen beyond a specific breakpoint.

Screen Size Transition	Rendered Layout
SM -> XS	Mobile layout
XS -> SM	Desktop layout

For this solution we used the handy Angular Material CDK portals that provides a flexible system for rendering dynamic content into an application. All the mechanism is handled by the DynamicLayoutComponent.

The architecture of the mechanism involves some extra code in our Angular server side configuration, and in the client side uses the same mechanism we use to dynamically change layouts in our demo page.

We added some extra bits of code to make this solution work with server side rendering (Angular Universal). This takes care of the initial page loading, before the client side code executes. That's why we needed to add the mobile-detect node module to our server.ts in order to classify the user-agent header coming in the user REQUEST of the app and then add a custom mobile-device header to the RESPONSE we send back to the user with the Angular app already rendered.

You will notice how the DynamicLayoutComponent checks the RESPONSE object sent in the server.ts and depending on the device the user is requesting the app from, we render the mobile layout or a desktop layout.

Dynamic Layout

As we mentioned above, we created the DynamicLayoutComponent to dynamically render different layouts for our app. This component has a scoped functionality of knowing how to render different layouts. By listening to a Subject that communicates when the screen size changes, this component can render different layouts accordingly.

We also included a LayoutService to enable dispatching layout switching events across the app and also store the current and previous layouts to ease the layout re-rendering mechanism. DynamicLayoutComponent subscribes to the LayoutService Subject in order to react to screen size changes.

The LayoutService is used in the SettingsMenuComponent (which handles the live demo theme switching functionality) and in the root AppComponent where we defined the conditional rendering using the Material CDK BreakpointObserver.

Configurations

Default layout

In the src/app/app-layouts.ts file you will find a list with all the layouts available. There are settings to also, easily, change the default layout.

const defaultLayout: IAppLayout = availableLayouts.find((layout: IAppLayout) => {
  return layout.name === 'C';
});

Remove unused layouts

We included several layout options. However, for your end project you would typically choose your preferred desktop layout and the mobile layout and discard the others.