build: Use prettier for markdown
Stop ignoring .md files in prettier and fix existing issues.
This commit is contained in:
Ralph Hopman
@@ -2,4 +2,3 @@
|
||||
|
||||
This project does not come with any analytics library.
|
||||
Should you decide to use one, you may want to consider [Angulartics2](https://github.com/angulartics/angulartics2).
|
||||
|
||||
|
||||
@@ -14,11 +14,12 @@ we also have setup a backend proxy to redirect API calls to whatever URL and por
|
||||
In the root folder you will find a `proxy.conf.js`, containing the backend proxy configuration.
|
||||
|
||||
The interesting part is there:
|
||||
|
||||
```js
|
||||
const proxyConfig = [
|
||||
{
|
||||
context: '/api',
|
||||
pathRewrite: {'^/api': ''},
|
||||
pathRewrite: { '^/api': '' },
|
||||
target: 'http://api.icndb.com',
|
||||
changeOrigin: true
|
||||
}
|
||||
@@ -33,7 +34,7 @@ For the complete set of options, see the `http-proxy-middleware`
|
||||
### Corporate proxy support
|
||||
|
||||
To allow external API calls redirection through a corporate proxy, you will also find a `setupForCorporateProxy()`
|
||||
function in the proxy configuration file. By default, this method configures a corporate proxy agent based on the
|
||||
function in the proxy configuration file. By default, this method configures a corporate proxy agent based on the
|
||||
`HTTP_PROXY` environment variable, see the [corporate proxy documentation](corporate-proxy.md) for more details.
|
||||
|
||||
If you need to, you can further customize this function to fit the network of your working environment.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
[Angular](https://angular.io) (aka Angular 2, 4, 5, 6...) is a new framework completely rewritten from the ground up,
|
||||
replacing the now well-known [AngularJS](https://angularjs.org) framework (aka Angular 1.x).
|
||||
|
||||
More that just a framework, Angular should now be considered as a whole *platform* which comes with a complete set of
|
||||
More that just a framework, Angular should now be considered as a whole _platform_ which comes with a complete set of
|
||||
tools, like its own [CLI](https://github.com/angular/angular-cli), [debug utilities](https://augury.angular.io) or
|
||||
[performance tools](https://github.com/angular/angular/tree/master/packages/benchpress).
|
||||
|
||||
@@ -48,37 +48,37 @@ like [reactive programming](#reactive-programming), [unidirectional data flow](#
|
||||
These concepts are difficult to resume in a few words, and despite being tightly related to each other they concern
|
||||
specific parts of an application flow, each being quite deep to learn on its own.
|
||||
|
||||
You will essentially find here a list of good starting points to learn more on these subjects.
|
||||
You will essentially find here a list of good starting points to learn more on these subjects.
|
||||
|
||||
#### Reactive programming
|
||||
|
||||
You may not be aware of it, but Angular is now a *reactive system* by design.
|
||||
You may not be aware of it, but Angular is now a _reactive system_ by design.
|
||||
Although you are not forced to use reactive programming patterns, they make the core of the framework and it is
|
||||
definitely recommended to learn them if you want to leverage the best of Angular.
|
||||
|
||||
Angular uses [RxJS](http://reactivex.io/rxjs/) to implement the *Observable* pattern.
|
||||
Angular uses [RxJS](http://reactivex.io/rxjs/) to implement the _Observable_ pattern.
|
||||
|
||||
> An *Observable* is a stream of asynchronous events that can be processed with array-like operators.
|
||||
> An _Observable_ is a stream of asynchronous events that can be processed with array-like operators.
|
||||
|
||||
##### From promises to observables
|
||||
|
||||
While AngularJS used to rely heavily on [*Promises*](https://docs.angularjs.org/api/ng/service/$q) to handle
|
||||
asynchronous events, *Observables* are now used instead in Angular. Even though in specific cases like for HTTP
|
||||
requests, an *Observable* can be converted into a *Promise*, it is recommended to embrace the new paradigm as it can a
|
||||
lot more than *Promises*, with way less code. This transition is also explained in the
|
||||
While AngularJS used to rely heavily on [_Promises_](https://docs.angularjs.org/api/ng/service/$q) to handle
|
||||
asynchronous events, _Observables_ are now used instead in Angular. Even though in specific cases like for HTTP
|
||||
requests, an _Observable_ can be converted into a _Promise_, it is recommended to embrace the new paradigm as it can a
|
||||
lot more than _Promises_, with way less code. This transition is also explained in the
|
||||
[Angular tutorial](https://angular.io/tutorial/toh-pt6#!%23observables).
|
||||
Once you have made the switch, you will never look back again.
|
||||
|
||||
##### Learning references
|
||||
|
||||
|
||||
- [What is reactive programming?](http://paulstovell.com/blog/reactive-programming), explained nicely through a simple
|
||||
imaged story *(5 min)*
|
||||
imaged story _(5 min)_
|
||||
|
||||
- [The introduction to reactive programming you've been missing](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754),
|
||||
the title says it all *(30 min)*
|
||||
the title says it all _(30 min)_
|
||||
|
||||
- [Functional reactive programming for Angular 2 developers](http://blog.angular-university.io/functional-reactive-programming-for-angular-2-developers-rxjs-and-observables/),
|
||||
see the functional reactive programming principles in practice with Angular *(15 min)*
|
||||
see the functional reactive programming principles in practice with Angular _(15 min)_
|
||||
|
||||
- [RxMarbles](http://rxmarbles.com), a graphical representation of Rx operators that greatly help to understand their
|
||||
usage
|
||||
@@ -95,13 +95,13 @@ with substantial performance improvements.
|
||||
**Wait, then why the Angular documentation have mention of a
|
||||
[two-way binding syntax](https://angular.io/guide/template-syntax#binding-syntax-an-overview)?**
|
||||
|
||||
If you look closely, the new two-way binding syntax is just syntactic sugar to combine two *one-way* bindings (a
|
||||
*property* and *event* binding), keeping the data flow unidirectional.
|
||||
If you look closely, the new two-way binding syntax is just syntactic sugar to combine two _one-way_ bindings (a
|
||||
_property_ and _event_ binding), keeping the data flow unidirectional.
|
||||
|
||||
This change is really important, as it was often the cause of performance issues with AngularJS, and it one of the
|
||||
pillars enabling better performance in new Angular apps.
|
||||
|
||||
While Angular tries to stay *pattern-agnostic* and can be used with conventional MV* patterns, it was designed with
|
||||
While Angular tries to stay _pattern-agnostic_ and can be used with conventional MV\* patterns, it was designed with
|
||||
reactive programming in mind and really shines when used with reactive data flow patterns like
|
||||
[redux](http://redux.js.org/docs/basics/DataFlow.html),
|
||||
[Flux](https://facebook.github.io/flux/docs/in-depth-overview.html#content) or
|
||||
@@ -112,25 +112,25 @@ reactive programming in mind and really shines when used with reactive data flow
|
||||
As applications grow in size, keeping track of the all its individual components state and data flows can become
|
||||
tedious, and tend to be difficult to manage and debug.
|
||||
|
||||
The main goal of using a centralized state management is to make state changes *predictable* by imposing certain
|
||||
restrictions on how and when updates can happen, using *unidirectional data flow*.
|
||||
The main goal of using a centralized state management is to make state changes _predictable_ by imposing certain
|
||||
restrictions on how and when updates can happen, using _unidirectional data flow_.
|
||||
|
||||
This approach was first made popular with React with introduction of the
|
||||
[Flux](https://facebook.github.io/flux/docs/in-depth-overview.html#content) architecture. Many libraries emerged then
|
||||
trying to adapt and refine the original concept, and one of these gained massive popularity by providing a simpler,
|
||||
elegant alternative: [Redux](http://redux.js.org/docs/basics/DataFlow.html).
|
||||
|
||||
Redux is at the same time a library (with the big *R*) and a design pattern (with the little *r*), the latter being
|
||||
Redux is at the same time a library (with the big _R_) and a design pattern (with the little _r_), the latter being
|
||||
framework-agnostic and working very well with Angular.
|
||||
|
||||
The *redux* design pattern is based on these [3 principles](http://redux.js.org/docs/introduction/ThreePrinciples.html):
|
||||
The _redux_ design pattern is based on these [3 principles](http://redux.js.org/docs/introduction/ThreePrinciples.html):
|
||||
|
||||
- The application state is a *single immutable* data structure
|
||||
- A state change is triggered by an *action*, an object describing what happened
|
||||
- Pure functions called *reducers* take the previous state and the next action to compute the new state
|
||||
- The application state is a _single immutable_ data structure
|
||||
- A state change is triggered by an _action_, an object describing what happened
|
||||
- Pure functions called _reducers_ take the previous state and the next action to compute the new state
|
||||
|
||||
The core concepts behind these principles are nicely explained in
|
||||
[this example](http://redux.js.org/docs/introduction/CoreConcepts.html) *(3 min)*.
|
||||
[this example](http://redux.js.org/docs/introduction/CoreConcepts.html) _(3 min)_.
|
||||
|
||||
##### Which library to use?
|
||||
|
||||
@@ -142,10 +142,10 @@ utilities.
|
||||
Here are some resources to get started:
|
||||
|
||||
- [Build a better Angular 2 application with redux and ngrx](http://onehungrymind.com/build-better-angular-2-application-redux-ngrx/),
|
||||
a nice tutorial for @ngrx/store *(30 min)*
|
||||
a nice tutorial for @ngrx/store _(30 min)_
|
||||
|
||||
- [Comprehensive introduction to @ngrx/store](https://gist.github.com/btroncone/a6e4347326749f938510), an in-depth
|
||||
walkthrough to this library usage in Angular *(60 min)*
|
||||
walkthrough to this library usage in Angular _(60 min)_
|
||||
|
||||
##### When to use it?
|
||||
|
||||
|
||||
@@ -18,15 +18,15 @@ These tests use [Protractor](https://github.com/angular/protractor), which is a
|
||||
|
||||
## Page objects
|
||||
|
||||
E2E tests should follow the *[Page Object](https://github.com/SeleniumHQ/selenium/wiki/PageObjects)* pattern.
|
||||
E2E tests should follow the _[Page Object](https://github.com/SeleniumHQ/selenium/wiki/PageObjects)_ pattern.
|
||||
|
||||
#### What is a page object?
|
||||
|
||||
A page object:
|
||||
|
||||
- Models the objects on a page under test:
|
||||
* *Properties* wrap page elements
|
||||
* *Methods* wrap code that interacts with the page elements
|
||||
- _Properties_ wrap page elements
|
||||
- _Methods_ wrap code that interacts with the page elements
|
||||
- Simplifies the test scripts
|
||||
- Reduces the amount of duplicated code
|
||||
|
||||
@@ -43,11 +43,11 @@ export class LoginPage {
|
||||
passwordInput = element(by.css('input[name=^"password"]'));
|
||||
loginButton = element(by.css('button[(click)^="login"]'));
|
||||
registerButton = element(by.css('button[(click)^="register"]'));
|
||||
|
||||
|
||||
navigateTo() {
|
||||
return browser.get('/');
|
||||
}
|
||||
|
||||
|
||||
getGreetingText() {
|
||||
return element(by.css('.greeting')).getText();
|
||||
}
|
||||
@@ -61,19 +61,19 @@ export class LoginPage {
|
||||
import { LoginPage } from './login.po';
|
||||
|
||||
describe('Login', () => {
|
||||
let page: LoginPage ;
|
||||
let page: LoginPage;
|
||||
|
||||
beforeEach(() => {
|
||||
page = new LoginPage();
|
||||
page.navigateTo();
|
||||
});
|
||||
|
||||
|
||||
it('should navigate to the register page when the register button is clicked', () => {
|
||||
page.registerButton.click();
|
||||
|
||||
|
||||
expect(browser.getCurrentUrl()).toContain('/register');
|
||||
});
|
||||
|
||||
|
||||
it('should allow a user to log in', () => {
|
||||
page.emailInput.sendKeys('test@mail.com');
|
||||
page.passwordInput.sendKeys('abc123');
|
||||
@@ -86,5 +86,5 @@ describe('Login', () => {
|
||||
|
||||
## Credits
|
||||
|
||||
Parts of this guide were freely inspired by this
|
||||
Parts of this guide were freely inspired by this
|
||||
[presentation](https://docs.google.com/presentation/d/1B6manhG0zEXkC-H-tPo2vwU06JhL8w9-XCF9oehXzAQ).
|
||||
|
||||
@@ -13,8 +13,8 @@
|
||||
- Use double quotes `"` around attribute values in tags
|
||||
- Use a new line for every block, list, or table element, and indent every such child element
|
||||
- Clearly Separate structure (HTML) from presentation (CSS) from behavior (JavaScript):
|
||||
* Never use inline CSS or JavaScript
|
||||
* Keep any logic out of the HTML
|
||||
- Never use inline CSS or JavaScript
|
||||
- Keep any logic out of the HTML
|
||||
- `type` attribute for stylesheets and script tags should be omitted
|
||||
|
||||
## Common pitfalls
|
||||
@@ -22,11 +22,11 @@
|
||||
- **Block**-type tags cannot be nested inside **inline**-type tags: a `<div>` tag cannot be nested in a `<span>`.
|
||||
This rule also applies regarding the `display` value of an element.
|
||||
- HTML is **not** XML: empty tags cannot be self-closing and will result in improper results
|
||||
* `<div/>` will be interpreted as a simple `<div>` without closing tag!
|
||||
* The only tags that allows self-closing are the one that does not require a closing tag in first place:
|
||||
- `<div/>` will be interpreted as a simple `<div>` without closing tag!
|
||||
- The only tags that allows self-closing are the one that does not require a closing tag in first place:
|
||||
these are the void elements that do not not accept content `<br>`, `<hr>`, `<img>`, `<input>`, `<meta>`, `<link>`
|
||||
(and others).
|
||||
|
||||
|
||||
## Templates
|
||||
|
||||
In accordance with the [Angular style guide](https://angular.io/guide/styleguide), HTML templates should be extracted in
|
||||
@@ -37,4 +37,3 @@ Only use inline templates sparingly in very simple components with less than 3 l
|
||||
## Enforcement
|
||||
|
||||
Coding rules enforcement and basic sanity checks are done in this project by [HTMLHint](http://htmlhint.com).
|
||||
|
||||
|
||||
+27
-24
@@ -3,11 +3,11 @@
|
||||
[Sass](http://sass-lang.com) is a superset of CSS, which brings a lot of developer candy to help scaling CSS in large
|
||||
projects and keeping it maintainable.
|
||||
|
||||
The main benefits of using Sass over plain CSS are *variables*, *nesting* and *mixins*, see the
|
||||
The main benefits of using Sass over plain CSS are _variables_, _nesting_ and _mixins_, see the
|
||||
[basics guide](http://sass-lang.com/guide) for more details.
|
||||
|
||||
> Note that this project use the newer, CSS-compatible **SCSS** syntax over the old
|
||||
[indented syntax](http://sass-lang.com/documentation/file.INDENTED_SYNTAX.html).
|
||||
> [indented syntax](http://sass-lang.com/documentation/file.INDENTED_SYNTAX.html).
|
||||
|
||||
## Naming conventions
|
||||
|
||||
@@ -18,6 +18,7 @@ The main benefits of using Sass over plain CSS are *variables*, *nesting* and *m
|
||||
|
||||
- Use single quotes `'` for strings
|
||||
- Use this general nesting hierarchy when constructing your styles:
|
||||
|
||||
```scss
|
||||
// The base component class acts as the namespace, to avoid naming and style collisions
|
||||
.my-component {
|
||||
@@ -28,16 +29,17 @@ The main benefits of using Sass over plain CSS are *variables*, *nesting* and *m
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Note that with
|
||||
[Angular view encapsulation](https://angular.io/docs/ts/latest/guide/component-styles.html#!#view-encapsulation),
|
||||
the first "namespace" level of nesting is not necessary as Angular takes care of the scoping for avoid collisions.
|
||||
|
||||
|
||||
> As a side note, we are aware of the [BEM naming approach](https://en.bem.info/tools/bem/bem-naming/), but we found
|
||||
it impractical for large projects. The nesting approach has drawbacks such as increased specificity, but it helps
|
||||
keeping everything nicely organized, and more importantly, *scoped*.
|
||||
|
||||
> it impractical for large projects. The nesting approach has drawbacks such as increased specificity, but it helps
|
||||
> keeping everything nicely organized, and more importantly, _scoped_.
|
||||
|
||||
Also keep in mind this general rules:
|
||||
|
||||
- Always use **class selectors**, never use ID selectors and avoid element selectors whenever possible
|
||||
- No more than **3 levels** of nesting
|
||||
- No more than **3 qualifiers**
|
||||
@@ -45,43 +47,44 @@ Also keep in mind this general rules:
|
||||
## Best practices
|
||||
|
||||
- Use object-oriented CSS (OOCSS):
|
||||
* Factorize common code in base class, and extend it, for example:
|
||||
|
||||
- Factorize common code in base class, and extend it, for example:
|
||||
|
||||
```scss
|
||||
// Base button class
|
||||
.btn { ... }
|
||||
|
||||
|
||||
// Color variation
|
||||
.btn-warning { ... }
|
||||
|
||||
|
||||
// Size variation
|
||||
.btn-small { ... }
|
||||
```
|
||||
* Try to name class by semantic, not style nor function for better reusability:
|
||||
|
||||
- Try to name class by semantic, not style nor function for better reusability:
|
||||
Use `.btn-warning`, not `btn-orange` nor `btn-cancel`
|
||||
* Avoid undoing style, refactor using common base classes and extensions
|
||||
- Avoid undoing style, refactor using common base classes and extensions
|
||||
|
||||
- Keep your style scoped
|
||||
* Clearly separate **global** (think *framework*) and **components** style
|
||||
* Global style should only go in `src/theme/`, never in components
|
||||
* Avoid style interactions between components, if some style may need to be shared, refactor it as a framework
|
||||
- Clearly separate **global** (think _framework_) and **components** style
|
||||
- Global style should only go in `src/theme/`, never in components
|
||||
- Avoid style interactions between components, if some style may need to be shared, refactor it as a framework
|
||||
component in put it in your global theme.
|
||||
* Avoid using wider selectors than needed: always use classes if you can!
|
||||
|
||||
- Avoid using wider selectors than needed: always use classes if you can!
|
||||
- Avoid rules multiplication
|
||||
* The less CSS the better, factorize rules whenever it's possible
|
||||
* CSS is code, and like any code frequent refactoring is healthy
|
||||
|
||||
- The less CSS the better, factorize rules whenever it's possible
|
||||
- CSS is code, and like any code frequent refactoring is healthy
|
||||
- When ugly hacks cannot be avoided, create an explicit `src/hacks.scss` file and put it in:
|
||||
* These ugly hacks should only be **temporary**
|
||||
* Each hack should be documented with the author name, the problem and hack reason
|
||||
* Limit this file to a reasonable length (~100 lines) and refactor hacks with proper solutions when the limit is
|
||||
- These ugly hacks should only be **temporary**
|
||||
- Each hack should be documented with the author name, the problem and hack reason
|
||||
- Limit this file to a reasonable length (~100 lines) and refactor hacks with proper solutions when the limit is
|
||||
reached.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Never use the `!important` keyword. Ever.
|
||||
- Never use **inline** style in html, even *just for debugging* (because we **KNOW** it will end up in your commit)
|
||||
|
||||
- Never use **inline** style in html, even _just for debugging_ (because we **KNOW** it will end up in your commit)
|
||||
|
||||
## Browser compatibility
|
||||
|
||||
You should never use browser-specific prefixes in your code, as [autoprefixer](https://github.com/postcss/autoprefixer)
|
||||
|
||||
@@ -23,14 +23,14 @@ In addition, this project also follows the general [Angular style guide](https:/
|
||||
|
||||
- Within a file, type definitions should come first
|
||||
- Within a class, these priorities should be respected:
|
||||
* Properties comes before functions
|
||||
* Static symbols comes before instance symbols
|
||||
* Public symbols comes before private symbols
|
||||
- Properties comes before functions
|
||||
- Static symbols comes before instance symbols
|
||||
- Public symbols comes before private symbols
|
||||
|
||||
## Coding rules
|
||||
|
||||
- Use single quotes `'` for strings
|
||||
- Always use strict equality checks: `===` and `!==` instead of `==` or `!=` to avoid comparison pitfalls (see
|
||||
- Always use strict equality checks: `===` and `!==` instead of `==` or `!=` to avoid comparison pitfalls (see
|
||||
[JavaScript equality table](https://dorey.github.io/JavaScript-Equality-Table/)).
|
||||
The only accepted usage for `==` is when you want to check a value against `null` or `undefined`.
|
||||
- Use `[]` instead of `Array` constructor
|
||||
@@ -39,11 +39,11 @@ In addition, this project also follows the general [Angular style guide](https:/
|
||||
- Do not export types/functions unless you need to share it across multiple components
|
||||
- Do not introduce new types/values to the global namespace
|
||||
- Use arrow functions over anonymous function expressions
|
||||
- Only surround arrow function parameters when necessary.
|
||||
- Only surround arrow function parameters when necessary.
|
||||
For example, `(x) => x + x` is wrong but the following are correct:
|
||||
* `x => x + x`
|
||||
* `(x, y) => x + y`
|
||||
* `<T>(x: T, y: T) => x === y`
|
||||
- `x => x + x`
|
||||
- `(x, y) => x + y`
|
||||
- `<T>(x: T, y: T) => x === y`
|
||||
|
||||
## Definitions
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Unit tests coding guide
|
||||
|
||||
The main objective of unit tests is to detect regressions and to help you design software components. A suite of
|
||||
*good* unit tests can be *immensely* valuable for your project and makes it easier to refactor and expand your code.
|
||||
But keep in mind that a suite of *bad* unit tests can also be *immensely* painful, and hurt your development by
|
||||
_good_ unit tests can be _immensely_ valuable for your project and makes it easier to refactor and expand your code.
|
||||
But keep in mind that a suite of _bad_ unit tests can also be _immensely_ painful, and hurt your development by
|
||||
inhibiting your ability to refactor or alter your code in any way.
|
||||
|
||||
## What to test?
|
||||
@@ -25,12 +25,12 @@ integration and interactions with other app components based on real use cases s
|
||||
- Test only one code unit at a time: if you cannot do this, it means you have an architecture problem in your app
|
||||
- Mock out all external dependencies and state: if there is too much to mock, it is often a sign that maybe you
|
||||
should split your tested module into several more independent modules
|
||||
- Clearly separate or identify these 3 stages of each unit test (the *3A*): *arrange*, *act* and *assert*
|
||||
- Clearly separate or identify these 3 stages of each unit test (the _3A_): _arrange_, _act_ and _assert_
|
||||
- When you fix a bug, add a test case for it to prevent regression
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Sometimes your architecture might mean your code modify static variables during unit tests. Avoid this if you can,
|
||||
- Sometimes your architecture might mean your code modify static variables during unit tests. Avoid this if you can,
|
||||
but if you can't, at least make sure each test resets the relevant statics before and after your tests.
|
||||
- Don’t unit-test configuration settings
|
||||
- Improving test coverage is good, but having meaningful tests is better: start with the latter first, and **only after
|
||||
|
||||
@@ -15,6 +15,7 @@ In Windows environments, add the `HTTP_PROXY` and `HTTPS_PROXY` system environme
|
||||
### Unix
|
||||
|
||||
Add these lines to your `~/.bash_profile` or `~/.profile`:
|
||||
|
||||
```sh
|
||||
export HTTP_PROXY="http://<username>:<password>@<proxy_server>:<proxy_port>"
|
||||
export HTTPS_PROXY="$HTTP_PROXY"
|
||||
@@ -44,6 +45,7 @@ export NO_PROXY="127.0.0.1, localhost, <your_local_server_ip_or_hostname>"
|
||||
### Npm
|
||||
|
||||
Run this command in your project directory:
|
||||
|
||||
```sh
|
||||
npm set strict-ssl false
|
||||
```
|
||||
|
||||
+16
-12
@@ -7,11 +7,13 @@ The internationalization of the application is managed by [ngx-translate](https:
|
||||
### In HTML templates
|
||||
|
||||
Use the `translate` directive on an HTML element to automatically translate its content:
|
||||
|
||||
```html
|
||||
<span translate>This text will be translated.</span>
|
||||
```
|
||||
|
||||
You can also use the `translate` pipe if needed:
|
||||
|
||||
```html
|
||||
<button title="{{'Add item' | translate}}">+</button>
|
||||
```
|
||||
@@ -23,7 +25,9 @@ If you need to translate strings in JavaScript code, import the `TranslateServic
|
||||
|
||||
```typescript
|
||||
let title;
|
||||
translateService.get('My page title').subscribe((res: string) => { title = res; });
|
||||
translateService.get('My page title').subscribe((res: string) => {
|
||||
title = res;
|
||||
});
|
||||
```
|
||||
|
||||
or `TranslateService` dependency and use the asynchronous
|
||||
@@ -46,16 +50,16 @@ Do no forget to edit the files in `src/environment` to add the supported languag
|
||||
These are the Language available now:
|
||||
|
||||
| Language | Code | File |
|
||||
|:----------:|:----:|:----------:|
|
||||
| Czech | cs | cs-CS.json |
|
||||
| German | de | de-DE.json |
|
||||
| English | en | en-US.json |
|
||||
| Spanish | es | es-MX.json |
|
||||
| French | fr | fr-FR.json |
|
||||
| Italian | it | it-IT.json |
|
||||
| Korean | ko | ko-KO.json |
|
||||
| :--------: | :--: | :--------: |
|
||||
| Czech | cs | cs-CS.json |
|
||||
| German | de | de-DE.json |
|
||||
| English | en | en-US.json |
|
||||
| Spanish | es | es-MX.json |
|
||||
| French | fr | fr-FR.json |
|
||||
| Italian | it | it-IT.json |
|
||||
| Korean | ko | ko-KO.json |
|
||||
| Lithuanian | li | li-LI.json |
|
||||
| Latvian | lv | lv-LV.json |
|
||||
| Nepali | ne | ne-NE.json |
|
||||
| Latvian | lv | lv-LV.json |
|
||||
| Nepali | ne | ne-NE.json |
|
||||
| Portuguese | pt | pt-PT.json |
|
||||
| Swahili | sw | sw-SW.json |
|
||||
| Swahili | sw | sw-SW.json |
|
||||
|
||||
+10
-11
@@ -2,10 +2,10 @@
|
||||
|
||||
To allow navigation without triggering a server request, Angular now use by default the
|
||||
[HTML5 pushState](https://developer.mozilla.org/en-US/docs/Web/API/History_API#Adding_and_modifying_history_entries)
|
||||
API enabling natural URL style (like `localhost:4200/home/`), in opposition to Angular 1 which used the *hashbang* hack
|
||||
routing style (like `localhost:4200/#/home/`).
|
||||
API enabling natural URL style (like `localhost:4200/home/`), in opposition to Angular 1 which used the _hashbang_ hack
|
||||
routing style (like `localhost:4200/#/home/`).
|
||||
|
||||
This change has several consequences you should know of, be sure to read the
|
||||
This change has several consequences you should know of, be sure to read the
|
||||
[browser URL styles](https://angular.io/docs/ts/latest/guide/router.html#!#browser-url-styles) notice to fully
|
||||
understand the differences between the two approaches.
|
||||
|
||||
@@ -13,8 +13,7 @@ In short:
|
||||
|
||||
- It is only supported on modern browsers (IE10+), a [polyfill](https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills#html5-history-api-pushstate-replacestate-popstate)
|
||||
is required for older browsers.
|
||||
|
||||
- You have the option to perform *server-side rendering* later if you need to increase your app perceived performance.
|
||||
- You have the option to perform _server-side rendering_ later if you need to increase your app perceived performance.
|
||||
|
||||
- You need to [configure URL rewriting](#server-configuration) on your server so that all routes serve your index file.
|
||||
|
||||
@@ -23,9 +22,9 @@ default HTML5 routing mode.
|
||||
|
||||
## Server configuration
|
||||
|
||||
To allow your angular application working properly as a *Single Page Application* (SPA) and allow bookmarking or
|
||||
To allow your angular application working properly as a _Single Page Application_ (SPA) and allow bookmarking or
|
||||
refreshing any page, you need some configuration on your server, otherwise you will be running into troubles.
|
||||
|
||||
|
||||
> Note that during development, the live reload server already supports SPA mode.
|
||||
|
||||
The basic idea is simply to serve the `index.html` file for every request aimed at your application.
|
||||
@@ -33,11 +32,11 @@ The basic idea is simply to serve the `index.html` file for every request aimed
|
||||
Here is an example on how to perform this on an [Express](http://expressjs.com) NodeJS server:
|
||||
|
||||
```js
|
||||
// Put this in your `server.js` file, after your other rules (APIs, static files...)
|
||||
app.get('/*', function(req, res) {
|
||||
res.sendFile(__dirname + '/index.html')
|
||||
// Put this in your `server.js` file, after your other rules (APIs, static files...)
|
||||
app.get('/*', function (req, res) {
|
||||
res.sendFile(__dirname + '/index.html');
|
||||
});
|
||||
```
|
||||
|
||||
For other servers like [Nginx](https://www.nginx.com/blog/creating-nginx-rewrite-rules/) or
|
||||
[Apache](http://httpd.apache.org/docs/2.0/misc/rewriteguide.html), you may look for how to perform *URL rewriting*.
|
||||
[Apache](http://httpd.apache.org/docs/2.0/misc/rewriteguide.html), you may look for how to perform _URL rewriting_.
|
||||
|
||||
+6
-1
@@ -1,21 +1,25 @@
|
||||
# Updating npm dependencies
|
||||
|
||||
- Check outdated packages
|
||||
|
||||
```sh
|
||||
npm outdated
|
||||
```
|
||||
|
||||
- Update local packages according to `package.json`
|
||||
|
||||
```sh
|
||||
npm update
|
||||
```
|
||||
|
||||
- Upgrade packages manually
|
||||
|
||||
```sh
|
||||
npm install --save[-dev] <package_name>@latest
|
||||
```
|
||||
|
||||
Alternatively, you can use [npm-check](https://github.com/dylang/npm-check) to perform an interactive upgrade:
|
||||
|
||||
```sh
|
||||
npm-check -u --skip-unused
|
||||
```
|
||||
@@ -28,13 +32,14 @@ reproducible dependency tree and avoid unwanted package updates.
|
||||
|
||||
If you use a previous npm version, it is recommended to use [npm shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap) to
|
||||
lock down all your dependencies version:
|
||||
|
||||
```sh
|
||||
npm shrinkwrap --dev
|
||||
```
|
||||
|
||||
This will create a file `npm-shrinkwrap.json` alongside your `package.json` files.
|
||||
|
||||
> Do not forget to run shrinkwrap each time you manually update your dependencies!
|
||||
> Do not forget to run shrinkwrap each time you manually update your dependencies!
|
||||
|
||||
# Updating angular-cli
|
||||
|
||||
|
||||
Reference in New Issue
Block a user