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.
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.
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.
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.
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.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.
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.
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.
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.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.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';
});
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.
Last modified 3yr ago