Proofing chapter styling (#26)

Author: kakulgupta

8-styling/8.0-intro.md

@@ -1,10 +1,10 @@
 # Styling in React Native
 
-In react native we use StyleSheets to write our styling. StyleSheets can be thought of something like a subset of CSS along with few additional helpers for RN. StyleSheets unlike CSS are pure JavaScript objects. This might confuse some web developers in the beginning and introduces a slight learning curve. StyleSheets in React Native are used somewhat similar to that of inline styles in web. Hence, you do not have access to pseudo classes like `:hover`,`:active`, etc.
+In React Native we use StyleSheets to write our styling. StyleSheets can be thought of as a subset of CSS along with a few additional helpers for RN. StyleSheets, unlike CSS, are pure JavaScript objects. This might confuse some web developers in the beginning and introduce a slight learning curve. StyleSheets in React Native are used somewhat similarly to inline styles in web. Hence, you do not have access to pseudo-classes like `:hover`, `:active`, etc.
 
 ### Example
 
-Imagine we want to add padding and border to a span. In CSS we will write:
+To add padding and border to a span in CSS we will write:
 
 ```css
 .button {
@@ -13,15 +13,15 @@ Imagine we want to add padding and border to a span. In CSS we will write:
   border: 1px solid black;
 }
 ```
-and then we will add this class to our span like this:
+Then we will add this class to our span like this:
 ```html
 <span class="button"> Test </span>
 ```
 Resulting in :
 
 <span style='padding:15px;border:1px solid black;'> Test </span>
 
-In React Native, there is no concept of pixels or classes. Instead, our sizes will be specified in "units" which will then be translated to pixels based on the pixel density of the screen automagically by RN. If we write the same `View` in a React Native StyleSheet, it would look something like this.
+In React Native, there is no concept of pixels or classes. Instead, our sizes will be specified in "units" which will then be translated to pixels based on the pixel density of the screen automatically by RN. If we write the same `View` in a React Native StyleSheet, it would look something like this:
 
 >styles.js
 ```js
@@ -36,7 +36,7 @@ export default StyleSheet.create({
 });
 ```
 
-and we will add styles to our View by:
+These styles can be added to our View using:
 
 ```js
 import styles from './styles.js';
@@ -48,10 +48,10 @@ import styles from './styles.js';
 <View style={styles.button}></View>
 ```
 
-Note that since we are writing JavaScript objects, immediately we notice that:
-- We write each style in its camel-cased version of the CSS
-- We then import our StyleSheet into our components and used them by declaring a style attribute as shown instead of classes.
+Note that since we are writing JavaScript objects:
+- We write each style attribute in its camel-cased version of CSS
+- We import our StyleSheet into our components and used them by declaring a style attribute as shown instead of classes.
 - There are no shorthands like `border:'1px solid black'`
 
 >Just like web, it is very easy to go wrong with CSS and end up with a style code that is unmanageable.
-Hence, we would like to introduce few basic guidelines in the next chapters, so that we can get most from our styles.
+Hence, we would like to introduce a few basic guidelines in the next chapters, so that we can get the most from our styles.

8-styling/8.1-theme-variables.md

@@ -1,14 +1,14 @@
 # Theme Variables
 
-In general every app should have few fixed font sizes, colors, spacing, etc. This is done so that the app looks consistent across screens.
-Now this can be achieved by keeping a convention across the app.
-For example, the devs and UX designers can decide **fontSize**:
+In general, every app should have well defined font sizes, colors, spacing, etc. This is done so that the app looks consistent across screens.
+Now this can be achieved by maintaining a convention across the app.
+For example, the devs and UX designers can decide **fontSize** as:
 
 - 16 - Large
 - 14 - Medium
 - 12 - Small
 
-Hence our style sheet may look like this :
+Hence our stylesheet may look like this:
 
 >styles.js
 ```js
@@ -28,17 +28,17 @@ export default StyleSheet.create({
 });
 ```
 
-Even though this convention is good and will help you maintain consistency in small,medium and large text sizes across the app,
-it has few fundamental faults:
+Even though this convention is good and will help you maintain consistency in small, medium and large text sizes across the app, it does have a few fundamental flaws:
+
+- Business/marketing team may come up with a change in the requirement that the large font size needs to be 18 instead of 16.
 
-- Business/Marketing team may come up with a new requirement that now they want the large font size to be 18 instead of 16.
   Now as a developer, you will need to make changes in the entire app and replace every instance of fontSize:16 with fontSize:18, which kind of sucks!.
-- A new developer who joined the team might not be aware of all the conventions followed by the team and may create a component with fontSize other than 12,14 or 16 thus accidently destroying the code standard/convention.
+- A new developer who joins the team might not be aware of all the conventions followed by the team and may create a component with fontSize other than 12, 14 or 16, thus accidentaly overlooking the code standard/convention.
 
 
 Enter **`theme variables`**.
 
-In order to solve the above mentioned issues we introduce a common file `theme.style.js` which will be located at `app/styles/theme.style.js`.
+In order to solve the above-mentioned issues, we introduce a common file `theme.style.js` which will be located at `app/styles/theme.style.js`.
 
 In the theme file we define our `theme` variables as follows:
 
@@ -57,7 +57,7 @@ export default {
 };
 ```
 
-and we can use it like this
+and we can use them like this:
 
 >styles.js
 
@@ -84,14 +84,14 @@ Now our theme file dictates the size of fonts and the primary color, etc.
 
 This gives us two benefits:
 - If our business team now tell us to change the font sizes, we can change the theme variables at one place and it gets reflected in the entire app.
-- This will enable us to write multiple theme files which inturn adds basic themeing support to our app. For example: we can write two theme files - one for light theme and one for dark theme and give our app users the option to switch the themes.
+- This will enable us to write multiple theme files which in turn adds basic theming support to our app. For example we can write two theme files - one for a light theme and one for a dark theme and give our app users the option to switch between the themes.
 
 
 ### Integrating theme variables into our NoteTaker demo
 
-Enough of the theory, lets try and inculcate this concept into our demo app.
+Enough of theory. Let's try and inculcate this concept into our demo app.
 
-First of all add the file `app/style/theme.style.js`.
+First of all, add the file `app/style/theme.style.js`.
 
 >app/style/theme.style.js
 

8-styling/8.2-common-styles-mixins.md

@@ -2,7 +2,7 @@
 
 In React Native, each component is styled using inline styles. This means that it becomes slightly tricky to share styles as you can in web.
 
-In web we write a class
+In web, we write a class
 
 ```css
 .btn {
@@ -17,7 +17,7 @@ Now if we want to apply this class to two different divs we will do so as follow
 <div class='btn second-btn'>Second button</div>
 ```
 
-Now same is possible in react native as follows:
+The same is possible in React Native in the following way:
 
 
 **`styles.js`**
@@ -54,13 +54,13 @@ import styles from './styles.js';
 </View>
 ```
 
-While this solves the problem only if the style objects are in the same component because in RN we do not import styles from other components (each component has its own style). But in web, we could have just reused the class anywhere (since css is global).
+This solves the problem only if the style objects are in the same component because in RN we do not import styles from other components (each component has its own style). But in web, we could have just reused the class anywhere (since css is global).
 
 To solve the problem of reusable styles in React Native, we introduce another file named **`app/style/common.style.js`**
-This is where we will write our mixins / common styles.
+This is where we will write our mixins/common styles.
 
 
-Hence,if all the buttons in our app have similar style we can write a style with the similar properties inside the **common.style.js**
+Hence, if all the buttons in our app have a similar style we can write a style with similar properties inside the **common.style.js**
 
 **`app/style/common.style.js`**
 ```js
@@ -107,13 +107,13 @@ import styles from './styles.js';
 ```
 
 This way our mixins/common style file will provide us the base styles which are common across the app and we write component specific styles in the component style file.
-Thus allowing significant style reuse and avoiding code duplication.
+This allows significant style reuse and avoids code duplication.
 
 
 ### Integrating common/mixin styles into our NoteTaker demo
 
-Before we go into common styles , lets modify our code a bit to add another component for entering title for our note.
-Modify the following files as follows:
+Before we go into common styles, let's modify our code a bit to add another component for entering a title for our note.
+Modify the files as follows:
 
 **`app/components/Home/Home.component.js`**
 
@@ -208,11 +208,12 @@ Our app should now look like this:
 <br>
 
 
-If you notice, even though we have theme file, our style code has lot of duplicated code. Primarily because we are repeating our styling for text input and also for the heading.
+If you notice, even though we have a theme file, our style code has a lot of duplicated code. This is primarily because we are repeating our styling for text input and also for the heading.
 
-The solution to this problem as discussed before is common styles/ mixins
+The solution to this problem, as discussed before, is common styles/mixins.
+
+Let's create the file `common.style.js`
 
-Lets create the file `common.style.js`
 **`app/styles/common.style.js`**
 ```js
 import theme from './theme.style';
@@ -264,11 +265,11 @@ export default StyleSheet.create({
 });
 ```
 
-If you see our style code looks much more consice and we are resuing the styles for similar components with slight style changes.
+If you see our style code looks much more concise and we are resuing the styles for similar components with slight style changes.
 Hence, we import our base styles for the components from common.style.js and add our custom styles later on top of it.
 This way we reduce our work and minimize code duplication.
 
-We see no change in the output but our code becomes much much cleaner.
+We see no change in the output but our code becomes much cleaner.
 <br>
 <div style="text-align:center">
   <img src="/assets/images/8/8.2/8.2-before-common.png" style="width: 40%;display:inline-block;" hspace="40">

8-styling/8.3-separating-styles-from-component.md

@@ -1,6 +1,6 @@
 # Separating styles from component code
 
-Lets assume we want to build a Button component.
+Let's assume we want to build a Button component.
 
 A simple button will look something like this:
 
@@ -77,10 +77,10 @@ export default StyleSheet.create({
 });
 ```
 
-This has few benefits:
+This has a few benefits:
 
 - This makes the component code much cleaner. The style is present in its own separate file.
-- This allows you two write two different style files for android and ios when needed. Thus you keep the same functionality but the button looks different as needed in two different platforms.
+- This allows you to write two different style files for Android and iOS if required. Thus, you can keep the same functionality but the button can look different based on the requirement for the platform.
 
 For example:
 
@@ -140,10 +140,10 @@ export default StyleSheet.create({
 });
 ```
 
-Thus by simply moving the styles into a separate file we could achieve a style code that behaves exactly the way we needed in different platforms. Also, we could reuse the component logic.
+Thus by simply moving the styles into a separate file, we could achieve a style code that behaves exactly the way we needed on different platforms. Also, we could reuse the component logic.
 
 
 
 ### Conclusion
 
-In Web, we have lots of production grade tools like Sass, Less, etc which allows us to write modular, scoped CSS which are easier to manage. These tools then take care of building all our style code into one cohesive stylesheet for our entire application. In React Native, we must think of styling in a slightly different manner. By doing some pre-planning and organization before writing the code for the components, we can reduce code duplication and unnecessary confusions. It takes a bit of getting used to, but styling in React Native is as powerful as the CSS for the web and is the fastest way to build multiplatform native applications.
+In Web, we have lots of production grade tools like Sass, Less, etc which allow us to write modular, scoped CSS which is easier to manage. These tools then take care of building all our style code into one cohesive stylesheet for our entire application. In React Native, we must think of styling in a slightly different manner. By doing some pre-planning and organization before writing the code for the components, we can reduce code duplication and unnecessary confusions. It takes a bit of getting used to, but styling in React Native is as powerful as CSS for the web and is the fastest way to build multi-platform native applications.