Strings Best Practice in Angular 2

Question

I've been learning Angular 2, and wondering what is regarded best practice for storing strings. I use various strings throughout the application: Some are placed directly in HTML elements, e.g.,

// sample.html
<h1>This is my title</h1>

other strings are stored in component models that are bound to, e.g.,

// boundSample.html
<h1>{{myTitle}}</h1>

// boundSample.component.ts
import ...

@Component({
   templateUrl: 'boundSample.html';
})
export class BoundSampleComponent {
  myTitle = 'This is another title';
}

My concern is that my strings are spread throughout the application. Coming from a C#/WPF background, I'm use to keeping my strings in a single location (e.g. strings.xaml) that I can import into code and UI markup (i.e. XAML for WPF, HTML for Angular). This greatly helps with maintainability and internationalization.

Furthermore, a quick look at internationalization in angular 2 suggests using the i18n attribute and the i18n tool. This assumes that all my strings are defined in HTML, but what if I want to use some of those strings in code...

How and where can I define a single location for my strings in Angular2 such that I can access those strings in code and make use of the internationalization tools?

Answer 1

You can search for some tools, some of them are good and already implement the things you want to have. However if you want to do it the way you used to, just do the following:

1. Store the strings in the XAML / JSON / YAML / etc file where you store your strings. If you use webpack, use the proper loader which handles the stuff for you. If not, you would need to parse this file on your own.

2. Create a service which is able to get the info from file (in the constructor I guess) and has a function which returns you the string based on the string token.

3. Create a pipe which returns a string based on token.

4. Use the pipe in HTML and the service in the typescript files.

i18n - no problem, just pass the language to the service function / subscribe to the language-change observable in the service.

The implementation is trivial. But think twice: you can use already existing solutions.