Fixed typos

Author: JasonStoltz

README.md

@@ -27,7 +27,7 @@ and include some instructions on running.
 
 ## Component Structure
 
-This project is structure in such a way that it mimics the eventual setup
+This project is structured in such a way that it mimics the eventual setup
 of our UI toolkit.
 
 For example:
@@ -44,21 +44,21 @@ For example:
 
 `AppSearchProvider` - The "Provider" is configured at the top level of your App.
 You pass it an instance of `AppSearchDriver`, which is configured for your
-account and engine. This "Provider" uses React's "Context" API to hold state
+Account and Engine. This "Provider" uses React's "Context" API to hold state
 and expose that state to other App Search components in the component tree.
 `AppSearchDriver` - Non-React "driver" class. The idea is to hold all non-React
 specific logic here, so that it can be shared across multiple toolkits
 `containers/{SearchBox,Meta,Results}` - These are individual "Connected" App
 Search Components. They are aware of state provided by AppSearchProvider and can
 update that state as well. They have no "View" of their own, they simply hold
-the logic. This means that any "View" component could be swapped in.
+implement the logic. This means that any "View" component could be swapped in.
 
 Not shown above, but included in this project:
 
 `components/{SearchBox,Meta,Results,Result` - These are individual "View"
-components. They have no logic and are not aware of App Search. They simply take
-simple properties are render them. These would be the "default" views for
-UI Toolkit, but could be easily swapped out.
+components. They have no logic and are not aware of App Search. They take
+simple properties and render them in a template. These would be the "default"
+views for UI Toolkit, but could be easily swapped out.
 `app-search/withAppSearch` - A higher order component that a Toolkit user could
 use to connect any component to the App Search state. This enables users to
 write their own components.