Server side rendering is becoming more popular and widespread. In theory, according to the Angular documentation, we run a command, pay attention to a few things, and it’s done – it turns out that it’s not so simple and easy in practice. In this article, I will try to look into zones and problems that some of you may encounter. The solution isn’t so trivial moreover finding the answer on the Internet may sometimes even be impossible.
In the first part, we will look at the problem of the window object at the stage of the building, we will be interested in guards and blocking access to the application on the server side, for example in case of lack of information about the authorization. In the next part, we will take a look at the initial state problems, we will find out how to get rid of double loaded animations, we will learn how to pass information between client and server applications and how to deal with CSS controlled from the code level e.g. by media query and we will take a look at the request object. Let’s go!
“After all, I have a window mockup, why doesn’t it work”. – problems at the stage of application building.
As it is commonly known we don’t have a browser on the server side so we don’t have a window object for example – obvious, but not always. Sometimes problems with libraries occur, which can’t be solved by window mockups such as Hammer.js or animate-css-grid.
For Example:
A simple hammer configuration service:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
import { Injectable } from '@angular/core'; import { HammerGestureConfig } from '@angular/platform-browser'; import * as Hammer from 'hammerjs'; @Injectable() export class HammerConfig extends HammerGestureConfig{ overrides = { swipe: { direction: Hammer.DIRECTION_ALL } }; } |
So what can go wrong, after all, there is no window object here. We run the application build, and the console says:
|
1 2 3 4 |
(window, document, 'Hammer'); ^ ReferenceError: window is not defined |
The first thought – there is no window object, I forgot to mock it up. Check our server.ts – everything is in place, domino effectively fixes our window. It’s hard to find solutions on google, which don’t require interference with webpack or even the source code of the library. However, it can be fixed:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
@Injectable() export class HammerConfig extends HammerGestureConfig { hammer: any; overrides = { swipe: { direction: 30 } }; constructor() { super(); this.getHammer().then(_=>console.log('Hammer ready')); } async getHammer(): Promise<any> { if (typeof window !== undefined) { // conditional include because window is undefined on build this.hammer = await import( /* webpackPrefetch: true */ 'hammerjs' ); } } |
This solution allows loading required libraries on demand. We check whether our window is available in the code and then we load the library. It seems simple, but it can cause problems. I also invite you to read the article, which describes how you can use this solution to lazy load components and what use does the comment above has.
“How do I know that I’m authorized” – server-side guards and excluding paths from SSR:
Another problem you may run into is excluding a path from needing SSR. For example – a part of the application requires authorization, it can’t be done on the server side. We need a browser object in our component e.g. storage. There are several solutions to this problem, but in my opinion, none of them give 100% satisfactory results.
The first approach is to use our server and in case of references to specific paths simply return index.html e.g:
|
1 |
app.get('/auth-path/**', (req, res) => { res.sendFile(join(DIST_FOLDER, 'browser', 'index.html')); }); |
In my case, this idea didn’t work at all, mainly because all paths in the index.html file have to be absolute, so it requires path modification in this file or experimenting with rendering.
The second approach is to expose two applications – one served by SSR and the other one served in the traditional way, as a result, the traffic is being managed rightly. This idea is also very average, if not bad.
If you decide to use any of the solutions above, you need to take into account one more problem – what if there is a requirement for routing translation? Then, you’d have to do a proper redirection for each path, multiplied by the number of supported translations, which discredits both ideas even more.
Not ideal, but in my opinion, the simplest and probably the least invasive way is the following one. It also has one major disadvantage, which I will mention later. But back to the point – why not redirect the user to a temporary page which will redirect us to the right place after rendering the application? For Example:
1. We create a temporary page/component that the user will see. It will be a SsrRedirectComponent:
|
1 2 3 4 5 6 7 |
@Component({ selector: 'app-ssr-redirect', template: `<h1>Waiting for initialization!</h1>`, changeDetection: ChangeDetectionStrategy.OnPush }) export class SsrRedirectComponent{ } |
2. Next, let’s create a guard that will only work on the server-side and will redirect us to a properly defined path:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
@Injectable({ providedIn: 'root' }) export class SsrRedirectGuard implements CanActivate { constructor(@Inject(PLATFORM_ID) private readonly platformId: unknown, private readonly router: Router) { } canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): boolean | UrlTree { if (isPlatformServer(this.platformId)) { return this.router.parseUrl(`/${ROUTE_SLUGS.ssrAuth}`); } return true; } } |
App.-routing.module
|
1 2 3 |
const routes: Routes = [... { path: ROUTE_SLUGS.ssrAuth, component: SsrRedirectComponent } ...] |
3. The guard above will redirect the server-side version of our application to our temporary component, however, it will not change the routing, so that when the application loads in the browser, the user will not stay on our temporary page but will be redirected to the landing page.
|
1 2 3 4 |
const routes: Routes = [... { path: ROUTE_SLUGS.ssrAuth, component: SsrRedirectComponent }, { path: ROUTE_SLUGS.protectedPath, component: ProtectedComponent, canActivate:[SsrRedirectGuard, AuthGuard]} ...] |
We can display at least the loader on our temporary component and the user will not realize that he/she finds himself/herself in a kind of a waiting room, especially because he/she will see the destination address in the address bar of the browser, and in the meantime, the application will do its job and either let us in or redirect us to the login page or display the appropriate popup. Well, it will display it or it won’t display it, but we will talk about it in the second part of this article.
Summary
Let’s summarize what we found out today. Firstly – how to deal with the problem of missing objects in third-party libraries at the stage of building the application without interfering in their code. Secondly, we learned how to easily exclude paths from Server Side Rendering or how to deal with authorization. What next? I invite you to read the next article soon.
Leave a Reply