Tweak 05_runningsideeffects for fluency

Author: mieky

packages/overmind-website/guides/beginner/05_runningsideeffects.md

@@ -1,14 +1,14 @@
 # Running side effects
 
-Developing applications is not only about managing state, but also managing side effects. A side effect is typically exampled with an http request or talking to local storage. In Overmind we just call this **effects**. There are several reasons why you would want to use effects:
+Developing applications is not only about managing state, but also managing side effects. A typical side effect would be an HTTP request or talking to localStorage. In Overmind we just call these **effects**. There are several reasons why you would want to use effects:
 
 1. All the code in your actions will be domain specific, no low level generic APIs
-2. Your actions will have less code and you avoid leaking out things like urls, types etc.
-3. You decouple the underlying tool from the usage of it, meaning that you can replace it at any time without changing your application logic
-4. You can more easily expand functionality of an effect. For example you want to introduce caching or a base url to an http effect
+2. Your actions will have less code and you avoid leaking out things like URLs, types etc.
+3. You decouple the underlying tool from its usage, meaning that you can replace it at any time without changing your application logic
+4. You can more easily expand the functionality of an effect. For example you want to introduce caching or a base URL to an HTTP effect
 5. The devtool tracks its execution
-6. If you write Overmind tests you can easily mock them
-7. You can lazy load the effect, reducing the initial payload of the app
+6. If you write Overmind tests, you can easily mock them
+7. You can lazy-load the effect, reducing the initial payload of the app
 
 ## Exposing an existing tool
 
@@ -18,15 +18,15 @@ Let us just expose the [axios](https://github.com/axios/axios) library as an **h
 h(Example, { name: "guide/runningsideeffects/axios" })
 ```
 
-We are just exporting the existing library from our effects file and include it in the application config. Now Overmind is aware of an **http** effect. It can track it for debugging and all actions and operators will have it injected.
+We are just exporting the existing library from our effects file and including it in the application config. Now Overmind is aware of an **http** effect. It can track it for debugging and all actions and operators will have it injected.
 
 Let us put it to use in an action that grabs the current user of the application.
 
 ```marksy
 h(Example, { name: "guide/runningsideeffects/getuser" })
 ```
 
-That was basically it. As you can see we are exposing some low level details like the http method used and the url. Let us follow the encouraged way of doing things and create our own **api** effect.
+That was basically it. As you can see we are exposing some low level details like the http method used and the URL. Let us follow the encouraged way of doing things and create our own **api** effect.
 
 ## Specific API
 
@@ -44,13 +44,13 @@ h(Example, { name: "guide/runningsideeffects/changestate" })
 
 ## Initializing effects
 
-It can be a good idea to not allow your side effects to initialize when they are defined. This makes sure that they do not leak into tests or server side rendering. For example if you want to use Firebase. Instead of initializing the Firebase application immediately we rather do it behind an **initialize** method:
+It can be a good idea to not allow your side effects to initialize when they are defined. This makes sure that they do not leak into tests or server side rendering. For example if you want to use Firebase, instead of initializing the Firebase application immediately we rather do it behind an **initialize** method:
 
 ```marksy
 h(Example, { name: "guide/runningsideeffects/initialize" })
 ```
 
-We are doing 2 things here:
+We are doing two things here:
 
 1. We use an [IIFE](https://developer.mozilla.org/en-US/docs/Glossary/IIFE) to create a scoped internal variable to be used for that specific effect
 2. We have created an **initialize** method which we can call from the Overmind **onInitialize** action, which runs when the Overmind instance is created
@@ -80,7 +80,7 @@ You can also lazily load your effects in the **initialize** method. Let us say w
 h(Example, { name: "guide/runningsideeffects/lazy" })
 ```
 
-In our initialize we would just have to wait for the initialize to finish before using the API:
+In our initialize() we would just have to wait for the initialization to finish before using the API:
 
 
 ```marksy
@@ -101,4 +101,4 @@ h(Example, { name: "guide/runningsideeffects/class" })
 We export an instance of our **Api** to the application. This allows us to also create instances in isolation for testing purposes, making sure our Api class works as we expect.
 
 ## Summary
-Importing side effects directly into your code should be considered bad practice. If you think about it from an application standpoint it is kinda weird that it runs http verb methods with a string url. It is better to create an abstraction around it to make your code more consistent with the domain, and by doing so also improve maintainability.
+Importing side effects directly into your code should be considered bad practice. If you think about it from an application standpoint it is kinda weird that it runs HTTP verb methods with a URL string passed in. It is better to create an abstraction around it to make your code more consistent with the domain, and by doing so also improve maintainability.