Merge pull request piotrwitek#34 from pino/master

Fixing linebreak and grammar problems

Author: piotrwitek

Diff for: README.md

@@ -1,5 +1,5 @@
 # React & Redux in TypeScript - Static Typing Guide
-**_"This guide is about to teach you how to leverage [Type Inference](https://www.typescriptlang.org/docs/handbook/type-inference.html), [Generics](https://www.typescriptlang.org/docs/handbook/generics.html) and other [Advanced Types](https://www.typescriptlang.org/docs/handbook/advanced-types.html) as much as possible to write the minimal amount of type annotations needed for your JavaScript code to be completely Type Safe"_** - this will make sure you get all the benefits of Static Typing and won't slow down your productivity by adding unnecessary typings.
+**_"This guide is about to teach you how to leverage [Type Inference](https://www.typescriptlang.org/docs/handbook/type-inference.html), [Generics](https://www.typescriptlang.org/docs/handbook/generics.html) and other [Advanced Types](https://www.typescriptlang.org/docs/handbook/advanced-types.html) as much as possible to write the minimal amount of type annotations needed for your JavaScript code to be completely Type Safe"_** - this will make sure you get all the benefits of Static Typing and your productivity won't be slowed down by adding excess type annotations.
 
 > #### _Found it usefull? Want more updates?_ [**Give it a :star2:**](https://github.com/piotrwitek/react-redux-typescript-patterns/stargazers)  
 
@@ -10,7 +10,7 @@
 
 ### Playground Project
 You should check Playground Project located in the `/playground` folder. It is a source of all the code examples found in the guide. They are all tested with the most recent version of TypeScript and 3rd party type definitions (like `@types/react` or `@types/react-redux`) to ensure the examples are up-to-date and not broken with updated definitions.
-> Playground was created is such ą way, that you can easily clone repository locally and immediately play around on your own to learn all the examples from this guide in a real project environment without complicated setup.
+> Playground was created is such a way, that you can simply clone the repository locally and immediately play around on your own to learn all the examples from this guide in a real project environment without the need to create some complicated environment setup by yourself.
 
 ---
 
@@ -630,6 +630,7 @@ This pattern is focused on a KISS principle - to stay clear of complex proprieta
 Advantages:
 - simple "const" based types
 - familiar to standard JS usage
+
 Disadvantages:
 - significant amount of boilerplate and duplication
 - necessary to export both action types and action creators to re-use in other places, e.g. `redux-saga` or `redux-observable`
@@ -882,8 +883,8 @@ export type RootAction =
 
 ### Create Store
 
-When creating store use rootReducer instance, this alone will to set-up **strongly typed Store instance** with type inference.
-> The resulting store instance methods like `getState` or `dispatch` will be typed checked and expose type errors
+When creating the store, use rootReducer. This will set-up a **strongly typed Store instance** with type inference.
+> The resulting store instance methods like `getState` or `dispatch` will be type checked and expose type errors
 
 ```tsx
 import { createStore, applyMiddleware, compose } from 'redux';
@@ -1232,7 +1233,7 @@ declare module 'enzyme';
 # FAQ
 
 ### - should I still use React.PropTypes in TS?
-> 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.  
+> No. With TypeScript, using PropTypes 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 standardized method of documenting your component external API in the source code.  
 
 [⇧ back to top](#table-of-contents)
 

Diff for: docs/markdown/2_redux.md

@@ -8,6 +8,7 @@ This pattern is focused on a KISS principle - to stay clear of complex proprieta
 Advantages:
 - simple "const" based types
 - familiar to standard JS usage
+
 Disadvantages:
 - significant amount of boilerplate and duplication
 - necessary to export both action types and action creators to re-use in other places, e.g. `redux-saga` or `redux-observable`
@@ -160,8 +161,8 @@ Can be imported in various layers receiving or sending redux actions like: reduc
 
 ### Create Store
 
-When creating store use rootReducer instance, this alone will to set-up **strongly typed Store instance** with type inference.
-> The resulting store instance methods like `getState` or `dispatch` will be typed checked and expose type errors
+When creating the store, use rootReducer. This will set-up a **strongly typed Store instance** with type inference.
+> The resulting store instance methods like `getState` or `dispatch` will be type checked and expose type errors
 
 ::example='../../playground/src/store.ts'::
 

Diff for: docs/markdown/5_faq.md

@@ -1,7 +1,7 @@
 # FAQ
 
 ### - should I still use React.PropTypes in TS?
-> 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.  
+> No. With TypeScript, using PropTypes 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 standardized method of documenting your component external API in the source code.  
 
 [⇧ back to top](#table-of-contents)