Merge branch 'master' of https://github.com/alsiola/form-and-function

Author: alexyounghive

CONTRIBUTING.md

@@ -0,0 +1,17 @@
+If you want to help out with improving form-and-function then first, thank you very much!
+
+At the moment the folder structure is a little odd, because this project started out as a create-react-app project, and that is 
+still in place for the demos.  I'm somewhat fond of keeping the demos in the same repo because then any API breaking changes 
+are very obvious, but if there is a compelling reason to change then let's talk.  The upshot of this is that the library code 
+lives in the `src/lib` folder.
+
+There are a couple of useful scripts in the `package.json`:
+
+* `start` - starts the demo locally
+* `build` - builds the library
+
+The build process currently uses the Typescript compiler to get down to ES5 and emit declarations, but keep things in modules, 
+then rollup to create bundles from these modules.  Probably a bit hacky, and something that needs improving but it works for now.
+
+There is no tolerance of any anti-social behaviour of any form amongst anyone contributing to this project.  And I decide what 
+anti-social means. Just be nice.

README.md

@@ -433,7 +433,7 @@ Of course, we want to give feedback to our users on both fields. We can do this
 
 #### Writing Your Own Validators
 
-Although the provided validators cover a lot of sitations, undoubtedly at some point you will need to create your own. This is relatively simple. Validators must match the signature:
+Although the provided validators cover a lot of situations, undoubtedly at some point you will need to create your own. This is relatively simple. Validators must match the signature:
 
 ```js
 interface ValidResult {
@@ -558,7 +558,7 @@ If, as above, we name our messages using the same keys as the form validation me
 
 ## State Management
 
-One of the design goals was to create a library that was agnostic to the variety of state management used. I'm not certain that this is an easy target, or one that is achieved entirely, but the current attempt uses a prop on the `Form` component: `stateEngine`. This is an optional prop, and if not passed then `form-and-function` will create its own state engine that uses the internal state of the `Form` component. If supplied, this prop should be an object that fulfils the following interface:
+One of the design goals was to create a library that was agnostic to the variety of state management used. I'm not certain that this is an easy target, or one that is achieved entirely, but the current attempt uses a prop on the `Form` component: `stateEngine`. This is an optional prop, and if not passed then `form-and-function` will create its own state engine that uses the internal state of the `Form` component. If supplied, this prop should be an object that fulfills the following interface:
 
 ```js
 export interface StateEngine<T extends object> {