{"id":3706,"date":"2020-03-17T21:49:05","date_gmt":"2020-03-17T20:49:05","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=3706"},"modified":"2020-03-17T21:49:05","modified_gmt":"2020-03-17T20:49:05","slug":"lazy-loading-locales-with-angular","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/lazy-loading-locales-with-angular\/","title":{"rendered":"Lazy Loading Locales with Angular"},"content":{"rendered":"

Angular 9 introduces a new implementation for its built-in I18N support called code>@angular\/localize<\/code<\/a>. One concept it contains is called global locales. These are bundles with meta data for different date and number formats the CLI can add after<\/strong> compiling the application.<\/p>\n

Normally, the CLI uses these bundles under the hood to dramatically speed up the creation of different language versions. However, we can divert it from its intended use to load the meta data dynamically on demand.<\/p>\n

This article shows how to leverage this. The used example can be found in my GitHub repo<\/a>.<\/p>\n

\nBig thanks to Angular's Pete Bacon Darwin<\/a> who helped me to see the whole picture regarding global locals.\n<\/p><\/blockquote>\n

Situation Before Angular 9<\/h2>\n

Beginning with Angular 5, Angular is shipped with meta data for different locales. It is derived from the Unicode Common Locale Data Repository (CLDR). To support some of them, we had to import and register them before the application starts, e. g. within main.ts<\/code>:<\/p>\n

import { registerLocaleData } from '@angular\/common';\nimport localeDe from '@angular\/common\/locales\/de';\nimport localeDeAt from '@angular\/common\/locales\/de-AT';\nimport localeEs from '@angular\/common\/locales\/es';\n\nregisterLocaleData(localeDe);     \/\/ de-DE\nregisterLocaleData(localeDeAt);   \/\/ de-AT\nregisterLocaleData(localeEs);     \/\/ es-ES\n\n[...]\n\nplatformBrowserDynamic().bootstrapModule(AppModule)\n  .catch(err => console.error(err));<\/code><\/pre>\n
In addition to these locales, en-US<\/code> is always available.<\/p>\n
Obviously, this increases the size of the main bundle as all this meta data is referenced at compile time. As the next chapters show, Angular 9 introduces a way to prevent this situation.<\/p>\n
Global Locales<\/h2>\n
Beginning with version 9, Angular is also providing a special set of bundles registering the locale meta data globally at global.ng.common.locales<\/code>. For instance, in the case of German, the meta data would be put to global.ng.common.locales['de']<\/code>. Hence, they are called global locales.<\/p>\n
These bundles are located within code>node_modules\/@angular\/common\/locales\/global<\/code<\/a>:<\/p>\n
\"global<\/p>\n
Global Locals go hand in hand with the new code>@angular\/localize<\/code<\/a> package which brings the built-in I18N support to the next level. The idea of this package is to only compile the application once. Then, this compiled version is duplicated for each language one wants to support and each of these duplications is modified. <\/p>\n
These modifications involve exchanging texts but also adding the right meta data. For the latter one, we need a way to simply add this meta data after the build. This is what global locals enable.<\/p>\n
Obviously, this approach is much faster than the original one which compiled the whole application once per language<\/strong>.<\/p>\n
Saying this, normally you don't need to deal directly with these global locals<\/strong> because the CLI does the heavy lifting for you. If you want to try it out, you find a wonderful blog post about code>@angular\/localize<\/code<\/a> here<\/a>.<\/p>\n
However<\/strong>, if you don't use code>@angular\/localize<\/code<\/a> do deal with translation texts but go with something like ngx-translate<\/code> instead, directly dealing with global locales will come in handy. This is also the case if you do use code>@angular\/localize<\/code<\/a> but define the translation texts programatically, e. g. after loading them from a custom service in a custom data format (which is called runtime tranlation).<\/p>\n
In these cases, loading just the needed meta data on demand instead of loading the meta data for all languages upfront will improve your startup performance.<\/p>\n
Lazy Loading<\/h2>\n
To demonstrate lazy loading global locals by hand, I've created a simple application which is using en-US<\/code> by default:<\/p>\n
\"example\"<\/p>\n
After clicking the button German Version<\/code>, the German locale meta data is lazy loaded and used. For this, I've created a simple script loader which is basically creating a script<\/code> tag dynamically:<\/p>\n
\/\/\n\/\/ Simplest Possible Script Loader TM\n\/\/\n\n@Injectable({\n  providedIn: 'root'\n})\nexport class SimpleLoaderService {\n\n  constructor() { }\n\n  \/\/ Remeber already loaded files so that we\n  \/\/ don't load it again.\n  private loadedFiles = new Set<string>();\n\n  loadScript(src: string): Promise<void> {\n\n    \/\/ If the file is already loaded don't do anything.\n    if (this.loadedFiles.has(src)) {\n      return Promise.resolve();\n    }\n\n    return new Promise<void>((resolve, reject) => {\n\n      \/\/ Create a script tag and point to java script file\n      const script = document.createElement('script');\n      script.src = src;\n\n      \/\/ Resolve Promise after loading\n      script.onload = () => {\n        this.loadedFiles.add(src);\n        resolve();\n      };\n\n      \/\/ Reject Promise on error\n      script.onerror = () => {\n        reject();\n      };\n\n      \/\/ Add script tag to page\n      document.body.appendChild(script);\n    });\n  }\n\n}<\/code><\/pre>\n
Our demo's AppComponent<\/code> holds a date which happens to be the authors birth day (just saying ...) and a property holding the locale to use:<\/p>\n
@Component({ [...] })\nexport class AppComponent {\n\n  date = new Date('2020-01-20T17:00+01:00');\n  lang = 'en-US';\n\n  constructor(private loader: SimpleLoaderService) {\n  }\n\n  toGerman() {\n    this.loader\n        .loadScript('assets\/de.js')\n        .then(_ => this.lang = 'de-DE')\n        .catch(err => console.error('Error loading file', err));\n  }\n\n}<\/code><\/pre>\n
The template displays this date as shown above:<\/p>\n
{{ date | date:'long':'':lang }}<\/code><\/pre>\n
The method toGerman<\/code> is bound to the shown button and uses our SimpleLoaderService<\/code> to load the German<\/code> locale. After that, it updates the lang<\/code> property.<\/p>\n
Testing the Application<\/h2>\n
To demonstrate that lazy loading really takes happen, you can open Chrome's network tab within the dev tools and click German Version<\/code> within the page. You should see that this lazy loads the assets\/de.js<\/code> file. Also, you should now see a German date.<\/p>\n
\"Lazy<\/p>\n
Conclusion<\/h2>\n
If you fully go with code>@angular\/localize<\/code<\/a> and compile time translation, you don't need to concentrate on gobal locals. But if you use other tools for loading translation texts or runtime translation, loading the meta data on demand will come in handy. This is especially the case if you use solutions like ngx-translate<\/code> which allow to switch between languages at runtime.<\/p>\n
<\/p>\n
References<\/h2>\n