Update README.md

Author: piotrwitek

README.md

@@ -945,7 +945,11 @@ npm i -D @types/react @types/react-dom @types/react-redux
 ```
 
 ### - should I still use React.PropTypes in TS?
-> No. In TypeScript it is unnecessary, when declaring Props and State types (refer to React components examples) you will get completely free intellisense and compile-time safety with static type checking, this way you'll be safe from runtime errors, not waste time on debugging and get an elegant way of describing component external API in your source code.  
+> No. When using TypeScript it is an unnecessary overhead, when declaring IProps and IState interfaces, you will get complete intellisense and compile-time safety with static type checking, this way you'll be safe from runtime errors and you will save a lot of time on debugging. Additional benefit is an elegant and standarized method of documenting your component external API in the source code.  
+
+### - when to use `interface` declarations and when `type` aliases?
+> From practical side, using `interface` declaration will display identity (interface name) in compiler errors, on the contrary `type` aliases will be unwinded to show all the properties and nested types it consists of. This can be a bit noisy when reading compiler errors and I like to leverage this distinction to hide some of not so important type details in errors  
+Related `ts-lint` rule: https://palantir.github.io/tslint/rules/interface-over-type-literal/  
 
 ### - how to best initialize class instance or static properties?
 > Prefered modern style is to use class Property Initializers  
@@ -975,10 +979,6 @@ class MyComponent extends React.Component<Props, State> {
 }
 ```
 
-### - differences between `interface` declarations and `type` aliases
-> From practical point of view `interface` types will use it's identity when showing compiler errors, while `type` aliases will be always unwinded to show all the nested types it consists of. This can be too noisy when reading compiler errors and I like to leverage this distinction to hide some not important type details in reported type errors  
-Related `ts-lint` rule: https://palantir.github.io/tslint/rules/interface-over-type-literal/  
-
 ---
 
 # Project Examples