Merge pull request #263 from aviveldan/UpdateTutorialTypos

Update tutorial.md

Author: galnir

content/tutorial/tutorial.md

@@ -153,7 +153,7 @@ class ShoppingList extends React.Component {
 נגיע לתגיות המצחיקות שמזכירות XML בהמשך. אנו משתמשים בקומפוננטות כדי לומר ל-React מה אנחנו רוצים לראות על המסך. כאשר הנתונים שלנו ישתנו, React יעדכן וירנדר מחדש את הקומפוננטות שלנו.
 
 
-כאן, ShoppingList היא **מחלקת קומפוננטת React**, או **מסוג קומפוננטת React**. קומפוננטה לוקחת פרמטרים, הנקראים `props` (פרופס, קיצור עבור "מאפיינים", properties), ומחזיר היררכיה של תצוגות (views) להצגה דרך המתודה `render`.
+כאן, ShoppingList היא **מחלקת קומפוננטת React**, או **מסוג קומפוננטת React**. קומפוננטה מקבלת פרמטרים, הנקראים `props` (פרופס, קיצור עבור "מאפיינים", properties), ומחזירה היררכיה של תצוגות (views) להצגה דרך המתודה `render`.
 
 המתודה `render` מחזירה *תיאור* של מה שאתם רוצים לראות על המסך. React לוקחת את התיאור ומציגה את התוצאה. בפרט, `render` מחזירה **אלמנט React**, שהוא תיאור מופשט של מה שצריך לרנדר. רוב מפתחי React משתמשים בתחביר מיוחד בשם "JSX" שהופך את המבנים האלה לקלים יותר לכתיבה. התחביר `<div />`  משתנה בזמן הבנייה (build time) ל-`React.createElement('div')`. הדוגמה שלמעלה שקולה לקוד:
 
@@ -358,7 +358,7 @@ class Square extends React.Component {
 
 אנחנו יכולים לחשוב כי הלוח צריך רק לשאול כל ריבוע על ה-state שלו. למרות שגישה זו אפשרית ב-React, אנו נרתעים ממנה משום ששימוש בה הופך את הקוד להיות קשה להבנה, רגיש לבאגים וקשה לשכתוב. במקום זאת, הגישה הטובה יותר היא לאחסן את ה-state של המשחק בקומפוננטת האב לוח במקום בכל ריבוע. קומפוננטת הלוח יכולה להגיד לכל ריבוע מה להציג על ידי העברת prop, [בדיוק כמו שעשינו כאשר העברנו מספר לכל ריבוע](#passing-data-through-props).
 
-**כדי לאסוף נתונים ממספר ילדים, או כדי לאפשר לשני קומפוננטות ילדים לתקשר אחת עם השניה, עלינו להכריז על state משותף בקומפוננטת האב שלהם במקום. קומפוננטת האב יכולה להעביר את ה-state שלה בחזרה לילדים באמצעות שימוש ב-props; פעולה זו שומרת על קומפוננטות הילדים מסונכרנות זו עם זו ועם קומפוננטת האב.**
+**כדי לאסוף נתונים ממספר ילדים, או כדי לאפשר לשתי קומפוננטות ילדים לתקשר אחת עם השניה, עלינו להכריז על state משותף בקומפוננטת האב שלהם במקום. קומפוננטת האב יכולה להעביר את ה-state שלה בחזרה לילדים באמצעות שימוש ב-props; פעולה זו שומרת על קומפוננטות הילדים מסונכרנות זו עם זו ועם קומפוננטת האב.**
 
 הרמת ה-state לקומפוננטת האב היא פעולה נפוצה כאשר משכתבים קומפוננטות React -- בואו ניקח הזדמנות זו כדי לנסות זאת.
 
@@ -435,7 +435,7 @@ class Board extends React.Component {
 * נחליף את `this.setState()` עם `this.props.onClick()` במתודת `render` של ריבוע
 * נמחק את הבנאי `constructor` מריבוע מכיון שריבוע כבר לא עוקב אחר ה-state של המשחק
 
-לאחר ביצוע שינויים אלו, קומפוננטת הריבוע נראה כך:
+לאחר ביצוע שינויים אלו, קומפוננטת הריבוע נראית כך:
 
 ```javascript{1,2,6,8}
 class Square extends React.Component {
@@ -462,7 +462,7 @@ class Square extends React.Component {
 
 >שימו לב
 >
->לתכונה `onClick` של אלמנט `<button>` של ה-DOM יש משמעות מיוחדת עבור React מכיוון שהיא קומפוננטה מובנה. עבור קומפוננטות מותאמות אישית כמו ריבוע, הגדרת השמות תלויה בנו. אנו יכולים להגדיר כל שם ל-prop `onClick` של ריבוע או למתודת `handleClick` של לוח, והקוד יעבוד באותו אופן. ב-React, זוהי קונבנציה להשתמש בשמות כמו `on[Event]` עבור props אשר מייצגים אירועים ו-`handle[Event]` עבור המתודות אשר מטפלות באירועים.
+>לתכונה `onClick` של אלמנט `<button>` של ה-DOM יש משמעות מיוחדת עבור React מכיוון שהיא קומפוננטה מובנית. עבור קומפוננטות מותאמות אישית כמו ריבוע, הגדרת השמות תלויה בנו. אנו יכולים להגדיר כל שם ל-prop `onClick` של ריבוע או למתודת `handleClick` של לוח, והקוד יעבוד באותו אופן. ב-React, זוהי קונבנציה להשתמש בשמות כמו `on[Event]` עבור props אשר מייצגים אירועים ו-`handle[Event]` עבור המתודות אשר מטפלות באירועים.
 
 כאשר אנו מנסים ללחוץ על ריבוע, אנחנו אמורים לקבל שגיאה כי עדיין לא הגדרנו את `handleClick`. כעת נוסיף את `handleClick` למחלקה לוח:
 
@@ -563,7 +563,7 @@ var newPlayer = Object.assign({}, player, {score: 2});
 
 #### ההחלטה מתי לרנדר מחדש ב-React {#determining-when-to-re-render-in-react}
 
-היתרון העיקרי של אי-יכולת השתנות הוא שהיא עוזר לנו לבנות _קומפוננטות טהורות (pure components)_ ב-React. נתונים בלתי ניתנים לשינוי מאפשרים לקבוע בקלות אם בוצעו שינויים, דבר אשר מסייע לקבוע מתי קומפוננטה דורשת רינדור מחדש.
+היתרון העיקרי של אי-יכולת השתנות הוא שהיא עוזרת לנו לבנות _קומפוננטות טהורות (pure components)_ ב-React. נתונים בלתי ניתנים לשינוי מאפשרים לקבוע בקלות אם בוצעו שינויים, דבר אשר מסייע לקבוע מתי קומפוננטה דורשת רינדור מחדש.
 
 אתם יכולים ללמוד עוד על `shouldComponentUpdate()` וכיצד ניתן לבנות *קומפוננטות טהורות* על ידי קריאת [אופטימיזציה של ביצועים](/docs/optimizing-performance.html#examples).