Merge pull request #4 from dphilipson/docs/remove-bad-example

Remove bad string literal example, add IDE reason

Author: dphilipson

README.md

@@ -84,22 +84,7 @@ console.log(state);
 
 ### Why not string literals?
 
-Using string literals throughout a program leaves it vulnerable to bugs caused by typos or
-incomplete refactors. For example:
-
-``` javascript
-type Status = "RUNNING" | "STOPPED";
-
-...
-
-// Typo "SOTPPED" is not caught by typechecker.
-// Pretty bad bug- this block will never run.
-if (state.status === "SOTPPED") {
-    soundTheAlarm();
-}
-```
-
-Further, string literals make refactoring difficult. Suppose I have two enums:
+String literals make refactoring difficult. Suppose I have two enums:
 
 ``` javascript
 type Status = "RUNNING" | "STOPPED";
@@ -111,6 +96,10 @@ way to do it. I can't globally find/replace `"RUNNING"` to `"STARTED"` because i
 the unrelated string constants representing `TriathlonStage`. Instead, I have to examine every
 occurrance of the string `"RUNNING"` to see if it needs to change.
 
+Another disadvantage of string literals comes when using IDE autocomplete features. It's convenient
+to be able to type `Status.` and have autocomplete suggest `Status.RUNNING` and `Status.STOPPED`,
+but with string literals no such suggestion appears with current IDEs.
+
 I might try to solve both problems by introducing constants for the string literals, but this has
 issues as well:
 
@@ -175,7 +164,7 @@ function Enum<V extends string>(...values: V[]): { [K in V]: K }
 
 the type parameter `V` is thus inferred to be `"RUNNING" | "STOPPED"`. Then the return type
 `{ [K in V]: K }` is a mapped type which describes an object whose keys are the types that
-make up `V` and for each such key has a value equal to that key. Hence, the type of
+make up `V` and for each such key has a value of the same type as that key. Hence, the type of
 `Enum("RUNNING", "STOPPED")` is
 
 ``` javascript