]/g, '');
let description = isHomePage
- ? 'React is the library for web and native user interfaces. Build user interfaces out of individual pieces called components written in JavaScript. React is designed to let you seamlessly combine components written by independent people, teams, and organizations.'
- : 'The library for web and native user interfaces';
+ ? 'React היא הספרייה לממשקי משתמש לווב ולנייטיב. בנו ממשקי משתמש מחלקים נפרדים שנקראים קומפוננטות ונכתבים ב-JavaScript. React תוכננה כדי לאפשר שילוב חלק של קומפוננטות שנכתבו בידי אנשים, צוותים וארגונים שונים.'
+ : 'הספרייה לממשקי משתמש לווב ולנייטיב';
return (
diff --git a/src/content/blog/2020/12/21/data-fetching-with-react-server-components.md b/src/content/blog/2020/12/21/data-fetching-with-react-server-components.md
index 948096c0f..1235e63df 100644
--- a/src/content/blog/2020/12/21/data-fetching-with-react-server-components.md
+++ b/src/content/blog/2020/12/21/data-fetching-with-react-server-components.md
@@ -2,30 +2,30 @@
title: "Introducing Zero-Bundle-Size React Server Components"
---
-December 21, 2020 by [Dan Abramov](https://twitter.com/dan_abramov), [Lauren Tan](https://twitter.com/potetotes), [Joseph Savona](https://twitter.com/en_JS), and [Sebastian Markbåge](https://twitter.com/sebmarkbage)
+21 בדצמבר 2020 מאת [Dan Abramov](https://twitter.com/dan_abramov), [Lauren Tan](https://twitter.com/potetotes), [Joseph Savona](https://twitter.com/en_JS), ו-[Sebastian Markbåge](https://twitter.com/sebmarkbage)
---
-2020 has been a long year. As it comes to an end we wanted to share a special Holiday Update on our research into zero-bundle-size **React Server Components**.
+2020 הייתה שנה ארוכה. לקראת סיומה רצינו לשתף עדכון חגים מיוחד על המחקר שלנו בנושא **React Server Components** בגודל bundle אפסי.
---
-To introduce React Server Components, we have prepared a talk and a demo. If you want, you can check them out during the holidays, or later when work picks back up in the new year.
+כדי להציג את React Server Components, הכנו הרצאה ודמו. אם תרצו, אפשר לעבור עליהם במהלך החגים, או בהמשך כשחוזרים לעבודה בשנה החדשה.
-**React Server Components are still in research and development.** We are sharing this work in the spirit of transparency and to get initial feedback from the React community. There will be plenty of time for that, so **don't feel like you have to catch up right now!**
+**React Server Components עדיין נמצאים במחקר ופיתוח.** אנחנו משתפים את העבודה הזו ברוח של שקיפות וכדי לקבל פידבק ראשוני מקהילת React. יהיה לזה עוד הרבה זמן, אז **אין צורך להרגיש שחייבים להדביק הכול עכשיו!**
-If you want to check them out, we recommend going in the following order:
+אם אתם רוצים לבדוק אותם, אנחנו ממליצים להתקדם בסדר הבא:
-1. **Watch the talk** to learn about React Server Components and see the demo.
+1. **צפו בהרצאה** כדי ללמוד על React Server Components ולראות את הדמו.
-2. **[Clone the demo](http://github.com/reactjs/server-components-demo)** to play with React Server Components on your computer.
+2. **[שכפלו את הדמו](http://github.com/reactjs/server-components-demo)** כדי לשחק עם React Server Components במחשב שלכם.
-3. **[Read the RFC (with FAQ at the end)](https://github.com/reactjs/rfcs/pull/188)** for a deeper technical breakdown and to provide feedback.
+3. **[קראו את ה-RFC (כולל FAQ בסוף)](https://github.com/reactjs/rfcs/pull/188)** לפירוק טכני עמוק יותר ולמתן פידבק.
-We are excited to hear from you on the RFC or in replies to the [@reactjs](https://twitter.com/reactjs) Twitter handle. Happy holidays, stay safe, and see you next year!
+נשמח לשמוע מכם ב-RFC או בתגובות לחשבון ה-Twitter של [@reactjs](https://twitter.com/reactjs). חג שמח, שמרו על עצמכם, ונתראה בשנה הבאה!
diff --git a/src/content/blog/2021/06/08/the-plan-for-react-18.md b/src/content/blog/2021/06/08/the-plan-for-react-18.md
index 0bf744c1d..5bb8182d3 100644
--- a/src/content/blog/2021/06/08/the-plan-for-react-18.md
+++ b/src/content/blog/2021/06/08/the-plan-for-react-18.md
@@ -1,68 +1,68 @@
---
-title: "The Plan for React 18"
+title: "התוכנית ל-React 18"
---
-June 8, 2021 by [Andrew Clark](https://twitter.com/acdlite), [Brian Vaughn](https://github.com/bvaughn), [Christine Abernathy](https://twitter.com/abernathyca), [Dan Abramov](https://twitter.com/dan_abramov), [Rachel Nabors](https://twitter.com/rachelnabors), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Seth Webster](https://twitter.com/sethwebster)
+8 ביוני 2021 מאת [Andrew Clark](https://twitter.com/acdlite), [Brian Vaughn](https://github.com/bvaughn), [Christine Abernathy](https://twitter.com/abernathyca), [Dan Abramov](https://twitter.com/dan_abramov), [Rachel Nabors](https://twitter.com/rachelnabors), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Seth Webster](https://twitter.com/sethwebster)
---
-The React team is excited to share a few updates:
+צוות React שמח לשתף כמה עדכונים:
-1. We’ve started work on the React 18 release, which will be our next major version.
-2. We’ve created a Working Group to prepare the community for gradual adoption of new features in React 18.
-3. We’ve published a React 18 Alpha so that library authors can try it and provide feedback.
+1. התחלנו לעבוד על React 18, שתהיה גרסת ה-major הבאה שלנו.
+2. הקמנו Working Group כדי להכין את הקהילה לאימוץ הדרגתי של יכולות חדשות ב-React 18.
+3. פרסמנו React 18 Alpha כדי שמחברי ספריות יוכלו לנסות ולתת משוב.
-These updates are primarily aimed at maintainers of third-party libraries. If you’re learning, teaching, or using React to build user-facing applications, you can safely ignore this post. But you are welcome to follow the discussions in the React 18 Working Group if you're curious!
+העדכונים האלה מיועדים בעיקר למתחזקי ספריות צד שלישי. אם אתם לומדים, מלמדים או משתמשים ב-React לבניית אפליקציות למשתמשי קצה, אפשר להתעלם בבטחה מהפוסט הזה. אבל אתם בהחלט מוזמנים לעקוב אחרי הדיונים ב-React 18 Working Group אם זה מסקרן אתכם.
---
-## What’s coming in React 18 {/*whats-coming-in-react-18*/}
+## מה מגיע ב-React 18 {/*whats-coming-in-react-18*/}
-When it’s released, React 18 will include out-of-the-box improvements (like [automatic batching](https://github.com/reactwg/react-18/discussions/21)), new APIs (like [`startTransition`](https://github.com/reactwg/react-18/discussions/41)), and a [new streaming server renderer](https://github.com/reactwg/react-18/discussions/37) with built-in support for `React.lazy`.
+כשתשוחרר, React 18 תכלול שיפורים מובנים (כמו [automatic batching](https://github.com/reactwg/react-18/discussions/21)), APIs חדשים (כמו [`startTransition`](https://github.com/reactwg/react-18/discussions/41)), וגם [renderer חדש לשרת בסטרימינג](https://github.com/reactwg/react-18/discussions/37) עם תמיכה מובנית ב-`React.lazy`.
-These features are possible thanks to a new opt-in mechanism we’re adding in React 18. It’s called “concurrent rendering” and it lets React prepare multiple versions of the UI at the same time. This change is mostly behind-the-scenes, but it unlocks new possibilities to improve both real and perceived performance of your app.
+היכולות האלה מתאפשרות בזכות מנגנון opt-in חדש שאנחנו מוסיפים ב-React 18. קוראים לו "concurrent rendering", והוא מאפשר ל-React להכין כמה גרסאות של ה-UI בו-זמנית. זה שינוי שמתרחש בעיקר מאחורי הקלעים, אבל הוא פותח אפשרויות חדשות לשיפור גם הביצועים בפועל וגם חוויית המהירות הנתפסת של האפליקציה.
-If you've been following our research into the future of React (we don't expect you to!), you might have heard of something called “concurrent mode” or that it might break your app. In response to this feedback from the community, we’ve redesigned the upgrade strategy for gradual adoption. Instead of an all-or-nothing “mode”, concurrent rendering will only be enabled for updates triggered by one of the new features. In practice, this means **you will be able to adopt React 18 without rewrites and try the new features at your own pace.**
+אם עקבתם אחרי המחקר שלנו לגבי עתיד React (אנחנו לא מצפים שכן), אולי שמעתם על משהו שנקרא "concurrent mode" או שהוא עלול לשבור את האפליקציה שלכם. בעקבות משוב כזה מהקהילה, עיצבנו מחדש את אסטרטגיית השדרוג כך שתתמוך באימוץ הדרגתי. במקום "mode" של הכול-או-כלום, concurrent rendering יופעל רק עבור עדכונים שמופעלים על ידי אחת היכולות החדשות. בפועל זה אומר ש-**תוכלו לאמץ את React 18 בלי כתיבה מחדש, ולנסות יכולות חדשות בקצב שלכם.**
-## A gradual adoption strategy {/*a-gradual-adoption-strategy*/}
+## אסטרטגיית אימוץ הדרגתית {/*a-gradual-adoption-strategy*/}
-Since concurrency in React 18 is opt-in, there are no significant out-of-the-box breaking changes to component behavior. **You can upgrade to React 18 with minimal or no changes to your application code, with a level of effort comparable to a typical major React release**. Based on our experience converting several apps to React 18, we expect that many users will be able to upgrade within a single afternoon.
+מכיוון ש-concurrency ב-React 18 הוא opt-in, אין שינויים שוברים משמעותיים בהתנהגות קומפוננטות כברירת מחדל. **אפשר לשדרג ל-React 18 עם מעט מאוד שינויים בקוד האפליקציה, או בלי שינויים בכלל, במאמץ דומה לשחרור major טיפוסי של React**. על סמך הניסיון שלנו בהסבת כמה אפליקציות ל-React 18, אנחנו מצפים שמשתמשים רבים יצליחו לשדרג תוך אחר צהריים אחד.
-We successfully shipped concurrent features to tens of thousands of components at Facebook, and in our experience, we've found that most React components “just work” without additional changes. We're committed to making sure this is a smooth upgrade for the entire community, so today we're announcing the React 18 Working Group.
+הוצאנו לפועל יכולות concurrent בעשרות אלפי קומפוננטות ב-Facebook, ובניסיון שלנו רוב קומפוננטות React "פשוט עובדות" בלי שינויים נוספים. אנחנו מחויבים לוודא שזה יהיה שדרוג חלק לכל הקהילה, ולכן אנחנו מכריזים היום על React 18 Working Group.
-## Working with the community {/*working-with-the-community*/}
+## עבודה עם הקהילה {/*working-with-the-community*/}
-We’re trying something new for this release: We've invited a panel of experts, developers, library authors, and educators from across the React community to participate in our [React 18 Working Group](https://github.com/reactwg/react-18) to provide feedback, ask questions, and collaborate on the release. We couldn't invite everyone we wanted to this initial, small group, but if this experiment works out, we hope there will be more in the future!
+בשחרור הזה אנחנו מנסים משהו חדש: הזמנו פאנל של מומחים, מפתחים, מחברי ספריות ומדריכים מכל קהילת React להשתתף ב-[React 18 Working Group](https://github.com/reactwg/react-18), לתת משוב, לשאול שאלות ולשתף פעולה סביב השחרור. לא הצלחנו להזמין את כל מי שרצינו לקבוצה הראשונית והקטנה הזו, אבל אם הניסוי יעבוד טוב אנחנו מקווים שיהיו עוד בהמשך.
-**The goal of the React 18 Working Group is to prepare the ecosystem for a smooth, gradual adoption of React 18 by existing applications and libraries.** The Working Group is hosted on [GitHub Discussions](https://github.com/reactwg/react-18/discussions) and is available for the public to read. Members of the working group can leave feedback, ask questions, and share ideas. The core team will also use the discussions repo to share our research findings. As the stable release gets closer, any important information will also be posted on this blog.
+**המטרה של React 18 Working Group היא להכין את האקו-סיסטם לאימוץ חלק והדרגתי של React 18 באפליקציות ובספריות קיימות.** ה-Working Group מתארח ב-[GitHub Discussions](https://github.com/reactwg/react-18/discussions), וכל הציבור יכול לקרוא אותו. חברי הקבוצה יכולים להשאיר משוב, לשאול שאלות ולשתף רעיונות. צוות הליבה גם ישתמש במאגר הדיונים כדי לשתף ממצאי מחקר. ככל שנתקרב לשחרור היציב, מידע חשוב יפורסם גם בבלוג הזה.
-For more information on upgrading to React 18, or additional resources about the release, see the [React 18 announcement post](https://github.com/reactwg/react-18/discussions/4).
+למידע נוסף על שדרוג ל-React 18 ומשאבים נוספים על השחרור, ראו את [פוסט ההכרזה על React 18](https://github.com/reactwg/react-18/discussions/4).
-## Accessing the React 18 Working Group {/*accessing-the-react-18-working-group*/}
+## גישה ל-React 18 Working Group {/*accessing-the-react-18-working-group*/}
-Everyone can read the discussions in the [React 18 Working Group repo](https://github.com/reactwg/react-18).
+כולם יכולים לקרוא את הדיונים ב-[מאגר React 18 Working Group](https://github.com/reactwg/react-18).
-Because we expect an initial surge of interest in the Working Group, only invited members will be allowed to create or comment on threads. However, the threads are fully visible to the public, so everyone has access to the same information. We believe this is a good compromise between creating a productive environment for working group members, while maintaining transparency with the wider community.
+מכיוון שאנחנו מצפים לגל עניין ראשוני, רק חברים מוזמנים יורשו ליצור או להגיב בשרשורים. עם זאת, השרשורים גלויים לגמרי לציבור, כך שלכולם יש גישה לאותו מידע. אנחנו מאמינים שזה איזון טוב בין יצירת סביבה פרודוקטיבית לחברי הקבוצה לבין שקיפות מלאה מול הקהילה הרחבה.
-As always, you can submit bug reports, questions, and general feedback to our [issue tracker](https://github.com/facebook/react/issues).
+כמו תמיד, אפשר לשלוח דיווחי באגים, שאלות ומשוב כללי ל-[issue tracker](https://github.com/facebook/react/issues) שלנו.
-## How to try React 18 Alpha today {/*how-to-try-react-18-alpha-today*/}
+## איך לנסות React 18 Alpha כבר היום {/*how-to-try-react-18-alpha-today*/}
-New alphas are [regularly published to npm using the `@alpha` tag](https://github.com/reactwg/react-18/discussions/9). These releases are built using the most recent commit to our main repo. When a feature or bugfix is merged, it will appear in an alpha the following weekday.
+גרסאות alpha חדשות [מתפרסמות באופן קבוע ל-npm עם התגית `@alpha`](https://github.com/reactwg/react-18/discussions/9). הגרסאות האלה נבנות מהקומיט האחרון במאגר הראשי שלנו. כשיכולת או תיקון באג מתמזגים, הם יופיעו ב-alpha ביום העבודה הבא.
-There may be significant behavioral or API changes between alpha releases. Please remember that **alpha releases are not recommended for user-facing, production applications**.
+ייתכנו שינויים משמעותיים בהתנהגות או ב-API בין שחרורי alpha. חשוב לזכור ש-**שחרורי alpha לא מומלצים לאפליקציות ייצור מול משתמשים.**
-## Projected React 18 release timeline {/*projected-react-18-release-timeline*/}
+## לוח זמנים משוער לשחרור React 18 {/*projected-react-18-release-timeline*/}
-We don't have a specific release date scheduled, but we expect it will take several months of feedback and iteration before React 18 is ready for most production applications.
+אין לנו כרגע תאריך שחרור ספציפי, אבל אנחנו מצפים שיידרשו כמה חודשים של משוב ואיטרציה לפני ש-React 18 תהיה מוכנה לרוב אפליקציות הייצור.
-* Library Alpha: Available today
-* Public Beta: At least several months
-* Release Candidate (RC): At least several weeks after Beta
-* General Availability: At least several weeks after RC
+* Library Alpha: זמין היום
+* Public Beta: לפחות כמה חודשים
+* Release Candidate (RC): לפחות כמה שבועות אחרי Beta
+* General Availability: לפחות כמה שבועות אחרי RC
-More details about our projected release timeline are [available in the Working Group](https://github.com/reactwg/react-18/discussions/9). We'll post updates on this blog when we're closer to a public release.
+פרטים נוספים על לוח הזמנים המשוער [זמינים ב-Working Group](https://github.com/reactwg/react-18/discussions/9). נפרסם עדכונים בבלוג הזה כשנתקרב לשחרור ציבורי.
diff --git a/src/content/blog/2021/12/17/react-conf-2021-recap.md b/src/content/blog/2021/12/17/react-conf-2021-recap.md
index 89e407af3..6430be44d 100644
--- a/src/content/blog/2021/12/17/react-conf-2021-recap.md
+++ b/src/content/blog/2021/12/17/react-conf-2021-recap.md
@@ -1,50 +1,50 @@
---
-title: "React Conf 2021 Recap"
+title: "סיכום React Conf 2021"
---
-December 17, 2021 by [Jesslyn Tannady](https://twitter.com/jtannady) and [Rick Hanlon](https://twitter.com/rickhanlonii)
+17 בדצמבר 2021 מאת [Jesslyn Tannady](https://twitter.com/jtannady) and [Rick Hanlon](https://twitter.com/rickhanlonii)
---
-Last week we hosted our 6th React Conf. In previous years, we've used the React Conf stage to deliver industry changing announcements such as [_React Native_](https://engineering.fb.com/2015/03/26/android/react-native-bringing-modern-web-techniques-to-mobile/) and [_React Hooks_](https://reactjs.org/docs/hooks-intro.html). This year, we shared our multi-platform vision for React, starting with the release of React 18 and gradual adoption of concurrent features.
+בשבוע שעבר אירחנו את React Conf השישי שלנו. בשנים קודמות השתמשנו בבמה של React Conf כדי למסור הכרזות ששינו את התעשייה, כמו [_React Native_](https://engineering.fb.com/2015/03/26/android/react-native-bringing-modern-web-techniques-to-mobile/) ו-[_React Hooks_](https://reactjs.org/docs/hooks-intro.html). השנה שיתפנו את החזון הרב-פלטפורמי שלנו ל-React, החל משחרור React 18 ואימוץ הדרגתי של יכולות concurrent.
---
-This was the first time React Conf was hosted online, and it was streamed for free, translated to 8 different languages. Participants from all over the world joined our conference Discord and the replay event for accessibility in all timezones. Over 50,000 people registered, with over 60,000 views of 19 talks, and 5,000 participants in Discord across both events.
+זו הייתה הפעם הראשונה ש-React Conf התארח אונליין, והוא שודר בחינם עם תרגום ל-8 שפות שונות. משתתפים מכל העולם הצטרפו ל-Discord של הכנס ולאירוע השידור החוזר, כדי לאפשר נגישות בכל אזורי הזמן. יותר מ-50,000 אנשים נרשמו, עם מעל 60,000 צפיות ב-19 הרצאות, ו-5,000 משתתפים ב-Discord בשני האירועים יחד.
-All the talks are [available to stream online](https://www.youtube.com/watch?v=FZ0cG47msEk&list=PLNG_1j3cPCaZZ7etkzWA7JfdmKWT0pMsa).
+כל ההרצאות [זמינות לצפייה אונליין](https://www.youtube.com/watch?v=FZ0cG47msEk&list=PLNG_1j3cPCaZZ7etkzWA7JfdmKWT0pMsa).
-Here’s a summary of what was shared on stage:
+הנה סיכום של מה שעלה על הבמה:
-## React 18 and concurrent features {/*react-18-and-concurrent-features*/}
+## React 18 ויכולות concurrent {/*react-18-and-concurrent-features*/}
-In the keynote, we shared our vision for the future of React starting with React 18.
+בהרצאת הפתיחה שיתפנו את החזון שלנו לעתיד React, שמתחיל ב-React 18.
-React 18 adds the long-awaited concurrent renderer and updates to Suspense without any major breaking changes. Apps can upgrade to React 18 and begin gradually adopting concurrent features with the amount of effort on par with any other major release.
+React 18 מוסיף את מנוע ה-renderer של concurrent שחיכו לו זמן רב, יחד עם עדכונים ל-Suspense, בלי שינויים שוברים משמעותיים. אפליקציות יכולות לשדרג ל-React 18 ולהתחיל לאמץ יכולות concurrent בהדרגה, במאמץ דומה לכל שחרור major אחר.
-**This means there is no concurrent mode, only concurrent features.**
+**זה אומר שאין concurrent mode, יש רק concurrent features.**
-In the keynote, we also shared our vision for Suspense, Server Components, new React working groups, and our long-term many-platform vision for React Native.
+בהרצאת הפתיחה שיתפנו גם את החזון שלנו לגבי Suspense, Server Components, קבוצות עבודה חדשות של React, וחזון רב-פלטפורמי ארוך טווח עבור React Native.
-Watch the full keynote from [Andrew Clark](https://twitter.com/acdlite), [Juan Tejada](https://twitter.com/_jstejada), [Lauren Tan](https://twitter.com/potetotes), and [Rick Hanlon](https://twitter.com/rickhanlonii) here:
+צפו בהרצאת הפתיחה המלאה של [Andrew Clark](https://twitter.com/acdlite), [Juan Tejada](https://twitter.com/_jstejada), [Lauren Tan](https://twitter.com/potetotes), and [Rick Hanlon](https://twitter.com/rickhanlonii):
-## React 18 for Application Developers {/*react-18-for-application-developers*/}
+## React 18 למפתחי אפליקציות {/*react-18-for-application-developers*/}
-In the keynote, we also announced that the React 18 RC is available to try now. Pending further feedback, this is the exact version of React that we will publish to stable early next year.
+בהרצאת הפתיחה הכרזנו גם ש-React 18 RC זמין לניסיון כבר עכשיו. בכפוף למשוב נוסף, זו תהיה בדיוק גרסת React שנפרסם כיציבה בתחילת השנה הבאה.
-To try the React 18 RC, upgrade your dependencies:
+כדי לנסות את React 18 RC, שדרגו את התלויות:
```bash
npm install react@rc react-dom@rc
```
-and switch to the new `createRoot` API:
+ועברו ל-API החדש של `createRoot`:
```js
// before
@@ -57,64 +57,64 @@ const root = ReactDOM.createRoot(container);
root.render(
);
```
-For a demo of upgrading to React 18, see [Shruti Kapoor](https://twitter.com/shrutikapoor08)’s talk here:
+להדגמה של שדרוג ל-React 18, ראו את ההרצאה של [Shruti Kapoor](https://twitter.com/shrutikapoor08):
-## Streaming Server Rendering with Suspense {/*streaming-server-rendering-with-suspense*/}
+## Streaming Server Rendering עם Suspense {/*streaming-server-rendering-with-suspense*/}
-React 18 also includes improvements to server-side rendering performance using Suspense.
+React 18 כולל גם שיפורים לביצועי רינדור צד שרת באמצעות Suspense.
-Streaming server rendering lets you generate HTML from React components on the server, and stream that HTML to your users. In React 18, you can use `Suspense` to break down your app into smaller independent units which can be streamed independently of each other without blocking the rest of the app. This means users will see your content sooner and be able to start interacting with it much faster.
+Streaming server rendering מאפשר לייצר HTML מקומפוננטות React בשרת, ולהזרים את ה-HTML הזה למשתמשים. ב-React 18 אפשר להשתמש ב-`Suspense` כדי לפרק את האפליקציה ליחידות קטנות ועצמאיות שאפשר להזרים בנפרד בלי לחסום את שאר האפליקציה. כלומר, משתמשים יראו תוכן מוקדם יותר ויוכלו להתחיל אינטראקציה הרבה יותר מהר.
-For a deep dive, see [Shaundai Person](https://twitter.com/shaundai)’s talk here:
+לצלילה עמוקה, ראו את ההרצאה של [Shaundai Person](https://twitter.com/shaundai):
-## The first React working group {/*the-first-react-working-group*/}
+## קבוצת העבודה הראשונה של React {/*the-first-react-working-group*/}
-For React 18, we created our first Working Group to collaborate with a panel of experts, developers, library maintainers, and educators. Together we worked to create our gradual adoption strategy and refine new APIs such as `useId`, `useSyncExternalStore`, and `useInsertionEffect`.
+עבור React 18 יצרנו את קבוצת העבודה הראשונה שלנו כדי לשתף פעולה עם פאנל של מומחים, מפתחים, מתחזקי ספריות ומדריכים. יחד בנינו את אסטרטגיית האימוץ ההדרגתי שלנו ושייפנו APIs חדשים כמו `useId`, `useSyncExternalStore`, ו-`useInsertionEffect`.
-For an overview of this work, see [Aakansha' Doshi](https://twitter.com/aakansha1216)'s talk:
+לסקירה של העבודה הזו, ראו את ההרצאה של [Aakansha' Doshi](https://twitter.com/aakansha1216):
-## React Developer Tooling {/*react-developer-tooling*/}
+## כלי פיתוח עבור React {/*react-developer-tooling*/}
-To support the new features in this release, we also announced the newly formed React DevTools team and a new Timeline Profiler to help developers debug their React apps.
+כדי לתמוך ביכולות החדשות של השחרור הזה, הכרזנו גם על צוות React DevTools החדש ועל Timeline Profiler חדש שיעזור למפתחים לדבג אפליקציות React.
-For more information and a demo of new DevTools features, see [Brian Vaughn](https://twitter.com/brian_d_vaughn)’s talk:
+למידע נוסף ולהדגמה של יכולות DevTools חדשות, ראו את ההרצאה של [Brian Vaughn](https://twitter.com/brian_d_vaughn):
-## React without memo {/*react-without-memo*/}
+## React בלי memo {/*react-without-memo*/}
-Looking further into the future, [Xuan Huang (黄玄)](https://twitter.com/Huxpro) shared an update from our React Labs research into an auto-memoizing compiler. Check out this talk for more information and a demo of the compiler prototype:
+במבט רחוק יותר לעתיד, [Xuan Huang (黄玄)](https://twitter.com/Huxpro) שיתף עדכון ממחקר React Labs שלנו על קומפיילר עם auto-memoization. לצפייה במידע נוסף ובהדגמה של אבטיפוס הקומפיילר:
-## React docs keynote {/*react-docs-keynote*/}
+## הרצאת תיעוד React {/*react-docs-keynote*/}
-[Rachel Nabors](https://twitter.com/rachelnabors) kicked off a section of talks about learning and designing with React with a keynote about our investment in React's new docs ([now shipped as react.dev](/blog/2023/03/16/introducing-react-dev)):
+[Rachel Nabors](https://twitter.com/rachelnabors) פתחה מקבץ הרצאות על למידה ועיצוב עם React, עם keynote על ההשקעה שלנו בתיעוד React החדש ([שכיום הושק כ-react.dev](/blog/2023/03/16/introducing-react-dev)):
-## And more... {/*and-more*/}
+## ועוד... {/*and-more*/}
-**We also heard talks on learning and designing with React:**
+**שמענו גם הרצאות על למידה ועיצוב עם React:**
* Debbie O'Brien: [Things I learnt from the new React docs](https://youtu.be/-7odLW_hG7s).
* Sarah Rainsberger: [Learning in the Browser](https://youtu.be/5X-WEQflCL0).
* Linton Ye: [The ROI of Designing with React](https://youtu.be/7cPWmID5XAk).
* Delba de Oliveira: [Interactive playgrounds with React](https://youtu.be/zL8cz2W0z34).
-**Talks from the Relay, React Native, and PyTorch teams:**
+**הרצאות מצוותי Relay, React Native ו-PyTorch:**
* Robert Balicki: [Re-introducing Relay](https://youtu.be/lhVGdErZuN4).
* Eric Rozell and Steven Moyes: [React Native Desktop](https://youtu.be/9L4FFrvwJwY).
* Roman Rädle: [On-device Machine Learning for React Native](https://youtu.be/NLj73vrc2I8)
-**And talks from the community on accessibility, tooling, and Server Components:**
+**וגם הרצאות קהילה על נגישות, כלי פיתוח ו-Server Components:**
* Daishi Kato: [React 18 for External Store Libraries](https://youtu.be/oPfSC5bQPR8).
* Diego Haz: [Building Accessible Components in React 18](https://youtu.be/dcm8fjBfro8).
@@ -122,36 +122,36 @@ Looking further into the future, [Xuan Huang (黄玄)](https://twitter.com/Huxpr
* Lyle Troxell: [UI tools for artists](https://youtu.be/b3l4WxipFsE).
* Helen Lin: [Hydrogen + React 18](https://youtu.be/HS6vIYkSNks).
-## Thank you {/*thank-you*/}
+## תודה {/*thank-you*/}
-This was our first year planning a conference ourselves, and we have a lot of people to thank.
+זו הייתה השנה הראשונה שבה תכננו כנס בעצמנו, ויש לנו הרבה אנשים להודות להם.
-First, thanks to all of our speakers [Aakansha Doshi](https://twitter.com/aakansha1216), [Andrew Clark](https://twitter.com/acdlite), [Brian Vaughn](https://twitter.com/brian_d_vaughn), [Daishi Kato](https://twitter.com/dai_shi), [Debbie O'Brien](https://twitter.com/debs_obrien), [Delba de Oliveira](https://twitter.com/delba_oliveira), [Diego Haz](https://twitter.com/diegohaz), [Eric Rozell](https://twitter.com/EricRozell), [Helen Lin](https://twitter.com/wizardlyhel), [Juan Tejada](https://twitter.com/_jstejada), [Lauren Tan](https://twitter.com/potetotes), [Linton Ye](https://twitter.com/lintonye), [Lyle Troxell](https://twitter.com/lyle), [Rachel Nabors](https://twitter.com/rachelnabors), [Rick Hanlon](https://twitter.com/rickhanlonii), [Robert Balicki](https://twitter.com/StatisticsFTW), [Roman Rädle](https://twitter.com/raedle), [Sarah Rainsberger](https://twitter.com/sarah11918), [Shaundai Person](https://twitter.com/shaundai), [Shruti Kapoor](https://twitter.com/shrutikapoor08), [Steven Moyes](https://twitter.com/moyessa), [Tafu Nakazaki](https://twitter.com/hawaiiman0), and [Xuan Huang (黄玄)](https://twitter.com/Huxpro).
+קודם כול תודה לכל הדוברים שלנו [Aakansha Doshi](https://twitter.com/aakansha1216), [Andrew Clark](https://twitter.com/acdlite), [Brian Vaughn](https://twitter.com/brian_d_vaughn), [Daishi Kato](https://twitter.com/dai_shi), [Debbie O'Brien](https://twitter.com/debs_obrien), [Delba de Oliveira](https://twitter.com/delba_oliveira), [Diego Haz](https://twitter.com/diegohaz), [Eric Rozell](https://twitter.com/EricRozell), [Helen Lin](https://twitter.com/wizardlyhel), [Juan Tejada](https://twitter.com/_jstejada), [Lauren Tan](https://twitter.com/potetotes), [Linton Ye](https://twitter.com/lintonye), [Lyle Troxell](https://twitter.com/lyle), [Rachel Nabors](https://twitter.com/rachelnabors), [Rick Hanlon](https://twitter.com/rickhanlonii), [Robert Balicki](https://twitter.com/StatisticsFTW), [Roman Rädle](https://twitter.com/raedle), [Sarah Rainsberger](https://twitter.com/sarah11918), [Shaundai Person](https://twitter.com/shaundai), [Shruti Kapoor](https://twitter.com/shrutikapoor08), [Steven Moyes](https://twitter.com/moyessa), [Tafu Nakazaki](https://twitter.com/hawaiiman0), and [Xuan Huang (黄玄)](https://twitter.com/Huxpro).
-Thanks to everyone who helped provide feedback on talks including [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Eli White](https://twitter.com/Eli_White), [Joe Savona](https://twitter.com/en_JS), [Lauren Tan](https://twitter.com/potetotes), [Rachel Nabors](https://twitter.com/rachelnabors), and [Tim Yung](https://twitter.com/yungsters).
+תודה לכל מי שעזרו לתת פידבק על ההרצאות, כולל [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Eli White](https://twitter.com/Eli_White), [Joe Savona](https://twitter.com/en_JS), [Lauren Tan](https://twitter.com/potetotes), [Rachel Nabors](https://twitter.com/rachelnabors), and [Tim Yung](https://twitter.com/yungsters).
-Thanks to [Lauren Tan](https://twitter.com/potetotes) for setting up the conference Discord and serving as our Discord admin.
+תודה ל-[Lauren Tan](https://twitter.com/potetotes) על הקמת Discord של הכנס ועל התפקיד כ-Discord admin שלנו.
-Thanks to [Seth Webster](https://twitter.com/sethwebster) for feedback on overall direction and making sure we were focused on diversity and inclusion.
+תודה ל-[Seth Webster](https://twitter.com/sethwebster) על משוב לגבי הכיוון הכללי ועל כך שווידא שנשארנו ממוקדים בגיוון והכלה.
-Thanks to [Rachel Nabors](https://twitter.com/rachelnabors) for spearheading our moderation effort, and [Aisha Blake](https://twitter.com/AishaBlake) for creating our moderation guide, leading our moderation team, training the translators and moderators, and helping to moderate both events.
+תודה ל-[Rachel Nabors](https://twitter.com/rachelnabors) על הובלת מאמץ המודרציה שלנו, ול-[Aisha Blake](https://twitter.com/AishaBlake) על יצירת מדריך המודרציה, הובלת צוות המודרציה, הכשרת המתרגמים והמודרטורים, וסיוע במודרציה של שני האירועים.
-Thanks to our moderators [Jesslyn Tannady](https://twitter.com/jtannady), [Suzie Grange](https://twitter.com/missuze), [Becca Bailey](https://twitter.com/beccaliz), [Luna Wei](https://twitter.com/lunaleaps), [Joe Previte](https://twitter.com/jsjoeio), [Nicola Corti](https://twitter.com/Cortinico), [Gijs Weterings](https://twitter.com/gweterings), [Claudio Procida](https://twitter.com/claudiopro), Julia Neumann, Mengdi Chen, Jean Zhang, Ricky Li, and [Xuan Huang (黄玄)](https://twitter.com/Huxpro).
+תודה למודרטורים שלנו [Jesslyn Tannady](https://twitter.com/jtannady), [Suzie Grange](https://twitter.com/missuze), [Becca Bailey](https://twitter.com/beccaliz), [Luna Wei](https://twitter.com/lunaleaps), [Joe Previte](https://twitter.com/jsjoeio), [Nicola Corti](https://twitter.com/Cortinico), [Gijs Weterings](https://twitter.com/gweterings), [Claudio Procida](https://twitter.com/claudiopro), Julia Neumann, Mengdi Chen, Jean Zhang, Ricky Li, and [Xuan Huang (黄玄)](https://twitter.com/Huxpro).
-Thanks to [Manjula Dube](https://twitter.com/manjula_dube), [Sahil Mhapsekar](https://twitter.com/apheri0), and Vihang Patel from [React India](https://www.reactindia.io/), and [Jasmine Xie](https://twitter.com/jasmine_xby), [QiChang Li](https://twitter.com/QCL15), and [YanLun Li](https://twitter.com/anneincoding) from [React China](https://twitter.com/ReactChina) for helping moderate our replay event and keep it engaging for the community.
+תודה ל-[Manjula Dube](https://twitter.com/manjula_dube), [Sahil Mhapsekar](https://twitter.com/apheri0), and Vihang Patel from [React India](https://www.reactindia.io/), ול-[Jasmine Xie](https://twitter.com/jasmine_xby), [QiChang Li](https://twitter.com/QCL15), and [YanLun Li](https://twitter.com/anneincoding) from [React China](https://twitter.com/ReactChina) על עזרה במודרציה של אירוע השידור החוזר ועל שמירה על מעורבות גבוהה בקהילה.
-Thanks to Vercel for publishing their [Virtual Event Starter Kit](https://vercel.com/virtual-event-starter-kit), which the conference website was built on, and to [Lee Robinson](https://twitter.com/leeerob) and [Delba de Oliveira](https://twitter.com/delba_oliveira) for sharing their experience running Next.js Conf.
+תודה ל-Vercel על פרסום [Virtual Event Starter Kit](https://vercel.com/virtual-event-starter-kit), שעליו נבנה אתר הכנס, ול-[Lee Robinson](https://twitter.com/leeerob) ו-[Delba de Oliveira](https://twitter.com/delba_oliveira) על שיתוף ניסיון מהפקת Next.js Conf.
-Thanks to [Leah Silber](https://twitter.com/wifelette) for sharing her experience running conferences, learnings from running [RustConf](https://rustconf.com/), and for her book [Event Driven](https://leanpub.com/eventdriven/) and the advice it contains for running conferences.
+תודה ל-[Leah Silber](https://twitter.com/wifelette) על שיתוף הניסיון שלה בהפקת כנסים, תובנות מ-[RustConf](https://rustconf.com/), ועל הספר שלה [Event Driven](https://leanpub.com/eventdriven/) והעצות שבו על הפקת כנסים.
-Thanks to [Kevin Lewis](https://twitter.com/_phzn) and [Rachel Nabors](https://twitter.com/rachelnabors) for sharing their experience running Women of React Conf.
+תודה ל-[Kevin Lewis](https://twitter.com/_phzn) ול-[Rachel Nabors](https://twitter.com/rachelnabors) על שיתוף ניסיון מהפקת Women of React Conf.
-Thanks to [Aakansha Doshi](https://twitter.com/aakansha1216), [Laurie Barth](https://twitter.com/laurieontech), [Michael Chan](https://twitter.com/chantastic), and [Shaundai Person](https://twitter.com/shaundai) for their advice and ideas throughout planning.
+תודה ל-[Aakansha Doshi](https://twitter.com/aakansha1216), [Laurie Barth](https://twitter.com/laurieontech), [Michael Chan](https://twitter.com/chantastic), and [Shaundai Person](https://twitter.com/shaundai) על העצות והרעיונות לאורך כל התכנון.
-Thanks to [Dan Lebowitz](https://twitter.com/lebo) for help designing and building the conference website and tickets.
+תודה ל-[Dan Lebowitz](https://twitter.com/lebo) על עזרה בעיצוב ובניית אתר הכנס והכרטיסים.
-Thanks to Laura Podolak Waddell, Desmond Osei-Acheampong, Mark Rossi, Josh Toberman and others on the Facebook Video Productions team for recording the videos for the Keynote and Meta employee talks.
+תודה ל-Laura Podolak Waddell, Desmond Osei-Acheampong, Mark Rossi, Josh Toberman ואחרים מצוות Facebook Video Productions על הקלטת הסרטונים ל-Keynote ולהרצאות עובדי Meta.
-Thanks to our partner HitPlay for helping to organize the conference, editing all the videos in the stream, translating all the talks, and moderating the Discord in multiple languages.
+תודה לשותפים שלנו ב-HitPlay על עזרה בארגון הכנס, עריכת כל סרטוני השידור, תרגום כל ההרצאות ומודרציה של Discord בכמה שפות.
-Finally, thanks to all of our participants for making this a great React Conf!
+ולבסוף, תודה לכל המשתתפים שלנו שהפכו את זה ל-React Conf נהדר.
diff --git a/src/content/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.md b/src/content/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.md
index 5e8456ea3..310f9bbd2 100644
--- a/src/content/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.md
+++ b/src/content/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.md
@@ -1,79 +1,79 @@
---
-title: "React Labs: What We've Been Working On – June 2022"
+title: "React Labs: על מה עבדנו - יוני 2022"
---
-June 15, 2022 by [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Jan Kassens](https://twitter.com/kassens), [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Luna Ruan](https://twitter.com/lunaruan), [Mengdi Chen](https://twitter.com/mengdi_en), [Rick Hanlon](https://twitter.com/rickhanlonii), [Robert Zhang](https://twitter.com/jiaxuanzhang01), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Xuan Huang](https://twitter.com/Huxpro)
+15 ביוני 2022 מאת [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Jan Kassens](https://twitter.com/kassens), [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Luna Ruan](https://twitter.com/lunaruan), [Mengdi Chen](https://twitter.com/mengdi_en), [Rick Hanlon](https://twitter.com/rickhanlonii), [Robert Zhang](https://twitter.com/jiaxuanzhang01), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Xuan Huang](https://twitter.com/Huxpro)
---
-[React 18](/blog/2022/03/29/react-v18) was years in the making, and with it brought valuable lessons for the React team. Its release was the result of many years of research and exploring many paths. Some of those paths were successful; many more were dead-ends that led to new insights. One lesson we’ve learned is that it’s frustrating for the community to wait for new features without having insight into these paths that we’re exploring.
+[React 18](/blog/2022/03/29/react-v18) נבנתה במשך שנים, ובדרך סיפקה לצוות React לא מעט שיעורים חשובים. השחרור שלה היה תוצאה של הרבה שנות מחקר ובדיקה של כיוונים רבים. חלק מהכיוונים הצליחו; הרבה אחרים היו מבוי סתום שהוביל לתובנות חדשות. אחד הדברים שלמדנו הוא שמאוד מתסכל עבור הקהילה להמתין ליכולות חדשות בלי חשיפה לכיווני החשיבה שאנחנו בודקים.
---
-We typically have a number of projects being worked on at any time, ranging from the more experimental to the clearly defined. Looking ahead, we’d like to start regularly sharing more about what we’ve been working on with the community across these projects.
+בכל רגע נתון יש לנו כמה פרויקטים בעבודה, מטווח ניסיוני מאוד ועד דברים עם הגדרה ברורה. קדימה, אנחנו רוצים להתחיל לשתף באופן קבוע יותר במה שעבדנו עליו מול הקהילה בכל הפרויקטים האלה.
-To set expectations, this is not a roadmap with clear timelines. Many of these projects are under active research and are difficult to put concrete ship dates on. They may possibly never even ship in their current iteration depending on what we learn. Instead, we want to share with you the problem spaces we’re actively thinking about, and what we’ve learned so far.
+כדי לתאם ציפיות: זו לא מפת דרכים עם לוחות זמנים ברורים. הרבה מהפרויקטים האלה עדיין במחקר פעיל וקשה להצמיד להם תאריך שחרור קונקרטי. ייתכן שחלקם בכלל לא יגיעו לשחרור בצורה הנוכחית, תלוי במה שנלמד. במקום זה, אנחנו רוצים לשתף אתכם בתחומי הבעיה שאנחנו חושבים עליהם באופן פעיל ומה למדנו עד כה.
## Server Components {/*server-components*/}
-We announced an [experimental demo of React Server Components](https://legacy.reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html) (RSC) in December 2020. Since then we’ve been finishing up its dependencies in React 18, and working on changes inspired by experimental feedback.
+הכרזנו על [דמו ניסיוני של React Server Components](https://legacy.reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html) (RSC) בדצמבר 2020. מאז סיימנו להשלים את התלויות שלהם ב-React 18, ועבדנו על שינויים בהשראת משוב מניסויים.
-In particular, we’re abandoning the idea of having forked I/O libraries (eg react-fetch), and instead adopting an async/await model for better compatibility. This doesn’t technically block RSC’s release because you can also use routers for data fetching. Another change is that we’re also moving away from the file extension approach in favor of [annotating boundaries](https://github.com/reactjs/rfcs/pull/189#issuecomment-1116482278).
+בפרט, אנחנו נוטשים את הרעיון של ספריות I/O מפוצלות (למשל react-fetch), ובמקום זאת מאמצים מודל async/await לתאימות טובה יותר. זה לא חוסם טכנית את שחרור RSC כי אפשר להשתמש גם בראוטרים לשליפת נתונים. שינוי נוסף הוא שאנחנו מתרחקים גם מגישת סיומות קבצים לטובת [תיוג גבולות](https://github.com/reactjs/rfcs/pull/189#issuecomment-1116482278).
-We’re working together with Vercel and Shopify to unify bundler support for shared semantics in both Webpack and Vite. Before launch, we want to make sure that the semantics of RSCs are the same across the whole React ecosystem. This is the major blocker for reaching stable.
+אנחנו עובדים יחד עם Vercel ו-Shopify כדי לאחד תמיכה בבאנדלרים עבור סמנטיקה משותפת גם ב-Webpack וגם ב-Vite. לפני ההשקה, חשוב לנו לוודא שסמנטיקת ה-RSC זהה בכל אקו-סיסטם React. זה החסם המרכזי בדרך ליציבות.
-## Asset Loading {/*asset-loading*/}
+## טעינת נכסים {/*asset-loading*/}
-Currently, assets like scripts, external styles, fonts, and images are typically preloaded and loaded using external systems. This can make it tricky to coordinate across new environments like streaming, Server Components, and more.
-We’re looking at adding APIs to preload and load deduplicated external assets through React APIs that work in all React environments.
+כיום נכסים כמו סקריפטים, סגנונות חיצוניים, פונטים ותמונות נטענים לרוב דרך מערכות חיצוניות. זה יכול להקשות על תיאום מול סביבות חדשות כמו streaming, Server Components ועוד.
+אנחנו בוחנים הוספת APIs ל-preload ו-load של נכסים חיצוניים בצורה deduplicated דרך APIs של React שעובדים בכל סביבות React.
-We’re also looking at having these support Suspense so you can have images, CSS, and fonts that block display until they’re loaded but don’t block streaming and concurrent rendering. This can help avoid [“popcorning“](https://twitter.com/sebmarkbage/status/1516852731251724293) as the visuals pop and layout shifts.
+אנחנו גם בוחנים תמיכה ב-Suspense כדי שתמונות, CSS ופונטים יוכלו לחסום תצוגה עד שנטענים, אבל בלי לחסום streaming ו-concurrent rendering. זה יכול לסייע במניעת ["popcorning"](https://twitter.com/sebmarkbage/status/1516852731251724293) שבו המראה קופץ ומשתנה.
-## Static Server Rendering Optimizations {/*static-server-rendering-optimizations*/}
+## אופטימיזציות לרינדור סטטי בשרת {/*static-server-rendering-optimizations*/}
-Static Site Generation (SSG) and Incremental Static Regeneration (ISR) are great ways to get performance for cacheable pages, but we think we can add features to improve performance of dynamic Server Side Rendering (SSR) – especially when most but not all of the content is cacheable. We're exploring ways to optimize server rendering utilizing compilation and static passes.
+Static Site Generation (SSG) ו-Incremental Static Regeneration (ISR) הן דרכים מצוינות להשיג ביצועים טובים עבור דפים שניתנים לקאש, אבל אנחנו חושבים שאפשר להוסיף יכולות לשיפור ביצועים גם עבור Server Side Rendering (SSR) דינמי, במיוחד כשהתוכן ברובו ניתן לקאש אבל לא כולו. אנחנו בוחנים דרכים לאופטם רינדור שרת בעזרת קומפילציה ומעברים סטטיים.
## React Optimizing Compiler {/*react-compiler*/}
-We gave an [early preview](https://www.youtube.com/watch?v=lGEMwh32soc) of React Forget at React Conf 2021. It’s a compiler that automatically generates the equivalent of `useMemo` and `useCallback` calls to minimize the cost of re-rendering, while retaining React’s programming model.
+נתנו [הצצה מוקדמת](https://www.youtube.com/watch?v=lGEMwh32soc) ל-React Forget ב-React Conf 2021. זה קומפיילר שמייצר אוטומטית את המקבילה לקריאות `useMemo` ו-`useCallback`, כדי למזער עלות רינדור מחדש ועדיין לשמר את מודל התכנות של React.
-Recently, we finished a rewrite of the compiler to make it more reliable and capable. This new architecture allows us to analyze and memoize more complex patterns such as the use of [local mutations](/learn/keeping-components-pure#local-mutation-your-components-little-secret), and opens up many new compile-time optimization opportunities beyond just being on par with memoization Hooks.
+לאחרונה סיימנו שכתוב של הקומפיילר כדי להפוך אותו לאמין ומסוגל יותר. הארכיטקטורה החדשה מאפשרת לנו לנתח ולעשות memoization לדפוסים מורכבים יותר, למשל שימוש ב-[local mutations](/learn/keeping-components-pure#local-mutation-your-components-little-secret), ופותחת הזדמנויות רבות לאופטימיזציה בזמן קומפילציה מעבר להתאמה בלבד ל-Hooks של memoization.
-We’re also working on a playground for exploring many aspects of the compiler. While the goal of the playground is to make development of the compiler easier, we think that it will make it easier to try it out and build intuition for what the compiler does. It reveals various insights into how it works under the hood, and live renders the compiler’s outputs as you type. This will be shipped together with the compiler when it’s released.
+אנחנו גם עובדים על playground לחקירת היבטים שונים של הקומפיילר. המטרה העיקרית שלו היא להקל על פיתוח הקומפיילר, אבל אנחנו חושבים שהוא גם יקל לנסות אותו ולבנות אינטואיציה למה הוא עושה. הוא מציג תובנות לגבי איך הוא עובד מאחורי הקלעים, ומרנדר בזמן אמת את הפלט של הקומפיילר בזמן ההקלדה. זה ישוחרר יחד עם הקומפיילר כשיהיה מוכן.
## Offscreen {/*offscreen*/}
-Today, if you want to hide and show a component, you have two options. One is to add or remove it from the tree completely. The problem with this approach is that the state of your UI is lost each time you unmount, including state stored in the DOM, like scroll position.
+היום, אם רוצים להסתיר ולהציג קומפוננטה, יש שתי אפשרויות. אחת היא להוסיף או להסיר אותה לגמרי מהעץ. הבעיה בגישה הזו היא שמצב ה-UI הולך לאיבוד בכל unmount, כולל מצב שנשמר ב-DOM כמו מיקום גלילה.
-The other option is to keep the component mounted and toggle the appearance visually using CSS. This preserves the state of your UI, but it comes at a performance cost, because React must keep rendering the hidden component and all of its children whenever it receives new updates.
+האפשרות השנייה היא להשאיר את הקומפוננטה mounted ולהחליף את התצוגה באופן ויזואלי עם CSS. זה שומר על מצב ה-UI, אבל מגיע עם עלות ביצועים כי React חייב להמשיך לרנדר את הקומפוננטה המוסתרת ואת כל ילדיה בכל עדכון חדש.
-Offscreen introduces a third option: hide the UI visually, but deprioritize its content. The idea is similar in spirit to the `content-visibility` CSS property: when content is hidden, it doesn't need to stay in sync with the rest of the UI. React can defer the rendering work until the rest of the app is idle, or until the content becomes visible again.
+Offscreen מוסיף אפשרות שלישית: להסתיר את ה-UI ויזואלית, אבל להוריד עדיפות לתוכן שלו. הרעיון דומה ל-`content-visibility` ב-CSS: כשהתוכן מוסתר, הוא לא חייב להישאר מסונכרן עם שאר ה-UI. React יכול לדחות את עבודת הרינדור עד ששאר האפליקציה פנויה או עד שהתוכן שוב גלוי.
-Offscreen is a low level capability that unlocks high level features. Similar to React's other concurrent features like `startTransition`, in most cases you won't interact with the Offscreen API directly, but instead via an opinionated framework to implement patterns like:
+Offscreen הוא יכולת low-level שמאפשרת יכולות high-level. בדומה ליכולות concurrent אחרות של React כמו `startTransition`, ברוב המקרים לא תעבדו ישירות עם Offscreen API, אלא דרך framework עם דעה ברורה שמממש דפוסים כמו:
-* **Instant transitions.** Some routing frameworks already prefetch data to speed up subsequent navigations, like when hovering over a link. With Offscreen, they'll also be able to prerender the next screen in the background.
-* **Reusable state.** Similarly, when navigating between routes or tabs, you can use Offscreen to preserve the state of the previous screen so you can switch back and pick up where you left off.
-* **Virtualized list rendering.** When displaying large lists of items, virtualized list frameworks will prerender more rows than are currently visible. You can use Offscreen to prerender the hidden rows at a lower priority than the visible items in the list.
-* **Backgrounded content.** We're also exploring a related feature for deprioritizing content in the background without hiding it, like when displaying a modal overlay.
+* **Instant transitions.** חלק מ-frameworks לניתוב כבר מבצעים prefetch לנתונים כדי להאיץ ניווטים הבאים, למשל בזמן hover על קישור. עם Offscreen, הם יוכלו גם prerender למסך הבא ברקע.
+* **Reusable state.** באופן דומה, בניווט בין ראוטים או טאבים, אפשר להשתמש ב-Offscreen כדי לשמור את מצב המסך הקודם כדי לחזור ולהמשיך מהמקום שבו הפסקתם.
+* **Virtualized list rendering.** כשמציגים רשימות גדולות של פריטים, frameworks של רשימות וירטואליות עושים prerender ליותר שורות מאלה שכרגע גלויות. אפשר להשתמש ב-Offscreen כדי לעשות prerender לשורות מוסתרות בעדיפות נמוכה יותר מהפריטים הגלויים.
+* **Backgrounded content.** אנחנו בוחנים גם יכולת קשורה להורדת עדיפות לתוכן שרץ ברקע בלי להסתיר אותו, למשל כאשר מוצגת שכבת modal מעל.
## Transition Tracing {/*transition-tracing*/}
-Currently, React has two profiling tools. The [original Profiler](https://legacy.reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html) shows an overview of all the commits in a profiling session. For each commit, it also shows all components that rendered and the amount of time it took for them to render. We also have a beta version of a [Timeline Profiler](https://github.com/reactwg/react-18/discussions/76) introduced in React 18 that shows when components schedule updates and when React works on these updates. Both of these profilers help developers identify performance problems in their code.
+כרגע יש ל-React שני כלי profiling. ה-[Profiler המקורי](https://legacy.reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html) מציג סקירה של כל ה-commits בסשן profiling. לכל commit הוא מציג גם את כל הקומפוננטות שרונדרו וכמה זמן זה לקח. בנוסף יש לנו גרסת beta של [Timeline Profiler](https://github.com/reactwg/react-18/discussions/76) שנוספה ב-React 18, שמציגה מתי קומפוננטות מתזמנות עדכונים ומתי React עובד עליהם. שני הכלים האלו עוזרים לזהות בעיות ביצועים בקוד.
-We’ve realized that developers don’t find knowing about individual slow commits or components out of context that useful. It’s more useful to know about what actually causes the slow commits. And that developers want to be able to track specific interactions (eg a button click, an initial load, or a page navigation) to watch for performance regressions and to understand why an interaction was slow and how to fix it.
+הבנו שמפתחים לא תמיד מקבלים ערך גדול מידע על commits איטיים או קומפוננטות איטיות בלי הקשר. יותר מועיל להבין מה בפועל גורם ל-commits האיטיים. בנוסף, מפתחים רוצים לעקוב אחרי אינטראקציות ספציפיות (למשל לחיצה על כפתור, טעינה ראשונית או ניווט עמוד) כדי לזהות רגרסיות ביצועים ולהבין למה אינטראקציה הייתה איטית ואיך לתקן.
-We previously tried to solve this issue by creating an [Interaction Tracing API](https://gist.github.com/bvaughn/8de925562903afd2e7a12554adcdda16), but it had some fundamental design flaws that reduced the accuracy of tracking why an interaction was slow and sometimes resulted in interactions never ending. We ended up [removing this API](https://github.com/facebook/react/pull/20037) because of these issues.
+ניסינו בעבר לפתור את זה עם [Interaction Tracing API](https://gist.github.com/bvaughn/8de925562903afd2e7a12554adcdda16), אבל היו לו פגמי תכנון בסיסיים שפגעו בדיוק של מעקב אחר מקור האיטיות, ולעיתים גם גרמו לכך שאינטראקציות לא הסתיימו לעולם. בסוף [הסרנו את ה-API הזה](https://github.com/facebook/react/pull/20037) בגלל הבעיות האלה.
-We are working on a new version for the Interaction Tracing API (tentatively called Transition Tracing because it is initiated via `startTransition`) that solves these problems.
+אנחנו עובדים על גרסה חדשה ל-Interaction Tracing API (כרגע בשם זמני Transition Tracing כי הוא מתחיל דרך `startTransition`) שפותרת את הבעיות האלה.
-## New React Docs {/*new-react-docs*/}
+## תיעוד React החדש {/*new-react-docs*/}
-Last year, we announced the beta version of the new React documentation website ([later shipped as react.dev](/blog/2023/03/16/introducing-react-dev)) of the new React documentation website. The new learning materials teach Hooks first and has new diagrams, illustrations, as well as many interactive examples and challenges. We took a break from that work to focus on the React 18 release, but now that React 18 is out, we’re actively working to finish and ship the new documentation.
+בשנה שעברה הכרזנו על גרסת beta של אתר התיעוד החדש של React ([ששוחרר בהמשך כ-react.dev](/blog/2023/03/16/introducing-react-dev)). חומרי הלימוד החדשים מלמדים קודם Hooks וכוללים דיאגרמות ואיורים חדשים, וגם הרבה דוגמאות ואתגרים אינטראקטיביים. עצרנו זמנית את העבודה הזו כדי להתמקד בשחרור React 18, אבל עכשיו כש-React 18 יצא, חזרנו לעבוד באופן פעיל כדי להשלים ולשחרר את התיעוד החדש.
-We are currently writing a detailed section about effects, as we’ve heard that is one of the more challenging topics for both new and experienced React users. [Synchronizing with Effects](/learn/synchronizing-with-effects) is the first published page in the series, and there are more to come in the following weeks. When we first started writing a detailed section about effects, we’ve realized that many common effect patterns can be simplified by adding a new primitive to React. We’ve shared some initial thoughts on that in the [useEvent RFC](https://github.com/reactjs/rfcs/pull/220). It is currently in early research, and we are still iterating on the idea. We appreciate the community’s comments on the RFC so far, as well as the [feedback](https://github.com/reactjs/reactjs.org/issues/3308) and contributions to the ongoing documentation rewrite. We’d specifically like to thank [Harish Kumar](https://github.com/harish-sethuraman) for submitting and reviewing many improvements to the new website implementation.
+כרגע אנחנו כותבים סעיף מפורט על effects, כי שמענו שזה אחד הנושאים המאתגרים ביותר גם למשתמשי React חדשים וגם למנוסים. [Synchronizing with Effects](/learn/synchronizing-with-effects) הוא הדף הראשון בסדרה שפורסם, ועוד דפים יגיעו בשבועות הקרובים. כשהתחלנו לכתוב סעיף מפורט על effects, הבנו שניתן לפשט דפוסים נפוצים רבים על ידי הוספת primitive חדש ל-React. שיתפנו מחשבות ראשוניות על כך ב-[useEvent RFC](https://github.com/reactjs/rfcs/pull/220). כרגע זה עדיין במחקר מוקדם ואנחנו ממשיכים באיטרציה על הרעיון. אנחנו מעריכים מאוד את תגובות הקהילה ל-RFC עד כה, וגם את ה-[feedback](https://github.com/reactjs/reactjs.org/issues/3308) והתרומות לשכתוב התיעוד המתמשך. אנחנו רוצים להודות במיוחד ל-[Harish Kumar](https://github.com/harish-sethuraman) על שליחת ובדיקת שיפורים רבים למימוש האתר החדש.
-*Thanks to [Sophie Alpert](https://twitter.com/sophiebits) for reviewing this blog post!*
+*תודה ל-[Sophie Alpert](https://twitter.com/sophiebits) על סקירת הפוסט הזה!*
diff --git a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md
index 1f6b911e1..4fd877c41 100644
--- a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md
+++ b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md
@@ -1,14 +1,14 @@
---
-title: "React Labs: What We've Been Working On – March 2023"
+title: "React Labs: על מה עבדנו - מרץ 2023"
---
-March 22, 2023 by [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite)
+22 במרץ 2023 מאת [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite)
---
-In React Labs posts, we write about projects in active research and development. We've made significant progress on them since our [last update](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022), and we'd like to share what we learned.
+בפוסטים של React Labs אנחנו כותבים על פרויקטים במחקר ופיתוח פעילים. מאז [העדכון הקודם](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022) הייתה התקדמות משמעותית, ורצינו לשתף מה למדנו.
@@ -16,87 +16,87 @@ In React Labs posts, we write about projects in active research and development.
## React Server Components {/*react-server-components*/}
-React Server Components (or RSC) is a new application architecture designed by the React team.
+React Server Components (או RSC) היא ארכיטקטורת אפליקציה חדשה שתוכננה על ידי צוות React.
-We've first shared our research on RSC in an [introductory talk](/blog/2020/12/21/data-fetching-with-react-server-components) and an [RFC](https://github.com/reactjs/rfcs/pull/188). To recap them, we are introducing a new kind of component--Server Components--that run ahead of time and are excluded from your JavaScript bundle. Server Components can run during the build, letting you read from the filesystem or fetch static content. They can also run on the server, letting you access your data layer without having to build an API. You can pass data by props from Server Components to the interactive Client Components in the browser.
+שיתפנו לראשונה את המחקר על RSC ב-[הרצאת מבוא](/blog/2020/12/21/data-fetching-with-react-server-components) וב-[RFC](https://github.com/reactjs/rfcs/pull/188). בקצרה: אנחנו מציגים סוג חדש של קומפוננטות, Server Components, שרצות מראש ולא נכללות בחבילת ה-JavaScript של הלקוח. הן יכולות לרוץ בזמן build ולקרוא ממערכת הקבצים או לטעון תוכן סטטי. הן יכולות גם לרוץ בשרת, כך שאפשר לגשת לשכבת הנתונים בלי לבנות API נפרד. נתונים עוברים דרך props מ-Server Components ל-Client Components אינטראקטיביות בדפדפן.
-RSC combines the simple "request/response" mental model of server-centric Multi-Page Apps with the seamless interactivity of client-centric Single-Page Apps, giving you the best of both worlds.
+RSC משלבת את המודל הפשוט של "request/response" מאפליקציות Multi-Page ממוקדות-שרת, עם האינטראקטיביות החלקה של Single-Page Apps ממוקדות-לקוח, כדי לקבל את הטוב משני העולמות.
-Since our last update, we have merged the [React Server Components RFC](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) to ratify the proposal. We resolved outstanding issues with the [React Server Module Conventions](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) proposal, and reached consensus with our partners to go with the `"use client"` convention. These documents also act as specification for what an RSC-compatible implementation should support.
+מאז העדכון האחרון מיזגנו את [React Server Components RFC](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) כדי לאשרר את ההצעה. פתרנו נושאים פתוחים סביב [React Server Module Conventions](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md), והגענו להסכמה עם השותפים לאמץ את קונבנציית `"use client"`. המסמכים האלה משמשים גם כמפרט לתמיכה שנדרשת ממימוש תואם-RSC.
-The biggest change is that we introduced [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) as the primary way to do data fetching from Server Components. We also plan to support data loading from the client by introducing a new Hook called `use` that unwraps Promises. Although we can't support `async / await` in arbitrary components in client-only apps, we plan to add support for it when you structure your client-only app similar to how RSC apps are structured.
+השינוי הגדול ביותר הוא אימוץ [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) כדרך הראשית לטעינת נתונים מתוך Server Components. בנוסף, אנחנו מתכננים לתמוך בטעינת נתונים מצד הלקוח דרך Hook חדש בשם `use` שפורס Promises. אמנם לא ניתן לתמוך ב-`async / await` בקומפוננטות שרירותיות באפליקציות client-only, אבל אנחנו מתכננים לתמוך בזה כאשר המבנה של האפליקציה דומה למבנה של אפליקציות RSC.
-Now that we have data fetching pretty well sorted, we're exploring the other direction: sending data from the client to the server, so that you can execute database mutations and implement forms. We're doing this by letting you pass Server Action functions across the server/client boundary, which the client can then call, providing seamless RPC. Server Actions also give you progressively enhanced forms before JavaScript loads.
+אחרי שתחום טעינת הנתונים התייצב יחסית, אנחנו בוחנים גם את הכיוון ההפוך: שליחת נתונים מהלקוח לשרת, כדי לבצע database mutations ולממש טפסים. אנחנו עושים זאת על ידי העברת פונקציות Server Action דרך הגבול בין שרת ללקוח, כך שהלקוח יכול לקרוא להן וליהנות מ-RPC חלק. Server Actions מאפשרות גם progressive enhancement לטפסים עוד לפני טעינת JavaScript.
-React Server Components has shipped in [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). This showcases a deep integration of a router that really buys into RSC as a primitive, but it's not the only way to build a RSC-compatible router and framework. There's a clear separation for features provided by the RSC spec and implementation. React Server Components is meant as a spec for components that work across compatible React frameworks.
+React Server Components כבר נשלחה ב-[Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). זה מדגים אינטגרציה עמוקה של router שמאמץ את RSC כ-prmitive מרכזי, אבל זו לא הדרך היחידה לבנות router/framework תואמי-RSC. יש הפרדה ברורה בין יכולות שניתנות מהמפרט והיישום של RSC. React Server Components מיועדת להיות מפרט לקומפוננטות שעובדות בין frameworks תואמים.
-We generally recommend using an existing framework, but if you need to build your own custom framework, it is possible. Building your own RSC-compatible framework is not as easy as we'd like it to be, mainly due to the deep bundler integration needed. The current generation of bundlers are great for use on the client, but they weren't designed with first-class support for splitting a single module graph between the server and the client. This is why we're now partnering directly with bundler developers to get the primitives for RSC built-in.
+באופן כללי אנחנו ממליצים להשתמש ב-framework קיים, אבל אם צריך אפשר לבנות framework מותאם אישית. בניית framework תואם-RSC עדיין מורכבת יותר ממה שהיינו רוצים, בעיקר בגלל אינטגרציית bundler עמוקה שנדרשת. הדור הנוכחי של bundlers מצוין ללקוח, אבל לא תוכנן עם תמיכה מדרגה ראשונה בפיצול module graph יחיד בין שרת ללקוח. לכן אנחנו עובדים ישירות עם מפתחי bundlers כדי להכניס primitives מובנים ל-RSC.
## Asset Loading {/*asset-loading*/}
-[Suspense](/reference/react/Suspense) lets you specify what to display on the screen while the data or code for your components is still being loaded. This lets your users progressively see more content while the page is loading as well as during the router navigations that load more data and code. However, from the user's perspective, data loading and rendering do not tell the whole story when considering whether new content is ready. By default, browsers load stylesheets, fonts, and images independently, which can lead to UI jumps and consecutive layout shifts.
+[`Suspense`](/reference/react/Suspense) מאפשרת להגדיר מה להציג בזמן שהנתונים או הקוד של הקומפוננטות עדיין נטענים. כך משתמשים רואים יותר ויותר תוכן בהדרגה בזמן טעינת העמוד וגם בזמן ניווטים ב-router שטוענים עוד נתונים וקוד. אבל מנקודת מבט המשתמש, טעינת נתונים ורינדור לא מספרים את כל הסיפור לגבי מוכנות התוכן. כברירת מחדל, דפדפנים טוענים stylesheets, fonts ותמונות בנפרד, מה שעלול לגרום לקפיצות UI ושינויי layout עוקבים.
-We're working to fully integrate Suspense with the loading lifecycle of stylesheets, fonts, and images, so that React takes them into account to determine whether the content is ready to be displayed. Without any change to the way you author your React components, updates will behave in a more coherent and pleasing manner. As an optimization, we will also provide a manual way to preload assets like fonts directly from components.
+אנחנו עובדים על אינטגרציה מלאה של Suspense עם מחזור הטעינה של stylesheets, fonts ותמונות, כך ש-React תביא אותם בחשבון כדי לקבוע מתי התוכן באמת מוכן להצגה. בלי לשנות את אופן הכתיבה של הקומפוננטות שלכם, העדכונים ירגישו קוהרנטיים ונעימים יותר. כאופטימיזציה, נספק גם דרך ידנית לבצע preload למשאבים כמו fonts ישירות מתוך קומפוננטות.
-We are currently implementing these features and will have more to share soon.
+היכולות האלה כרגע במימוש, ונשתף עוד בקרוב.
## Document Metadata {/*document-metadata*/}
-Different pages and screens in your app may have different metadata like the `
` tag, description, and other `<meta>` tags specific to this screen. From the maintenance perspective, it's more scalable to keep this information close to the React component for that page or screen. However, the HTML tags for this metadata need to be in the document `<head>` which is typically rendered in a component at the very root of your app.
+עמודים ומסכים שונים באפליקציה עשויים לדרוש metadata שונה, כמו תגית `<title>`, תיאור, ותגיות `<meta>` נוספות. מבחינת תחזוקה, עדיף לשמור מידע כזה קרוב לקומפוננטת React של אותו עמוד/מסך. אבל בפועל תגיות HTML הללו חייבות להיות בתוך `<head>` של המסמך, שבדרך כלל נרנדר מקומפוננטה בשורש האפליקציה.
-Today, people solve this problem with one of the two techniques.
+היום פותרים את זה לרוב באחת משתי דרכים.
-One technique is to render a special third-party component that moves `<title>`, `<meta>`, and other tags inside it into the document `<head>`. This works for major browsers but there are many clients which do not run client-side JavaScript, such as Open Graph parsers, and so this technique is not universally suitable.
+דרך אחת היא לרנדר קומפוננטת צד-שלישי מיוחדת שמעבירה `<title>`, `<meta>` ותגיות נוספות ל-`<head>`. זה עובד בדפדפנים מרכזיים, אבל יש הרבה לקוחות שלא מריצים JavaScript בצד הלקוח, כמו Open Graph parsers, ולכן זו לא גישה אוניברסלית.
-Another technique is to server-render the page in two parts. First, the main content is rendered and all such tags are collected. Then, the `<head>` is rendered with these tags. Finally, the `<head>` and the main content are sent to the browser. This approach works, but it prevents you from taking advantage of the [React 18's Streaming Server Renderer](/reference/react-dom/server/renderToReadableStream) because you'd have to wait for all content to render before sending the `<head>`.
+דרך שנייה היא לרנדר את העמוד בשרת בשני שלבים: קודם התוכן הראשי נאסף יחד עם כל התגיות הרלוונטיות, ואז מרנדרים `<head>` עם אותן תגיות, ורק אז שולחים את הכול לדפדפן. הגישה הזו עובדת, אבל מונעת ניצול של [React 18 Streaming Server Renderer](/reference/react-dom/server/renderToReadableStream), כי צריך לחכות לכל התוכן לפני שליחת `<head>`.
-This is why we're adding built-in support for rendering `<title>`, `<meta>`, and metadata `<link>` tags anywhere in your component tree out of the box. It would work the same way in all environments, including fully client-side code, SSR, and in the future, RSC. We will share more details about this soon.
+לכן אנחנו מוסיפים תמיכה מובנית ברינדור `<title>`, `<meta>`, ותגיות metadata מסוג `<link>` בכל מקום בעץ הקומפוננטות, מהקופסה. זה יעבוד אותו דבר בכל סביבה: קוד client-side מלא, SSR, ובעתיד גם RSC. נשתף פרטים נוספים בקרוב.
## React Optimizing Compiler {/*react-optimizing-compiler*/}
-Since our previous update we've been actively iterating on the design of [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), an optimizing compiler for React. We've previously talked about it as an "auto-memoizing compiler", and that is true in some sense. But building the compiler has helped us understand React's programming model even more deeply. A better way to understand React Forget is as an automatic *reactivity* compiler.
+מאז העדכון הקודם עשינו איטרציה פעילה על העיצוב של [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), קומפיילר אופטימיזציה ל-React. דיברנו עליו בעבר כ-"auto-memoizing compiler", וזה נכון במובן מסוים. אבל העבודה עליו העמיקה אצלנו את ההבנה של מודל התכנות ב-React. דרך מדויקת יותר להבין את React Forget היא כקומפיילר *reactivity* אוטומטי.
-The core idea of React is that developers define their UI as a function of the current state. You work with plain JavaScript values — numbers, strings, arrays, objects — and use standard JavaScript idioms — if/else, for, etc — to describe your component logic. The mental model is that React will re-render whenever the application state changes. We believe this simple mental model and keeping close to JavaScript semantics is an important principle in React's programming model.
+הרעיון המרכזי ב-React הוא שמפתחים מגדירים UI כפונקציה של המצב הנוכחי. עובדים עם ערכי JavaScript רגילים - מספרים, מחרוזות, מערכים, אובייקטים - ומשתמשים באידיומים רגילים של JavaScript - `if/else`, `for` וכו' - כדי לתאר את לוגיקת הקומפוננטה. המודל המנטלי הוא ש-React תרנדר מחדש כשמצב האפליקציה משתנה. אנחנו מאמינים שהמודל הפשוט הזה וההיצמדות לסמנטיקה של JavaScript הם עקרון חשוב ב-React.
-The catch is that React can sometimes be *too* reactive: it can re-render too much. For example, in JavaScript we don't have cheap ways to compare if two objects or arrays are equivalent (having the same keys and values), so creating a new object or array on each render may cause React to do more work than it strictly needs to. This means developers have to explicitly memoize components so as to not over-react to changes.
+האתגר הוא שלפעמים React *מגיבה יותר מדי*: היא מרנדרת מחדש יותר מדי. לדוגמה, ב-JavaScript אין דרך זולה להשוות אם שני אובייקטים/מערכים שקולים, ולכן יצירת אובייקט חדש בכל render יכולה לגרום ל-React לבצע יותר עבודה מהנדרש. לכן מפתחים נאלצים לבצע memoization מפורש כדי לא "להגיב יתר על המידה" לשינויים.
-Our goal with React Forget is to ensure that React apps have just the right amount of reactivity by default: that apps re-render only when state values *meaningfully* change. From an implementation perspective this means automatically memoizing, but we believe that the reactivity framing is a better way to understand React and Forget. One way to think about this is that React currently re-renders when object identity changes. With Forget, React re-renders when the semantic value changes — but without incurring the runtime cost of deep comparisons.
+המטרה שלנו ב-React Forget היא להבטיח כמות reactivity נכונה כברירת מחדל: שהאפליקציה תרנדר מחדש רק כשערכי state משתנים *באופן משמעותי*. מבחינת מימוש זה אומר memoization אוטומטי, אבל אנחנו חושבים שהמסגור כ-reactivity מסביר טוב יותר את React ו-Forget. דרך להבין זאת: כיום React מרנדרת מחדש לפי שינוי בזהות אובייקט. עם Forget, React תרנדר מחדש לפי שינוי בערך הסמנטי, בלי לשלם עלות runtime של השוואות עמוקות.
-In terms of concrete progress, since our last update we have substantially iterated on the design of the compiler to align with this automatic reactivity approach and to incorporate feedback from using the compiler internally. After some significant refactors to the compiler starting late last year, we've now begun using the compiler in production in limited areas at Meta. We plan to open-source it once we've proved it in production.
+מבחינת התקדמות קונקרטית, מאז העדכון האחרון עשינו איטרציה משמעותית על עיצוב הקומפיילר כדי ליישר אותו עם הגישה הזו ולשלב משוב משימוש פנימי. אחרי refactors גדולים בסוף השנה שעברה, התחלנו להשתמש בקומפיילר בפרודקשן באזורים מוגבלים ב-Meta. אנחנו מתכננים לפתוח אותו לקוד פתוח אחרי שנוכיח אותו בפרודקשן.
-Finally, a lot of people have expressed interest in how the compiler works. We're looking forward to sharing a lot more details when we prove the compiler and open-source it. But there are a few bits we can share now:
+בנוסף, הרבה אנשים ביקשו להבין יותר איך הקומפיילר עובד. נשמח לשתף הרבה יותר פרטים אחרי שנוכיח ונפתח אותו. בינתיים אפשר לשתף כמה נקודות:
-The core of the compiler is almost completely decoupled from Babel, and the core compiler API is (roughly) old AST in, new AST out (while retaining source location data). Under the hood we use a custom code representation and transformation pipeline in order to do low-level semantic analysis. However, the primary public interface to the compiler will be via Babel and other build system plugins. For ease of testing we currently have a Babel plugin which is a very thin wrapper that calls the compiler to generate a new version of each function and swap it in.
+ליבת הקומפיילר כמעט מנותקת לגמרי מ-Babel, ו-API הליבה הוא בקירוב AST נכנס, AST יוצא (תוך שמירה על source locations). מתחת למכסה המנוע אנחנו משתמשים בייצוג קוד מותאם וב-pipeline טרנספורמציות כדי לבצע ניתוח סמנטי ברמה נמוכה. עם זאת, הממשק הציבורי המרכזי לקומפיילר יהיה דרך Babel ותוספי build נוספים. לצורכי בדיקות יש לנו כרגע Babel plugin דק מאוד שקורא לקומפיילר, מייצר גרסה חדשה לכל פונקציה ומחליף אותה.
-As we refactored the compiler over the last few months, we wanted to focus on refining the core compilation model to ensure we could handle complexities such as conditionals, loops, reassignment, and mutation. However, JavaScript has a lot of ways to express each of those features: if/else, ternaries, for, for-in, for-of, etc. Trying to support the full language up-front would have delayed the point where we could validate the core model. Instead, we started with a small but representative subset of the language: let/const, if/else, for loops, objects, arrays, primitives, function calls, and a few other features. As we gained confidence in the core model and refined our internal abstractions, we expanded the supported language subset. We're also explicit about syntax we don't yet support, logging diagnostics and skipping compilation for unsupported input. We have utilities to try the compiler on Meta's codebases and see what unsupported features are most common so we can prioritize those next. We'll continue incrementally expanding towards supporting the whole language.
+במהלך ה-refactor בחודשים האחרונים רצינו להתמקד בשיפור מודל הקומפילציה המרכזי כדי לוודא שהוא מתמודד עם מורכבויות כמו תנאים, לולאות, השמה מחדש ומוטציות. אבל ל-JavaScript יש דרכים רבות לבטא כל אחת מהיכולות האלה: `if/else`, ternaries, `for`, `for-in`, `for-of` וכו'. תמיכה מלאה בכל השפה מראש הייתה מעכבת את האימות של מודל הליבה. במקום זה התחלנו בתת-קבוצה קטנה אך מייצגת: `let/const`, `if/else`, לולאות `for`, אובייקטים, מערכים, primitives, קריאות פונקציה ועוד כמה יכולות. ככל שהביטחון במודל גדל והפשטנו את ההפשטות הפנימיות, הרחבנו את תת-הקבוצה הנתמכת. אנחנו גם מסמנים במפורש תחביר שלא נתמך עדיין, מדווחים diagnostics ומדלגים על קומפילציה לקלט לא נתמך. יש לנו כלים להריץ את הקומפיילר על בסיסי הקוד של Meta ולזהות אילו יכולות חסרות הן הנפוצות ביותר כדי לתעדף אותן בהמשך. נמשיך להרחיב בהדרגה עד תמיכה בשפה כולה.
-Making plain JavaScript in React components reactive requires a compiler with a deep understanding of semantics so that it can understand exactly what the code is doing. By taking this approach, we're creating a system for reactivity within JavaScript that lets you write product code of any complexity with the full expressivity of the language, instead of being limited to a domain specific language.
+כדי להפוך JavaScript רגיל בקומפוננטות React ל-reactive צריך קומפיילר עם הבנה סמנטית עמוקה, כדי להבין בדיוק מה הקוד עושה. בגישה הזו אנחנו בונים מערכת reactivity בתוך JavaScript שמאפשרת כתיבת קוד מוצר בכל רמת מורכבות עם כל העוצמה של השפה, במקום להיות מוגבלים לשפה ייעודית צרה.
## Offscreen Rendering {/*offscreen-rendering*/}
-Offscreen rendering is an upcoming capability in React for rendering screens in the background without additional performance overhead. You can think of it as a version of the [`content-visibility` CSS property](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) that works not only for DOM elements but React components, too. During our research, we've discovered a variety of use cases:
+Offscreen rendering היא יכולת מתוכננת ב-React לרינדור מסכים ברקע ללא עלות ביצועים נוספת. אפשר לחשוב עליה כגרסה של [`content-visibility` ב-CSS](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) שעובדת לא רק על אלמנטים ב-DOM אלא גם על קומפוננטות React. במהלך המחקר מצאנו מגוון שימושים:
-- A router can prerender screens in the background so that when a user navigates to them, they're instantly available.
-- A tab switching component can preserve the state of hidden tabs, so the user can switch between them without losing their progress.
-- A virtualized list component can prerender additional rows above and below the visible window.
-- When opening a modal or popup, the rest of the app can be put into "background" mode so that events and updates are disabled for everything except the modal.
+- router יכול לבצע prerender למסכים ברקע כך שכשהמשתמש מנווט אליהם הם זמינים מיד.
+- קומפוננטת החלפת טאבים יכולה לשמור את המצב של טאבים מוסתרים, כך שאפשר לעבור ביניהם בלי לאבד התקדמות.
+- קומפוננטת רשימה וירטואלית יכולה לבצע prerender לשורות נוספות מעל ומתחת לאזור הגלוי.
+- בעת פתיחת modal/popup אפשר להעביר את שאר האפליקציה למצב "background" כך שאירועים ועדכונים כבויים לכל מה שמחוץ למודל.
-Most React developers will not interact with React's offscreen APIs directly. Instead, offscreen rendering will be integrated into things like routers and UI libraries, and then developers who use those libraries will automatically benefit without additional work.
+רוב מפתחי React לא יעבדו ישירות עם APIs של offscreen. במקום זה, offscreen rendering תשולב בראוטרים ובספריות UI, ומי שמשתמש בספריות האלה ירוויח אוטומטית בלי עבודה נוספת.
-The idea is that you should be able to render any React tree offscreen without changing the way you write your components. When a component is rendered offscreen, it does not actually *mount* until the component becomes visible — its effects are not fired. For example, if a component uses `useEffect` to log analytics when it appears for the first time, prerendering won't mess up the accuracy of those analytics. Similarly, when a component goes offscreen, its effects are unmounted, too. A key feature of offscreen rendering is that you can toggle the visibility of a component without losing its state.
+הרעיון הוא שתוכלו לרנדר כל עץ React ב-offscreen בלי לשנות את אופן כתיבת הקומפוננטות. כשקומפוננטה מרונדרת ב-offscreen היא לא באמת *מתבצעת mount* עד שהיא הופכת לגלויה, ולכן ה-effects שלה לא מופעלים. לדוגמה, אם קומפוננטה משתמשת ב-`useEffect` כדי לרשום אנליטיקה כשהיא מופיעה לראשונה, prerendering לא יפגע בדיוק האנליטיקה. באופן דומה, כשהקומפוננטה עוברת ל-offscreen גם ה-effects שלה עושים unmount. תכונה מרכזית היא שאפשר להחליף נראות בלי לאבד state.
-Since our last update, we've tested an experimental version of prerendering internally at Meta in our React Native apps on Android and iOS, with positive performance results. We've also improved how offscreen rendering works with Suspense — suspending inside an offscreen tree will not trigger Suspense fallbacks. Our remaining work involves finalizing the primitives that are exposed to library developers. We expect to publish an RFC later this year, alongside an experimental API for testing and feedback.
+מאז העדכון האחרון בדקנו גרסה ניסיונית פנימית של prerendering באפליקציות React Native ב-Android וב-iOS עם תוצאות ביצועים חיוביות. שיפרנו גם את האינטגרציה עם Suspense: השהיה בתוך עץ offscreen לא תפעיל Suspense fallbacks. העבודה שנותרה היא לסיים את ה-primitives שנחשפים למפתחי ספריות. אנחנו מצפים לפרסם RFC בהמשך השנה יחד עם API ניסיוני לבדיקות ומשוב.
## Transition Tracing {/*transition-tracing*/}
-The Transition Tracing API lets you detect when [React Transitions](/reference/react/useTransition) become slower and investigate why they may be slow. Following our last update, we have completed the initial design of the API and published an [RFC](https://github.com/reactjs/rfcs/pull/238). The basic capabilities have also been implemented. The project is currently on hold. We welcome feedback on the RFC and look forward to resuming its development to provide a better performance measurement tool for React. This will be particularly useful with routers built on top of React Transitions, like the [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router).
+Transition Tracing API מאפשר לזהות מתי [React Transitions](/reference/react/useTransition) נעשים איטיים ולחקור למה. אחרי העדכון האחרון השלמנו את העיצוב הראשוני ופרסמנו [RFC](https://github.com/reactjs/rfcs/pull/238). היכולות הבסיסיות גם מומשו. כרגע הפרויקט בהשהיה זמנית. נשמח למשוב על ה-RFC ומצפים לחזור לפיתוח כדי לספק כלי מדידה ביצועים טוב יותר ל-React. זה יהיה שימושי במיוחד עם routers שמבוססים על React Transitions, כמו [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router).
* * *
-In addition to this update, our team has made recent guest appearances on community podcasts and livestreams to speak more on our work and answer questions.
+בנוסף לעדכון הזה, הצוות שלנו התארח לאחרונה בפודקאסטים ושידורים חיים של הקהילה כדי לדבר על העבודה שלנו ולענות על שאלות.
-* [Dan Abramov](https://twitter.com/dan_abramov) and [Joe Savona](https://twitter.com/en_JS) were interviewed by [Kent C. Dodds on his YouTube channel](https://www.youtube.com/watch?v=h7tur48JSaw), where they discussed concerns around React Server Components.
-* [Dan Abramov](https://twitter.com/dan_abramov) and [Joe Savona](https://twitter.com/en_JS) were guests on the [JSParty podcast](https://jsparty.fm/267) and shared their thoughts about the future of React.
+* [Dan Abramov](https://twitter.com/dan_abramov) ו-[Joe Savona](https://twitter.com/en_JS) התראיינו אצל [Kent C. Dodds ביוטיוב](https://www.youtube.com/watch?v=h7tur48JSaw), ושם דיברו על חששות סביב React Server Components.
+* [Dan Abramov](https://twitter.com/dan_abramov) ו-[Joe Savona](https://twitter.com/en_JS) היו אורחים ב-[JSParty podcast](https://jsparty.fm/267) ושיתפו מחשבות על עתיד React.
-Thanks to [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), and [Sophie Alpert](https://twitter.com/sophiebits) for reviewing this post.
+תודה ל-[Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), and [Sophie Alpert](https://twitter.com/sophiebits) על סקירת הפוסט הזה.
-Thanks for reading, and see you in the next update!
+תודה שקראתם, נתראה בעדכון הבא!
diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md
index 81da3fd00..3a2f33992 100644
--- a/src/content/blog/2023/05/03/react-canaries.md
+++ b/src/content/blog/2023/05/03/react-canaries.md
@@ -1,14 +1,14 @@
---
-title: "React Canaries: Enabling Incremental Feature Rollout Outside Meta"
+title: "React Canaries: מאפשרים השקה הדרגתית של יכולות מחוץ ל-Meta"
---
-May 3, 2023 by [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite)
+3 במאי 2023 מאת [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite)
---
<Intro>
-We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final, before they're released in a stable version--similar to how Meta has long used bleeding-edge versions of React internally. We are introducing a new officially supported [Canary release channel](/community/versioning-policy#canary-channel). It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule.
+אנחנו רוצים להציע לקהילת React אפשרות לאמץ יכולות חדשות בודדות ברגע שהעיצוב שלהן כמעט סופי, עוד לפני שהן משוחררות בגרסה יציבה, בדומה לאופן שבו Meta משתמשת במשך שנים בגרסאות bleeding-edge של React פנימית. אנחנו מציגים ערוץ שחרור חדש ונתמך רשמית: [Canary release channel](/community/versioning-policy#canary-channel). הוא מאפשר ל-setups מנוהלים כמו frameworks לנתק בין אימוץ יכולות React ספציפיות לבין לוח הזמנים של שחרורי React.
</Intro>
@@ -16,79 +16,80 @@ We'd like to offer the React community an option to adopt individual new feature
## tl;dr {/*tldr*/}
-* We're introducing an officially supported [Canary release channel](/community/versioning-policy#canary-channel) for React. Since it's officially supported, if any regressions land, we'll treat them with a similar urgency to bugs in stable releases.
-* Canaries let you start using individual new React features before they land in the semver-stable releases.
-* Unlike the [Experimental](/community/versioning-policy#experimental-channel) channel, React Canaries only include features that we reasonably believe to be ready for adoption. We encourage frameworks to consider bundling pinned Canary React releases.
-* We will announce breaking changes and new features on our blog as they land in Canary releases.
-* **As always, React continues to follow semver for every Stable release.**
+* אנחנו מציגים ערוץ [Canary release channel](/community/versioning-policy#canary-channel) נתמך רשמית עבור React. בגלל שהוא נתמך רשמית, אם תיכנס רגרסיה נתייחס אליה בדחיפות דומה לבאגים בשחרורים יציבים.
+* Canaries מאפשרים להתחיל להשתמש ביכולות חדשות ספציפיות של React לפני שהן נכנסות לשחרורי semver יציבים.
+* בניגוד לערוץ [Experimental](/community/versioning-policy#experimental-channel), React Canaries כוללים רק יכולות שאנחנו מאמינים באופן סביר שהן מוכנות לאימוץ. אנחנו מעודדים frameworks לשקול שילוב של גרסאות Canary נעולות של React.
+* נכריז בבלוג על שינויים שוברים ועל יכולות חדשות כשהם נכנסים לשחרורי Canary.
+* **כמו תמיד, React ממשיך לעקוב אחרי semver בכל שחרור יציב.**
-## How React features are usually developed {/*how-react-features-are-usually-developed*/}
+## איך בדרך כלל מפותחות יכולות React {/*how-react-features-are-usually-developed*/}
-Typically, every React feature has gone through the same stages:
+בדרך כלל כל יכולת ב-React עברה את אותם שלבים:
-1. We develop an initial version and prefix it with `experimental_` or `unstable_`. The feature is only available in the `experimental` release channel. At this point, the feature is expected to change significantly.
-2. We find a team at Meta willing to help us test this feature and provide feedback on it. This leads to a round of changes. As the feature becomes more stable, we work with more teams at Meta to try it out.
-3. Eventually, we feel confident in the design. We remove the prefix from the API name, and make the feature available on the `main` branch by default, which most Meta products use. At this point, any team at Meta can use this feature.
-4. As we build confidence in the direction, we also post an RFC for the new feature. At this point we know the design works for a broad set of cases, but we might make some last minute adjustments.
-5. When we are close to cutting an open source release, we write documentation for the feature and finally release the feature in a stable React release.
+1. אנחנו מפתחים גרסה ראשונית ומוסיפים לה קידומת `experimental_` או `unstable_`. היכולת זמינה רק בערוץ השחרור `experimental`. בשלב הזה מצופה שהיא תשתנה משמעותית.
+2. אנחנו מוצאים צוות ב-Meta שמוכן לעזור לבדוק את היכולת ולתת משוב. זה מוביל לסבב שינויים. כשהיכולת נעשית יציבה יותר, אנחנו עובדים עם צוותים נוספים ב-Meta שמנסים אותה.
+3. בסוף אנחנו מרגישים בטוחים בעיצוב. אנחנו מסירים את הקידומת משם ה-API, והיכולת זמינה כברירת מחדל בענף `main`, שבו רוב מוצרי Meta משתמשים. בשלב הזה כל צוות ב-Meta יכול להשתמש בה.
+4. ככל שהביטחון בכיוון גדל, אנחנו גם מפרסמים RFC עבור היכולת החדשה. בשלב הזה אנחנו יודעים שהעיצוב עובד על טווח רחב של מקרים, אבל ייתכנו התאמות של הרגע האחרון.
+5. כשאנחנו קרובים לשחרור קוד פתוח, אנחנו כותבים תיעוד ליכולת ולבסוף משחררים אותה בגרסה יציבה של React.
-This playbook works well for most features we've released so far. However, there can be a significant gap between when the feature is generally ready to use (step 3) and when it is released in open source (step 5).
+ה-playbook הזה עובד טוב לרוב היכולות ששחררנו עד היום. עם זאת, יכול להיות פער משמעותי בין הזמן שבו היכולת מוכנה לשימוש באופן כללי (שלב 3) לבין הזמן שבו היא משוחררת בקוד פתוח (שלב 5).
-**We'd like to offer the React community an option to follow the same approach as Meta, and adopt individual new features earlier (as they become available) without having to wait for the next release cycle of React.**
+**אנחנו רוצים להציע לקהילת React אפשרות ללכת בגישה דומה לזו של Meta, ולאמץ יכולות חדשות בודדות מוקדם יותר (ברגע שהן זמינות), בלי להמתין למחזור השחרור הבא של React.**
-As always, all React features will eventually make it into a Stable release.
+כמו תמיד, כל יכולות React יגיעו בסוף לשחרור Stable.
-## Can we just do more minor releases? {/*can-we-just-do-more-minor-releases*/}
+## למה לא פשוט להוציא יותר שחרורי minor? {/*can-we-just-do-more-minor-releases*/}
-Generally, we *do* use minor releases for introducing new features.
+באופן כללי, אנחנו *כן* משתמשים בשחרורי minor כדי להציג יכולות חדשות.
-However, this isn't always possible. Sometimes, new features are interconnected with *other* new features which have not yet been fully completed and that we're still actively iterating on. We can't release them separately because their implementations are related. We can't version them separately because they affect the same packages (for example, `react` and `react-dom`). And we need to keep the ability to iterate on the pieces that aren't ready without a flurry of major version releases, which semver would require us to do.
+אבל זה לא תמיד אפשרי. לפעמים יכולות חדשות מקושרות ליכולות חדשות *אחרות* שעדיין לא הושלמו ואנחנו עדיין עושים עליהן איטרציה. אי אפשר לשחרר אותן בנפרד כי המימושים קשורים זה בזה. אי אפשר לגרס אותן בנפרד כי הן משפיעות על אותן חבילות (למשל `react` ו-`react-dom`). ואנחנו צריכים לשמר את היכולת להמשיך איטרציה על החלקים שלא מוכנים בלי סבב של גרסאות major מרובות, ש-semver היה מחייב.
-At Meta, we've solved this problem by building React from the `main` branch, and manually updating it to a specific pinned commit every week. This is also the approach that React Native releases have been following for the last several years. Every *stable* release of React Native is pinned to a specific commit from the `main` branch of the React repository. This lets React Native include important bugfixes and incrementally adopt new React features at the framework level without getting coupled to the global React release schedule.
+ב-Meta פתרנו את זה על ידי בניית React מענף `main`, ועדכון ידני לקומיט נעול ספציפי בכל שבוע. זו גם הגישה שבה React Native עובד כבר כמה שנים. כל שחרור *יציב* של React Native נעול לקומיט ספציפי מענף `main` של מאגר React. זה מאפשר ל-React Native לכלול תיקוני באגים חשובים ולאמץ יכולות חדשות של React בהדרגה ברמת ה-framework, בלי להיות תלוי בלוח השחרורים הגלובלי של React.
-We would like to make this workflow available to other frameworks and curated setups. For example, it lets a framework *on top of* React include a React-related breaking change *before* this breaking change gets included into a stable React release. This is particularly useful because some breaking changes only affect framework integrations. This lets a framework release such a change in its own minor version without breaking semver.
+אנחנו רוצים להפוך את זרימת העבודה הזו לזמינה גם ל-frameworks ול-setups מנוהלים אחרים. לדוגמה, זה מאפשר ל-framework *שמעל* React לכלול שינוי שובר שקשור ל-React *לפני* שהשינוי הזה נכנס לשחרור יציב של React. זה שימושי במיוחד כי חלק מהשינויים השוברים משפיעים רק על אינטגרציות framework. כך framework יכול לשחרר שינוי כזה בגרסת minor משלו בלי לשבור semver.
-Rolling releases with the Canaries channel will allow us to have a tighter feedback loop and ensure that new features get comprehensive testing in the community. This workflow is closer to how TC39, the JavaScript standards committee, [handles changes in numbered stages](https://tc39.es/process-document/). New React features may be available in frameworks built on React before they are in a React stable release, just as new JavaScript features ship in browsers before they are officially ratified as part of the specification.
+שחרורים מתגלגלים דרך ערוץ Canaries יתנו לנו לולאת משוב הדוקה יותר ויבטיחו שהיכולות החדשות מקבלות בדיקות מקיפות בקהילה. זרימת העבודה הזו קרובה יותר לאופן שבו TC39, ועדת התקנים של JavaScript, [מטפלת בשינויים בשלבים ממוספרים](https://tc39.es/process-document/). יכולות חדשות של React עשויות להיות זמינות ב-frameworks מבוססי React לפני שהן נכנסות לשחרור יציב של React, כמו שיכולות JavaScript חדשות מגיעות לדפדפנים לפני שהן מאושרות רשמית כחלק מהמפרט.
-## Why not use experimental releases instead? {/*why-not-use-experimental-releases-instead*/}
+## למה לא להשתמש בשחרורי experimental במקום? {/*why-not-use-experimental-releases-instead*/}
-Although you *can* technically use [Experimental releases](/community/versioning-policy#canary-channel), we recommend against using them in production because experimental APIs can undergo significant breaking changes on their way to stabilization (or can even be removed entirely). While Canaries can also contain mistakes (as with any release), going forward we plan to announce any significant breaking changes in Canaries on our blog. Canaries are the closest to the code Meta runs internally, so you can generally expect them to be relatively stable. However, you *do* need to keep the version pinned and manually scan the GitHub commit log when updating between the pinned commits.
+למרות שמבחינה טכנית *אפשר* להשתמש ב-[Experimental releases](/community/versioning-policy#canary-channel), אנחנו לא ממליצים להשתמש בהן בפרודקשן, כי APIs ניסיוניים יכולים לעבור שינויים שוברים משמעותיים בדרך לייצוב (או להימחק לגמרי). גם Canaries יכולים להכיל טעויות (כמו כל שחרור), אבל מעכשיו אנחנו מתכוונים להכריז בבלוג על שינויים שוברים משמעותיים ב-Canaries. Canaries הם הקרובים ביותר לקוד ש-Meta מריצה בפנים, ולכן בדרך כלל אפשר לצפות שיהיו יציבים יחסית. אבל *כן* צריך לנעול גרסה ולעבור ידנית על commit log ב-GitHub כשמעדכנים בין קומיטים נעולים.
-**We expect that most people using React outside a curated setup (like a framework) will want to continue using the Stable releases.** However, if you're building a framework, you might want to consider bundling a Canary version of React pinned to a particular commit, and update it at your own pace. The benefit of that is that it lets you ship individual completed React features and bugfixes earlier for your users and at your own release schedule, similar to how React Native has been doing it for the last few years. The downside is that you would take on additional responsibility to review which React commits are being pulled in and communicate to your users which React changes are included with your releases.
+**אנחנו מצפים שרוב מי שמשתמש ב-React מחוץ ל-setup מנוהל (כמו framework) ימשיך להשתמש בשחרורי Stable.** אבל אם אתם בונים framework, כדאי לשקול שילוב גרסת Canary של React שנעולה לקומיט מסוים ולעדכן בקצב שלכם. היתרון הוא שזה מאפשר לשחרר למשתמשים שלכם יכולות ותיקוני באגים בודדים של React מוקדם יותר ובקצב השחרור שלכם, בדומה למה ש-React Native עושה כבר כמה שנים. החיסרון הוא שאתם לוקחים אחריות נוספת לבדוק אילו קומיטים של React נכנסים ולעדכן את המשתמשים אילו שינויים ב-React נכללים בכל שחרור שלכם.
-If you're a framework author and want to try this approach, please get in touch with us.
+אם אתם מחברי framework ורוצים לנסות את הגישה הזו, דברו איתנו.
-## Announcing breaking changes and new features early {/*announcing-breaking-changes-and-new-features-early*/}
+## הכרזה מוקדמת על שינויים שוברים ויכולות חדשות {/*announcing-breaking-changes-and-new-features-early*/}
-Canary releases represent our best guess of what will go into the next stable React release at any given time.
+שחרורי Canary מייצגים את ההערכה הטובה ביותר שלנו בכל רגע למה ייכנס לשחרור היציב הבא של React.
-Traditionally, we've only announced breaking changes at the *end* of the release cycle (when doing a major release). Now that Canary releases are an officially supported way to consume React, we plan to shift towards announcing breaking changes and significant new features *as they land* in Canaries. For example, if we merge a breaking change that will go out in a Canary, we will write a post about it on the React blog, including codemods and migration instructions if necessary. Then, if you're a framework author cutting a major release that updates the pinned React canary to include that change, you can link to our blog post from your release notes. Finally, when a stable major version of React is ready, we will link to those already published blog posts, which we hope will help our team make progress faster.
+באופן מסורתי הכרזנו על שינויים שוברים רק בסוף מחזור השחרור (בזמן major release). עכשיו כש-Canary הוא דרך נתמכת רשמית לצרוך React, אנחנו מתכננים לעבור להכריז על שינויים שוברים ועל יכולות חדשות משמעותיות *ברגע שהם נכנסים* ל-Canaries. לדוגמה, אם נמזג שינוי שובר שייצא ב-Canary, נכתוב עליו פוסט בבלוג React כולל codemods והנחיות מיגרציה לפי הצורך. לאחר מכן, אם אתם מחברי framework שמוציאים major release ומעדכנים את React canary הנעול כדי לכלול את השינוי הזה, תוכלו לקשר לפוסט שלנו מתוך release notes. ולבסוף, כשגרסת major יציבה של React תהיה מוכנה, נקשר לאותם פוסטים שכבר פורסמו, מה שלדעתנו יעזור לצוות להתקדם מהר יותר.
-We plan to document APIs as they land in Canaries--even if these APIs are not yet available outside of them. APIs that are only available in Canaries will be marked with a special note on the corresponding pages. This will include APIs like [`use`](https://github.com/reactjs/rfcs/pull/229), and some others (like `cache` and `createServerContext`) which we'll send RFCs for.
+אנחנו מתכננים לתעד APIs ברגע שהם נכנסים ל-Canaries, גם אם הם עדיין לא זמינים מחוץ לערוץ הזה. APIs שזמינים רק ב-Canaries יסומנו עם הערה מיוחדת בדפים המתאימים. זה יכלול APIs כמו [`use`](https://github.com/reactjs/rfcs/pull/229), ועוד כמה נוספים (כמו `cache` ו-`createServerContext`) שעבורם נפרסם RFCs.
-## Canaries must be pinned {/*canaries-must-be-pinned*/}
+## חייבים לנעול Canaries {/*canaries-must-be-pinned*/}
-If you decide to adopt the Canary workflow for your app or framework, make sure you always pin the *exact* version of the Canary you're using. Since Canaries are pre-releases, they may still include breaking changes.
+אם החלטתם לאמץ את זרימת העבודה של Canary באפליקציה או ב-framework שלכם, ודאו שאתם תמיד נועלים את הגרסה *המדויקת* של Canary שאתם משתמשים בה. מכיוון ש-Canaries הם prereleases, הם עדיין יכולים לכלול שינויים שוברים.
-## Example: React Server Components {/*example-react-server-components*/}
+## דוגמה: React Server Components {/*example-react-server-components*/}
-As we [announced in March](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), the React Server Components conventions have been finalized, and we do not expect significant breaking changes related to their user-facing API contract. However, we can't release support for React Server Components in a stable version of React yet because we are still working on several intertwined framework-only features (such as [asset loading](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) and expect more breaking changes there.
+כפי [שהכרזנו במרץ](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), הקונבנציות של React Server Components נסגרו, ואנחנו לא מצפים לשינויים שוברים משמעותיים בחוזה ה-API שנראה למשתמש. עם זאת, עדיין אי אפשר לשחרר תמיכה ב-React Server Components בגרסה יציבה של React כי אנחנו ממשיכים לעבוד על כמה יכולות שקשורות ל-framework בלבד (כמו [asset loading](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) ומצפים לעוד שינויים שוברים שם.
-This means that React Server Components are ready to be adopted by frameworks. However, until the next major React release, the only way for a framework to adopt them is to ship a pinned Canary version of React. (To avoid bundling two copies of React, frameworks that wish to do this would need to enforce resolution of `react` and `react-dom` to the pinned Canary they ship with their framework, and explain that to their users. As an example, this is what Next.js App Router does.)
+המשמעות היא ש-React Server Components כבר מוכנים לאימוץ על ידי frameworks. אבל עד שחרור major הבא של React, הדרך היחידה ל-framework לאמץ אותם היא לשחרר גרסת Canary נעולה של React. (כדי להימנע מבאנדל של שני עותקי React, frameworks שבוחרים בכך צריכים לאכוף resolution של `react` ו-`react-dom` לגרסת ה-Canary הנעולה שהם משחררים עם ה-framework, ולהסביר זאת למשתמשים שלהם. לדוגמה, כך עובד Next.js App Router.)
-## Testing libraries against both Stable and Canary versions {/*testing-libraries-against-both-stable-and-canary-versions*/}
+## בדיקת ספריות מול גרסאות Stable וגם Canary {/*testing-libraries-against-both-stable-and-canary-versions*/}
-We do not expect library authors to test every single Canary release since it would be prohibitively difficult. However, just as when we [originally introduced the different React pre-release channels three years ago](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), we encourage libraries to run tests against *both* the latest Stable and latest Canary versions. If you see a change in behavior that wasn't announced, please file a bug in the React repository so that we can help diagnose it. We expect that as this practice becomes widely adopted, it will reduce the amount of effort necessary to upgrade libraries to new major versions of React, since accidental regressions would be found as they land.
+אנחנו לא מצפים ממחברי ספריות לבדוק כל שחרור Canary בודד, כי זה קשה מדי. אבל כמו שעודדנו כש-[הצגנו במקור את ערוצי ה-prerelease השונים של React לפני שלוש שנים](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), אנחנו מעודדים ספריות להריץ בדיקות מול *גם* גרסת Stable האחרונה *וגם* גרסת Canary האחרונה. אם אתם רואים שינוי התנהגות שלא הוכרז, פתחו באג במאגר React כדי שנוכל לעזור לאבחן. אנחנו מצפים שככל שהפרקטיקה הזו תהפוך לנפוצה, היא תפחית את המאמץ שנדרש לשדרג ספריות לגרסאות major חדשות של React, כי רגרסיות אקראיות יימצאו מוקדם.
<Note>
-Strictly speaking, Canary is not a *new* release channel--it used to be called Next. However, we've decided to rename it to avoid confusion with Next.js. We're announcing it as a *new* release channel to communicate the new expectations, such as Canaries being an officially supported way to use React.
+למען הדיוק, Canary הוא לא ערוץ שחרור *חדש* לגמרי. בעבר הוא נקרא Next. החלטנו לשנות את השם כדי למנוע בלבול מול Next.js. אנחנו מכריזים עליו כערוץ *חדש* כדי להבהיר את הציפיות החדשות, למשל ש-Canaries הם דרך נתמכת רשמית להשתמש ב-React.
</Note>
-## Stable releases work like before {/*stable-releases-work-like-before*/}
+## שחרורים יציבים עובדים כמו קודם {/*stable-releases-work-like-before*/}
+
+אנחנו לא משנים שום דבר באופן שבו שחרורי React יציבים עובדים.
-We are not introducing any changes to stable React releases.
diff --git a/src/content/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024.md b/src/content/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024.md
index 03fc85c37..f482f272b 100644
--- a/src/content/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024.md
+++ b/src/content/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024.md
@@ -1,22 +1,22 @@
---
-title: "React Labs: What We've Been Working On – February 2024"
+title: "React Labs: על מה עבדנו - פברואר 2024"
---
-February 15, 2024 by [Joseph Savona](https://twitter.com/en_JS), [Ricky Hanlon](https://twitter.com/rickhanlonii), [Andrew Clark](https://twitter.com/acdlite), [Matt Carroll](https://twitter.com/mattcarrollcode), and [Dan Abramov](https://twitter.com/dan_abramov).
+15 בפברואר 2024 מאת [Joseph Savona](https://twitter.com/en_JS), [Ricky Hanlon](https://twitter.com/rickhanlonii), [Andrew Clark](https://twitter.com/acdlite), [Matt Carroll](https://twitter.com/mattcarrollcode), and [Dan Abramov](https://twitter.com/dan_abramov).
---
<Intro>
-In React Labs posts, we write about projects in active research and development. We’ve made significant progress since our [last update](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023), and we’d like to share our progress.
+בפוסטים של React Labs אנחנו כותבים על פרויקטים שנמצאים במחקר ופיתוח פעילים. התקדמנו משמעותית מאז [העדכון הקודם שלנו](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023), ורצינו לשתף בהתקדמות.
</Intro>
<Note>
-React Conf 2024 is scheduled for May 15–16 in Henderson, Nevada! If you’re interested in attending React Conf in person, you can [sign up for the ticket lottery](https://forms.reform.app/bLaLeE/react-conf-2024-ticket-lottery/1aRQLK) until February 28th.
+React Conf 2024 מתוכנן ל-15-16 במאי ב-Henderson, Nevada! אם מעניין אתכם להגיע פיזית ל-React Conf, אפשר [להירשם להגרלת הכרטיסים](https://forms.reform.app/bLaLeE/react-conf-2024-ticket-lottery/1aRQLK) עד 28 בפברואר.
-For more info on tickets, free streaming, sponsoring, and more, see [the React Conf website](https://conf.react.dev).
+למידע נוסף על כרטיסים, סטרימינג בחינם, חסויות ועוד, ראו את [אתר React Conf](https://conf.react.dev).
</Note>
@@ -24,26 +24,25 @@ For more info on tickets, free streaming, sponsoring, and more, see [the React C
## React Compiler {/*react-compiler*/}
-React Compiler is no longer a research project: the compiler now powers instagram.com in production, and we are working to ship the compiler across additional surfaces at Meta and to prepare the first open source release.
+React Compiler כבר לא פרויקט מחקר: הקומפיילר מריץ עכשיו את instagram.com בפרודקשן, ואנחנו עובדים כדי לפרוס אותו למשטחים נוספים ב-Meta ולהכין את שחרור הקוד הפתוח הראשון.
-As discussed in our [previous post](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-optimizing-compiler), React can *sometimes* re-render too much when state changes. Since the early days of React our solution for such cases has been manual memoization. In our current APIs, this means applying the [`useMemo`](/reference/react/useMemo), [`useCallback`](/reference/react/useCallback), and [`memo`](/reference/react/memo) APIs to manually tune how much React re-renders on state changes. But manual memoization is a compromise. It clutters up our code, is easy to get wrong, and requires extra work to keep up to date.
+כפי שדיברנו [בפוסט הקודם](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-optimizing-compiler), React יכול *לפעמים* לבצע יותר מדי רינדורים מחדש כשמצב משתנה. מאז הימים הראשונים של React הפתרון שלנו למקרים כאלה היה memoization ידני. ב-APIs הנוכחיים שלנו זה אומר להשתמש ב-[`useMemo`](/reference/react/useMemo), [`useCallback`](/reference/react/useCallback), ו-[`memo`](/reference/react/memo) כדי לכוונן ידנית כמה React ירנדר מחדש בזמן שינויים במצב. אבל memoization ידני הוא פשרה: הוא מעמיס על הקוד, קל לטעות בו, ודורש עבודה נוספת כדי לשמור אותו מעודכן.
-Manual memoization is a reasonable compromise, but we weren’t satisfied. Our vision is for React to *automatically* re-render just the right parts of the UI when state changes, *without compromising on React’s core mental model*. We believe that React’s approach — UI as a simple function of state, with standard JavaScript values and idioms — is a key part of why React has been approachable for so many developers. That’s why we’ve invested in building an optimizing compiler for React.
+memoization ידני הוא פשרה סבירה, אבל לא היינו מרוצים. החזון שלנו הוא ש-React ירנדר מחדש *אוטומטית* רק את החלקים הנכונים ב-UI כשמצב משתנה, *בלי להתפשר על המודל המחשבתי המרכזי של React*. אנחנו מאמינים שהגישה של React, UI כפונקציה פשוטה של מצב עם ערכי JavaScript סטנדרטיים ואידיומים מוכרים, היא חלק מרכזי בסיבה לכך ש-React נגיש לכל כך הרבה מפתחים. לכן השקענו בבניית optimizing compiler עבור React.
-JavaScript is a notoriously challenging language to optimize, thanks to its loose rules and dynamic nature. React Compiler is able to compile code safely by modeling both the rules of JavaScript *and* the “rules of React”. For example, React components must be idempotent — returning the same value given the same inputs — and can’t mutate props or state values. These rules limit what developers can do and help to carve out a safe space for the compiler to optimize.
+JavaScript היא שפה מאתגרת במיוחד לאופטימיזציה בגלל החוקים הרופפים והאופי הדינמי שלה. React Compiler מסוגל לקמפל קוד בצורה בטוחה על ידי מודל של גם חוקי JavaScript *וגם* "החוקים של React". לדוגמה, קומפוננטות React חייבות להיות idempotent, כלומר להחזיר את אותו ערך עבור אותם קלטים, ואסור להן לשנות props או ערכי state. החוקים האלה מגבילים מה מפתחים יכולים לעשות, וגם יוצרים מרחב בטוח שבו הקומפיילר יכול לבצע אופטימיזציה.
-Of course, we understand that developers sometimes bend the rules a bit, and our goal is to make React Compiler work out of the box on as much code as possible. The compiler attempts to detect when code doesn’t strictly follow React’s rules and will either compile the code where safe or skip compilation if it isn’t safe. We’re testing against Meta’s large and varied codebase in order to help validate this approach.
+כמובן, אנחנו מבינים שלפעמים מפתחים מכופפים את החוקים קצת, והמטרה שלנו היא ש-React Compiler יעבוד מהקופסה על כמה שיותר קוד. הקומפיילר מנסה לזהות מתי קוד לא עומד לגמרי בחוקי React, ואז או יקמפל אותו אם זה בטוח או ידלג על הקומפילציה אם זה לא בטוח. אנחנו בודקים מול בסיס הקוד הגדול והמגוון של Meta כדי לאמת את הגישה הזו.
-For developers who are curious about making sure their code follows React’s rules, we recommend [enabling Strict Mode](/reference/react/StrictMode) and [configuring React’s ESLint plugin](/learn/editor-setup#linting). These tools can help to catch subtle bugs in your React code, improving the quality of your applications today, and future-proofs your applications for upcoming features such as React Compiler. We are also working on consolidated documentation of the rules of React and updates to our ESLint plugin to help teams understand and apply these rules to create more robust apps.
+למפתחים שרוצים לוודא שהקוד עומד בחוקי React, אנחנו ממליצים [להפעיל Strict Mode](/reference/react/StrictMode) ו-[להגדיר את תוסף ESLint של React](/learn/editor-setup#linting). הכלים האלה יכולים לתפוס באגים עדינים בקוד React, לשפר את איכות האפליקציות כבר היום, ולחזק אותן לעתיד מול יכולות עתידיות כמו React Compiler. אנחנו גם עובדים על תיעוד מאוחד של חוקי React ועל עדכונים לתוסף ESLint כדי לעזור לצוותים להבין וליישם את החוקים האלה ולבנות אפליקציות חזקות יותר.
-To see the compiler in action, you can check out our [talk from last fall](https://www.youtube.com/watch?v=qOQClO3g8-Y). At the time of the talk, we had early experimental data from trying React Compiler on one page of instagram.com. Since then, we shipped the compiler to production across instagram.com. We’ve also expanded our team to accelerate the rollout to additional surfaces at Meta and to open source. We’re excited about the path ahead and will have more to share in the coming months.
+כדי לראות את הקומפיילר בפעולה, אפשר לצפות ב-[הרצאה שלנו מהסתיו האחרון](https://www.youtube.com/watch?v=qOQClO3g8-Y). בזמן ההרצאה היו לנו נתונים ניסיוניים מוקדמים מניסיון React Compiler על עמוד אחד ב-instagram.com. מאז פרסמנו את הקומפיילר לפרודקשן בכל instagram.com. הרחבנו גם את הצוות כדי להאיץ את הפריסה למשטחים נוספים ב-Meta ובקוד פתוח. אנחנו נרגשים מהדרך קדימה ונשתף עוד בחודשים הקרובים.
## Actions {/*actions*/}
+[שיתפנו בעבר](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components) שאנחנו בוחנים פתרונות להעברת נתונים מהלקוח לשרת עם Server Actions, כך שאפשר לבצע מוטציות במסד נתונים ולממש טפסים. במהלך הפיתוח של Server Actions הרחבנו את ה-APIs האלה כדי לתמוך גם בטיפול בנתונים באפליקציות לקוח בלבד.
-We [previously shared](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components) that we were exploring solutions for sending data from the client to the server with Server Actions, so that you can execute database mutations and implement forms. During development of Server Actions, we extended these APIs to support data handling in client-only applications as well.
-
-We refer to this broader collection of features as simply "Actions". Actions allow you to pass a function to DOM elements such as [`<form/>`](/reference/react-dom/components/form):
+לקבוצת היכולות הרחבה הזו אנחנו קוראים פשוט "Actions". Actions מאפשרים להעביר פונקציה לאלמנטים ב-DOM כמו [`<form/>`](/reference/react-dom/components/form):
```js
<form action={search}>
@@ -52,66 +51,66 @@ We refer to this broader collection of features as simply "Actions". Actions all
</form>
```
-The `action` function can operate synchronously or asynchronously. You can define them on the client side using standard JavaScript or on the server with the [`'use server'`](/reference/react/use-server) directive. When using an action, React will manage the life cycle of the data submission for you, providing hooks like [`useFormStatus`](/reference/react-dom/hooks/useFormStatus), and [`useFormState`](/reference/react-dom/hooks/useFormState) to access the current state and response of the form action.
+הפונקציה `action` יכולה לפעול סינכרונית או אסינכרונית. אפשר להגדיר Actions בצד הלקוח עם JavaScript רגיל או בצד השרת עם ההנחיה [`'use server'`](/reference/react/use-server). כשמשתמשים ב-action, React מנהל עבורכם את מחזור החיים של שליחת הנתונים ומספק hooks כמו [`useFormStatus`](/reference/react-dom/hooks/useFormStatus) ו-[`useFormState`](/reference/react-dom/hooks/useFormState) כדי לגשת למצב הנוכחי ולתגובה של פעולת הטופס.
-By default, Actions are submitted within a [transition](/reference/react/useTransition), keeping the current page interactive while the action is processing. Since Actions support async functions, we've also added the ability to use `async/await` in transitions. This allows you to show pending UI with the `isPending` state of a transition when an async request like `fetch` starts, and show the pending UI all the way through the update being applied.
+כברירת מחדל, Actions נשלחים בתוך [transition](/reference/react/useTransition), כך שהעמוד הנוכחי נשאר אינטראקטיבי בזמן שהפעולה מעובדת. מכיוון ש-Actions תומכים בפונקציות async, הוספנו גם אפשרות להשתמש ב-`async/await` בתוך transitions. זה מאפשר להציג pending UI עם מצב `isPending` של transition כשהבקשה האסינכרונית (כמו `fetch`) מתחילה, ולהמשיך להציג pending UI עד שהעדכון מוחל.
-Alongside Actions, we're introducing a feature named [`useOptimistic`](/reference/react/useOptimistic) for managing optimistic state updates. With this hook, you can apply temporary updates that are automatically reverted once the final state commits. For Actions, this allows you to optimistically set the final state of the data on the client, assuming the submission is successful, and revert to the value for data received from the server. It works using regular `async`/`await`, so it works the same whether you're using `fetch` on the client, or a Server Action from the server.
+יחד עם Actions אנחנו מציגים יכולת בשם [`useOptimistic`](/reference/react/useOptimistic) לניהול optimistic state updates. עם hook זה אפשר להחיל עדכונים זמניים שחוזרים אוטומטית אחורה ברגע שהמצב הסופי נכתב. עבור Actions, זה מאפשר לקבוע בצורה אופטימית את מצב הנתונים הסופי בצד הלקוח בהנחה שהשליחה הצליחה, ולחזור לערך שהתקבל מהשרת אם צריך. זה עובד עם `async`/`await` רגיל, ולכן מתנהג אותו דבר בין אם משתמשים ב-`fetch` בצד הלקוח או ב-Server Action בצד השרת.
-Library authors can implement custom `action={fn}` props in their own components with `useTransition`. Our intent is for libraries to adopt the Actions pattern when designing their component APIs, to provide a consistent experience for React developers. For example, if your library provides a `<Calendar onSelect={eventHandler}>` component, consider also exposing a `<Calendar selectAction={action}>` API, too.
+מחברי ספריות יכולים לממש props מותאמים מסוג `action={fn}` בקומפוננטות שלהם עם `useTransition`. הכוונה שלנו היא שספריות יאמצו את דפוס Actions בעת תכנון APIs של קומפוננטות, כדי לספק חוויה עקבית למפתחי React. לדוגמה, אם הספרייה שלכם מספקת קומפוננטה `<Calendar onSelect={eventHandler}>`, שקלו לחשוף גם API של `<Calendar selectAction={action}>`.
-While we initially focused on Server Actions for client-server data transfer, our philosophy for React is to provide the same programming model across all platforms and environments. When possible, if we introduce a feature on the client, we aim to make it also work on the server, and vice versa. This philosophy allows us to create a single set of APIs that work no matter where your app runs, making it easier to upgrade to different environments later.
+למרות שבהתחלה התמקדנו ב-Server Actions להעברת נתונים לקוח-שרת, הפילוסופיה שלנו ב-React היא לספק את אותו מודל תכנות בכל הפלטפורמות והסביבות. כשאפשר, אם אנחנו מציגים יכולת בצד הלקוח, אנחנו שואפים שתעבוד גם בשרת ולהפך. הפילוסופיה הזו מאפשרת ליצור סט APIs אחיד שעובד לא משנה איפה האפליקציה רצה, ומקלה על שדרוג לסביבות שונות בעתיד.
-Actions are now available in the Canary channel and will ship in the next release of React.
+Actions זמינים עכשיו בערוץ Canary ויישלחו בגרסת React הבאה.
-## New Features in React Canary {/*new-features-in-react-canary*/}
+## יכולות חדשות ב-React Canary {/*new-features-in-react-canary*/}
-We introduced [React Canaries](/blog/2023/05/03/react-canaries) as an option to adopt individual new stable features as soon as their design is close to final, before they’re released in a stable semver version.
+הצגנו את [React Canaries](/blog/2023/05/03/react-canaries) כאפשרות לאמץ יכולות יציבות חדשות בודדות ברגע שהעיצוב שלהן קרוב לסופי, עוד לפני שהן משתחררות בגרסת semver יציבה.
-Canaries are a change to the way we develop React. Previously, features would be researched and built privately inside of Meta, so users would only see the final polished product when released to Stable. With Canaries, we’re building in public with the help of the community to finalize features we share in the React Labs blog series. This means you hear about new features sooner, as they’re being finalized instead of after they’re complete.
+Canaries הם שינוי באופן שבו אנחנו מפתחים את React. בעבר יכולות נחקרו ונבנו פנימית בתוך Meta, כך שמשתמשים ראו רק את התוצר המלוטש הסופי כשהוא שוחרר ל-Stable. עם Canaries אנחנו בונים בפומבי בעזרת הקהילה כדי לסגור סופית יכולות שאנחנו משתפים בסדרת פוסטי React Labs. זה אומר שאתם שומעים על יכולות חדשות מוקדם יותר, בזמן שהן נסגרות ולא רק אחרי שהכול הושלם.
-React Server Components, Asset Loading, Document Metadata, and Actions have all landed in the React Canary, and we've added docs for these features on react.dev:
+React Server Components, Asset Loading, Document Metadata ו-Actions כבר נכנסו ל-React Canary, והוספנו תיעוד ליכולות האלה ב-react.dev:
-- **Directives**: [`"use client"`](/reference/react/use-client) and [`"use server"`](/reference/react/use-server) are bundler features designed for full-stack React frameworks. They mark the "split points" between the two environments: `"use client"` instructs the bundler to generate a `<script>` tag (like [Astro Islands](https://docs.astro.build/en/concepts/islands/#creating-an-island)), while `"use server"` tells the bundler to generate a POST endpoint (like [tRPC Mutations](https://trpc.io/docs/concepts)). Together, they let you write reusable components that compose client-side interactivity with the related server-side logic.
+- **Directives**: [`"use client"`](/reference/react/use-client) ו-[`"use server"`](/reference/react/use-server) הן יכולות bundler שמיועדות ל-full-stack React frameworks. הן מסמנות את "נקודות הפיצול" בין שתי הסביבות: `"use client"` מנחה את הבאנדלר לייצר תגית `<script>` (בדומה ל-[Astro Islands](https://docs.astro.build/en/concepts/islands/#creating-an-island)), ו-`"use server"` אומר לבאנדלר לייצר endpoint של POST (בדומה ל-[tRPC Mutations](https://trpc.io/docs/concepts)). יחד הן מאפשרות לכתוב קומפוננטות לשימוש חוזר שמשלבות אינטראקטיביות בצד לקוח עם הלוגיקה המתאימה בצד שרת.
-- **Document Metadata**: we added built-in support for rendering [`<title>`](/reference/react-dom/components/title), [`<meta>`](/reference/react-dom/components/meta), and metadata [`<link>`](/reference/react-dom/components/link) tags anywhere in your component tree. These work the same way in all environments, including fully client-side code, SSR, and RSC. This provides built-in support for features pioneered by libraries like [React Helmet](https://github.com/nfl/react-helmet).
+- **Document Metadata**: הוספנו תמיכה מובנית ברינדור תגיות [`<title>`](/reference/react-dom/components/title), [`<meta>`](/reference/react-dom/components/meta), ו-[`<link>`](/reference/react-dom/components/link) של metadata בכל מקום בעץ הקומפוננטות. הן עובדות אותו דבר בכל סביבה, כולל קוד לקוח מלא, SSR ו-RSC. כך מתקבלת תמיכה מובנית ביכולות שספריות כמו [React Helmet](https://github.com/nfl/react-helmet) הובילו בעבר.
-- **Asset Loading**: we integrated Suspense with the loading lifecycle of resources such as stylesheets, fonts, and scripts so that React takes them into account to determine whether the content in elements like [`<style>`](/reference/react-dom/components/style), [`<link>`](/reference/react-dom/components/link), and [`<script>`](/reference/react-dom/components/script) are ready to be displayed. We’ve also added new [Resource Loading APIs](/reference/react-dom#resource-preloading-apis) like `preload` and `preinit` to provide greater control for when a resource should load and initialize.
+- **Asset Loading**: שילבנו Suspense במחזור החיים של טעינת משאבים כמו stylesheets, פונטים וסקריפטים כך ש-React לוקח אותם בחשבון כדי לקבוע אם תוכן באלמנטים כמו [`<style>`](/reference/react-dom/components/style), [`<link>`](/reference/react-dom/components/link), ו-[`<script>`](/reference/react-dom/components/script) מוכן להצגה. הוספנו גם [Resource Loading APIs](/reference/react-dom#resource-preloading-apis) חדשים כמו `preload` ו-`preinit` כדי לאפשר שליטה טובה יותר מתי משאב צריך להיטען ולעבור אתחול.
-- **Actions**: As shared above, we've added Actions to manage sending data from the client to the server. You can add `action` to elements like [`<form/>`](/reference/react-dom/components/form), access the status with [`useFormStatus`](/reference/react-dom/hooks/useFormStatus), handle the result with [`useFormState`](/reference/react-dom/hooks/useFormState), and optimistically update the UI with [`useOptimistic`](/reference/react/useOptimistic).
+- **Actions**: כפי ששיתפנו למעלה, הוספנו Actions לניהול שליחת נתונים מהלקוח לשרת. אפשר להוסיף `action` לאלמנטים כמו [`<form/>`](/reference/react-dom/components/form), לגשת לסטטוס עם [`useFormStatus`](/reference/react-dom/hooks/useFormStatus), לטפל בתוצאה עם [`useFormState`](/reference/react-dom/hooks/useFormState), ולעדכן את ה-UI באופן אופטימי עם [`useOptimistic`](/reference/react/useOptimistic).
-Since all of these features work together, it’s difficult to release them in the Stable channel individually. Releasing Actions without the complementary hooks for accessing form states would limit the practical usability of Actions. Introducing React Server Components without integrating Server Actions would complicate modifying data on the server.
+מכיוון שכל היכולות האלה עובדות יחד, קשה לשחרר אותן בנפרד בערוץ Stable. שחרור Actions בלי ה-hooks המשלימים לגישה למצבי טופס היה מגביל את השימוש המעשי ב-Actions. הכנסת React Server Components בלי אינטגרציה של Server Actions הייתה מסבכת עדכון נתונים בשרת.
-Before we can release a set of features to the Stable channel, we need to ensure they work cohesively and developers have everything they need to use them in production. React Canaries allow us to develop these features individually, and release the stable APIs incrementally until the entire feature set is complete.
+לפני שאפשר לשחרר סט יכולות לערוץ Stable, צריך לוודא שהן עובדות יחד בצורה קוהרנטית ושיש למפתחים את כל מה שצריך כדי להשתמש בהן בפרודקשן. React Canaries מאפשרים לנו לפתח את היכולות האלה בנפרד ולשחרר APIs יציבים בהדרגה עד שכל סט היכולות שלם.
-The current set of features in React Canary are complete and ready to release.
+סט היכולות הנוכחי ב-React Canary שלם ומוכן לשחרור.
-## The Next Major Version of React {/*the-next-major-version-of-react*/}
+## גרסת ה-major הבאה של React {/*the-next-major-version-of-react*/}
-After a couple of years of iteration, `react@canary` is now ready to ship to `react@latest`. The new features mentioned above are compatible with any environment your app runs in, providing everything needed for production use. Since Asset Loading and Document Metadata may be a breaking change for some apps, the next version of React will be a major version: **React 19**.
+אחרי כמה שנים של איטרציה, `react@canary` מוכן עכשיו להישלח ל-`react@latest`. היכולות החדשות שצוינו למעלה תואמות לכל סביבה שבה האפליקציה שלכם רצה ומספקות את כל מה שנדרש לשימוש בפרודקשן. מכיוון ש-Asset Loading ו-Document Metadata עלולים להיות שינוי שובר עבור חלק מהאפליקציות, הגרסה הבאה של React תהיה major version: **React 19**.
-There’s still more to be done to prepare for release. In React 19, we’re also adding long-requested improvements which require breaking changes like support for Web Components. Our focus now is to land these changes, prepare for release, finalize docs for new features, and publish announcements for what’s included.
+עדיין נותרה עבודה לקראת השחרור. ב-React 19 אנחנו מוסיפים גם שיפורים מבוקשים שדורשים שינויים שוברים, כמו תמיכה ב-Web Components. הפוקוס שלנו עכשיו הוא להכניס את השינויים האלה, להכין את השחרור, לסיים את התיעוד ליכולות החדשות ולפרסם הכרזות על כל מה שנכלל.
-We’ll share more information about everything React 19 includes, how to adopt the new client features, and how to build support for React Server Components in the coming months.
+נשתף בחודשים הקרובים עוד מידע על כל מה ש-React 19 כולל, איך לאמץ את יכולות הלקוח החדשות, ואיך לבנות תמיכה ב-React Server Components.
-## Offscreen (renamed to Activity). {/*offscreen-renamed-to-activity*/}
+## Offscreen (שמו שונה ל-Activity) {/*offscreen-renamed-to-activity*/}
-Since our last update, we’ve renamed a capability we’re researching from “Offscreen” to “Activity”. The name “Offscreen” implied that it only applied to parts of the app that were not visible, but while researching the feature we realized that it’s possible for parts of the app to be visible and inactive, such as content behind a modal. The new name more closely reflects the behavior of marking certain parts of the app “active” or “inactive”.
+מאז העדכון הקודם שינינו שם ליכולת שאנחנו חוקרים מ-"Offscreen" ל-"Activity". השם "Offscreen" רמז שזה חל רק על חלקים באפליקציה שלא נראים, אבל תוך כדי מחקר הבנו שיכולים להיות חלקים גלויים אך לא פעילים, כמו תוכן שנמצא מאחורי modal. השם החדש משקף טוב יותר את ההתנהגות של סימון חלקים מסוימים באפליקציה כ-"active" או "inactive".
-Activity is still under research and our remaining work is to finalize the primitives that are exposed to library developers. We’ve deprioritized this area while we focus on shipping features that are more complete.
+Activity עדיין במחקר, והעבודה שנותרה היא לסגור סופית את ה-primitives שנחשפים למפתחי ספריות. הורדנו עדיפות זמנית לאזור הזה בזמן שאנחנו מתמקדים בשחרור יכולות בשלות יותר.
* * *
-In addition to this update, our team has presented at conferences and made appearances on podcasts to speak more on our work and answer questions.
+בנוסף לעדכון הזה, הצוות שלנו הרצה בכנסים והתארח בפודקאסטים כדי לדבר יותר על העבודה שלנו ולענות על שאלות.
-- [Sathya Gunasekaran](/community/team#sathya-gunasekaran) spoke about the React Compiler at the [React India](https://www.youtube.com/watch?v=kjOacmVsLSE) conference
+- [Sathya Gunasekaran](/community/team#sathya-gunasekaran) דיבר על React Compiler בכנס [React India](https://www.youtube.com/watch?v=kjOacmVsLSE)
-- [Dan Abramov](/community/team#dan-abramov) gave a talk at [RemixConf](https://www.youtube.com/watch?v=zMf_xeGPn6s) titled “React from Another Dimension” which explores an alternative history of how React Server Components and Actions could have been created
+- [Dan Abramov](/community/team#dan-abramov) נתן הרצאה ב-[RemixConf](https://www.youtube.com/watch?v=zMf_xeGPn6s) בשם "React from Another Dimension" שחוקרת היסטוריה חלופית של יצירת React Server Components ו-Actions
-- [Dan Abramov](/community/team#dan-abramov) was interviewed on [the Changelog’s JS Party podcast](https://changelog.com/jsparty/311) about React Server Components
+- [Dan Abramov](/community/team#dan-abramov) התראיין ב-[פודקאסט JS Party של Changelog](https://changelog.com/jsparty/311) על React Server Components
-- [Matt Carroll](/community/team#matt-carroll) was interviewed on the [Front-End Fire podcast](https://www.buzzsprout.com/2226499/14462424-interview-the-two-reacts-with-rachel-nabors-evan-bacon-and-matt-carroll) where he discussed [The Two Reacts](https://overreacted.io/the-two-reacts/)
+- [Matt Carroll](/community/team#matt-carroll) התראיין ב-[פודקאסט Front-End Fire](https://www.buzzsprout.com/2226499/14462424-interview-the-two-reacts-with-rachel-nabors-evan-bacon-and-matt-carroll) ושם דיבר על [The Two Reacts](https://overreacted.io/the-two-reacts/)
-Thanks [Lauren Tan](https://twitter.com/potetotes), [Sophie Alpert](https://twitter.com/sophiebits), [Jason Bonta](https://threads.net/someextent), [Eli White](https://twitter.com/Eli_White), and [Sathya Gunasekaran](https://twitter.com/_gsathya) for reviewing this post.
+תודה ל-[Lauren Tan](https://twitter.com/potetotes), [Sophie Alpert](https://twitter.com/sophiebits), [Jason Bonta](https://threads.net/someextent), [Eli White](https://twitter.com/Eli_White), and [Sathya Gunasekaran](https://twitter.com/_gsathya) על סקירת הפוסט הזה.
-Thanks for reading, and [see you at React Conf](https://conf.react.dev/)!
+תודה שקראתם, ו-[נתראה ב-React Conf](https://conf.react.dev/)!
diff --git a/src/content/blog/index.md b/src/content/blog/index.md
index 409f33701..108367ea7 100644
--- a/src/content/blog/index.md
+++ b/src/content/blog/index.md
@@ -1,10 +1,10 @@
---
-title: React Blog
+title: בלוג React
---
<Intro>
-This blog is the official source for the updates from the React team. Anything important, including release notes or deprecation notices, will be posted here first. You can also follow the [@reactjs](https://twitter.com/reactjs) account on Twitter, but you won’t miss anything essential if you only read this blog.
+הבלוג הזה הוא המקור הרשמי לעדכונים מצוות React. כל דבר חשוב, כולל הערות שחרור או הודעות על הוצאה משימוש, יתפרסם כאן קודם. אפשר גם לעקוב אחרי חשבון [@reactjs](https://twitter.com/reactjs) ב-Twitter, אבל לא תפספסו שום דבר מהותי גם אם תקראו רק את הבלוג הזה.
</Intro>
@@ -12,70 +12,70 @@ This blog is the official source for the updates from the React team. Anything i
<BlogCard title="React Labs: What We've Been Working On – February 2024" date="February 15, 2024" url="/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024">
-In React Labs posts, we write about projects in active research and development. Since our last update, we've made significant progress on React Compiler, new features, and React 19, and we'd like to share what we learned.
+בפוסטים של React Labs אנחנו כותבים על פרויקטים שנמצאים במחקר ופיתוח פעילים. מאז העדכון הקודם שלנו התקדמנו משמעותית ב-React Compiler, בפיצ'רים חדשים וב-React 19, ורצינו לשתף במה שלמדנו.
</BlogCard>
<BlogCard title="React Canaries: Incremental Feature Rollout Outside Meta" date="May 3, 2023" url="/blog/2023/05/03/react-canaries">
-Traditionally, new React features used to only be available at Meta first, and land in the open source releases later. We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final--similar to how Meta uses React internally. We are introducing a new officially supported Canary release channel. It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule.
+באופן מסורתי, פיצ'רים חדשים של React היו זמינים קודם רק ב-Meta, ורק אחר כך הגיעו לגרסאות קוד פתוח. אנחנו רוצים לתת לקהילת React אפשרות לאמץ פיצ'רים חדשים בודדים ברגע שהעיצוב שלהם קרוב לגרסה סופית, בדומה לאופן שבו Meta משתמשת ב-React פנימית. לכן השקנו ערוץ שחרור Canary חדש שנתמך רשמית. הוא מאפשר לסביבות מאורגנות כמו frameworks לנתק בין אימוץ פיצ'רים בודדים של React לבין לוח הזמנים של שחרורי React.
</BlogCard>
<BlogCard title="React Labs: What We've Been Working On – March 2023" date="March 22, 2023" url="/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023">
-In React Labs posts, we write about projects in active research and development. Since our last update, we've made significant progress on React Server Components, Asset Loading, Optimizing Compiler, Offscreen Rendering, and Transition Tracing, and we'd like to share what we learned.
+בפוסטים של React Labs אנחנו כותבים על פרויקטים שנמצאים במחקר ופיתוח פעילים. מאז העדכון הקודם התקדמנו משמעותית ב-React Server Components, טעינת נכסים, אופטימיזציית קומפיילר, Offscreen Rendering ו-Transition Tracing, ורצינו לשתף במה שלמדנו.
</BlogCard>
<BlogCard title="Introducing react.dev" date="March 16, 2023" url="/blog/2023/03/16/introducing-react-dev">
-Today we are thrilled to launch react.dev, the new home for React and its documentation. In this post, we would like to give you a tour of the new site.
+היום אנחנו נרגשים להשיק את react.dev, הבית החדש של React והתיעוד שלו. בפוסט הזה אנחנו נותנים סיור באתר החדש.
</BlogCard>
<BlogCard title="React Labs: What We've Been Working On – June 2022" date="June 15, 2022" url="/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022">
-React 18 was years in the making, and with it brought valuable lessons for the React team. Its release was the result of many years of research and exploring many paths. Some of those paths were successful; many more were dead-ends that led to new insights. One lesson we’ve learned is that it’s frustrating for the community to wait for new features without having insight into these paths that we’re exploring...
+React 18 נבנתה לאורך שנים, ובדרך סיפקה לצוות React הרבה תובנות חשובות. השחרור שלה הוא תוצאה של שנים של מחקר ובחינה של מסלולים רבים. חלק מהמסלולים הצליחו; רבים אחרים היו מבוי סתום שהוביל לתובנות חדשות. אחד הדברים שלמדנו הוא שמתסכל את הקהילה להמתין לפיצ'רים חדשים בלי לראות את המסלולים שאנחנו בוחנים...
</BlogCard>
<BlogCard title="React v18.0" date="March 29, 2022" url="/blog/2022/03/29/react-v18">
-React 18 is now available on npm! In our last post, we shared step-by-step instructions for upgrading your app to React 18. In this post, we’ll give an overview of what’s new in React 18, and what it means for the future...
+React 18 זמינה עכשיו ב-npm! בפוסט הקודם שיתפנו הוראות שלב-אחר-שלב לשדרוג אפליקציה ל-React 18. בפוסט הזה ניתן סקירה של מה חדש ב-React 18 ומה המשמעות לעתיד...
</BlogCard>
<BlogCard title="How to Upgrade to React 18" date="March 8, 2022" url="/blog/2022/03/08/react-18-upgrade-guide">
-As we shared in the release post, React 18 introduces features powered by our new concurrent renderer, with a gradual adoption strategy for existing applications. In this post, we will guide you through the steps for upgrading to React 18...
+כפי ששיתפנו בפוסט ההשקה, React 18 מציגה פיצ'רים שמופעלים על ידי concurrent renderer החדש שלנו, עם אסטרטגיית אימוץ הדרגתית לאפליקציות קיימות. בפוסט הזה נדריך אתכם בשלבים לשדרוג ל-React 18...
</BlogCard>
<BlogCard title="React Conf 2021 Recap" date="December 17, 2021" url="/blog/2021/12/17/react-conf-2021-recap">
-Last week we hosted our 6th React Conf. In previous years, we’ve used the React Conf stage to deliver industry changing announcements such as React Native and React Hooks. This year, we shared our multi-platform vision for React, starting with the release of React 18 and gradual adoption of concurrent features...
+בשבוע שעבר ערכנו את React Conf השישי שלנו. בשנים קודמות השתמשנו בבמה של React Conf כדי לפרסם הכרזות ששינו את התעשייה, כמו React Native ו-React Hooks. השנה שיתפנו את החזון הרב-פלטפורמי שלנו ל-React, החל מהשקת React 18 ועד לאימוץ הדרגתי של פיצ'רים מבוססי concurrency...
</BlogCard>
<BlogCard title="The Plan for React 18" date="June 8, 2021" url="/blog/2021/06/08/the-plan-for-react-18">
-The React team is excited to share a few updates:
+צוות React שמח לשתף כמה עדכונים:
-- We’ve started work on the React 18 release, which will be our next major version.
-- We’ve created a Working Group to prepare the community for gradual adoption of new features in React 18.
-- We’ve published a React 18 Alpha so that library authors can try it and provide feedback...
+- התחלנו לעבוד על React 18, שתהיה הגרסה הגדולה הבאה שלנו.
+- יצרנו Working Group כדי להכין את הקהילה לאימוץ הדרגתי של פיצ'רים חדשים ב-React 18.
+- פרסמנו React 18 Alpha כדי שמפתחי ספריות יוכלו לנסות ולתת פידבק...
</BlogCard>
<BlogCard title="Introducing Zero-Bundle-Size React Server Components" date="December 21, 2020" url="/blog/2020/12/21/data-fetching-with-react-server-components">
-2020 has been a long year. As it comes to an end we wanted to share a special Holiday Update on our research into zero-bundle-size React Server Components. To introduce React Server Components, we have prepared a talk and a demo. If you want, you can check them out during the holidays, or later when work picks back up in the new year...
+שנת 2020 הייתה שנה ארוכה. לקראת הסוף שלה רצינו לשתף עדכון חגים מיוחד על המחקר שלנו בנושא React Server Components בגודל bundle אפסי. כדי להציג את React Server Components הכנו הרצאה ודמו. אם תרצו, אפשר לעבור עליהם במהלך החגים, או בהמשך כשחוזרים לשגרה בשנה החדשה...
</BlogCard>
</div>
---
-### All release notes {/*all-release-notes*/}
+### כל הערות השחרור {/*all-release-notes*/}
-Not every React release deserves its own blog post, but you can find a detailed changelog for every release in the [`CHANGELOG.md`](https://github.com/facebook/react/blob/main/CHANGELOG.md) file in the React repository, as well as on the [Releases](https://github.com/facebook/react/releases) page.
+לא כל שחרור של React מקבל פוסט משלו בבלוג, אבל אפשר למצוא changelog מפורט לכל שחרור בקובץ [`CHANGELOG.md`](https://github.com/facebook/react/blob/main/CHANGELOG.md) במאגר של React, וגם בעמוד [Releases](https://github.com/facebook/react/releases).
---
-### Older posts {/*older-posts*/}
+### פוסטים ישנים יותר {/*older-posts*/}
-See the [older posts.](https://reactjs.org/blog/all.html)
+ראו את [הפוסטים הישנים יותר.](https://reactjs.org/blog/all.html)
<div className="h-12"></div>
diff --git a/src/content/community/acknowledgements.md b/src/content/community/acknowledgements.md
index c87a92979..5d27d5a29 100644
--- a/src/content/community/acknowledgements.md
+++ b/src/content/community/acknowledgements.md
@@ -1,16 +1,16 @@
---
-title: Acknowledgements
+title: תודות
---
<Intro>
-React was originally created by [Jordan Walke.](https://github.com/jordwalke) Today, React has a [dedicated full-time team working on it](/community/team), as well as over a thousand [open source contributors.](https://github.com/facebook/react/blob/main/AUTHORS)
+React נוצרה במקור על ידי [Jordan Walke.](https://github.com/jordwalke) כיום ל-React יש [צוות ייעודי שעובד עליה במשרה מלאה](/community/team), וגם למעלה מאלף [תורמי קוד פתוח.](https://github.com/facebook/react/blob/main/AUTHORS)
</Intro>
-## Past contributors {/*past-contributors*/}
+## תורמים בעבר {/*past-contributors*/}
-We'd like to recognize a few people who have made significant contributions to React and its documentation in the past and have helped maintain them over the years:
+אנחנו רוצים להוקיר כמה אנשים שתרמו תרומה משמעותית ל-React ולתיעוד שלה בעבר, ועזרו לתחזק אותם לאורך השנים:
* [Almero Steyn](https://github.com/AlmeroSteyn)
* [Andreas Svensson](https://github.com/syranide)
@@ -56,15 +56,15 @@ We'd like to recognize a few people who have made significant contributions to R
* [Tim Yung](https://github.com/yungsters)
* [Xuan Huang](https://github.com/huxpro)
-This list is not exhaustive.
+הרשימה הזו אינה מלאה.
-We'd like to give special thanks to [Tom Occhino](https://github.com/tomocchino) and [Adam Wolff](https://github.com/wolffiex) for their guidance and support over the years. We are also thankful to all the volunteers who [translated React into other languages.](https://translations.reactjs.org/)
+אנחנו רוצים להגיד תודה מיוחדת ל-[Tom Occhino](https://github.com/tomocchino) ול-[Adam Wolff](https://github.com/wolffiex) על ההכוונה והתמיכה לאורך השנים. אנחנו גם מודים לכל המתנדבים ש-[תרגמו את React לשפות אחרות.](https://translations.reactjs.org/)
-## Additional Thanks {/*additional-thanks*/}
+## תודות נוספות {/*additional-thanks*/}
-Additionally, we're grateful to:
+בנוסף, אנחנו מודים ל:
-* [Jeff Barczewski](https://github.com/jeffbski) for allowing us to use the `react` package name on npm
-* [Christopher Aue](https://christopheraue.net/) for letting us use the reactjs.com domain name and the [@reactjs](https://twitter.com/reactjs) username on Twitter
-* [ProjectMoon](https://github.com/ProjectMoon) for letting us use the [flux](https://www.npmjs.com/package/flux) package name on npm
-* Shane Anderson for allowing us to use the [react](https://github.com/react) org on GitHub
+* [Jeff Barczewski](https://github.com/jeffbski) שאפשר לנו להשתמש בשם החבילה `react` ב-npm
+* [Christopher Aue](https://christopheraue.net/) שאפשר לנו להשתמש בדומיין reactjs.com ובשם המשתמש [@reactjs](https://twitter.com/reactjs) ב-Twitter
+* [ProjectMoon](https://github.com/ProjectMoon) שאפשר לנו להשתמש בשם החבילה [flux](https://www.npmjs.com/package/flux) ב-npm
+* Shane Anderson שאפשר לנו להשתמש בארגון [react](https://github.com/react) ב-GitHub
diff --git a/src/content/community/docs-contributors.md b/src/content/community/docs-contributors.md
index cbdbf7d7f..b6e6024ab 100644
--- a/src/content/community/docs-contributors.md
+++ b/src/content/community/docs-contributors.md
@@ -1,42 +1,42 @@
---
-title: Docs Contributors
+title: תורמי התיעוד
---
<Intro>
-React documentation is written and maintained by the [React team](/community/team) and [external contributors.](https://github.com/reactjs/reactjs.org/graphs/contributors) On this page, we'd like to thank a few people who've made significant contributions to this site.
+התיעוד של React נכתב ומתוחזק על ידי [צוות React](/community/team) ועל ידי [תורמים חיצוניים.](https://github.com/reactjs/reactjs.org/graphs/contributors) בעמוד הזה אנחנו רוצים להודות לכמה אנשים שתרמו תרומה משמעותית לאתר.
</Intro>
-## Content {/*content*/}
-
-* [Rachel Nabors](https://twitter.com/RachelNabors): editing, writing, illustrating
-* [Dan Abramov](https://twitter.com/dan_abramov): writing, curriculum design
-* [Sylwia Vargas](https://twitter.com/SylwiaVargas): example code
-* [Rick Hanlon](https://twitter.com/rickhanlonii): writing
-* [David McCabe](https://twitter.com/mcc_abe): writing
-* [Sophie Alpert](https://twitter.com/sophiebits): writing
-* [Pete Hunt](https://twitter.com/floydophone): writing
-* [Andrew Clark](https://twitter.com/acdlite): writing
-* [Matt Carroll](https://twitter.com/mattcarrollcode): editing, writing
-* [Natalia Tepluhina](https://twitter.com/n_tepluhina): reviews, advice
-* [Sebastian Markbåge](https://twitter.com/sebmarkbage): feedback
-
-## Design {/*design*/}
-
-* [Dan Lebowitz](https://twitter.com/lebo): site design
-* [Razvan Gradinar](https://dribbble.com/GradinarRazvan): sandbox design
-* [Maggie Appleton](https://maggieappleton.com/): diagram system
-* [Sophie Alpert](https://twitter.com/sophiebits): color-coded explanations
-
-## Development {/*development*/}
-
-* [Jared Palmer](https://twitter.com/jaredpalmer): site development
-* [ThisDotLabs](https://www.thisdot.co/) ([Dane Grant](https://twitter.com/danecando), [Dustin Goodman](https://twitter.com/dustinsgoodman)): site development
-* [CodeSandbox](https://codesandbox.io/) ([Ives van Hoorne](https://twitter.com/CompuIves), [Alex Moldovan](https://twitter.com/alexnmoldovan), [Jasper De Moor](https://twitter.com/JasperDeMoor), [Danilo Woznica](https://twitter.com/danilowoz)): sandbox integration
-* [Dan Abramov](https://twitter.com/dan_abramov): site development
-* [Rick Hanlon](https://twitter.com/rickhanlonii): site development
-* [Harish Kumar](https://www.strek.in/): development and maintenance
-* [Luna Ruan](https://twitter.com/lunaruan): sandbox improvements
-
-We'd also like to thank countless alpha testers and community members who gave us feedback along the way.
+## תוכן {/*content*/}
+
+* [Rachel Nabors](https://twitter.com/RachelNabors): עריכה, כתיבה, איור
+* [Dan Abramov](https://twitter.com/dan_abramov): כתיבה, תכנון תכנית לימוד
+* [Sylwia Vargas](https://twitter.com/SylwiaVargas): קוד לדוגמאות
+* [Rick Hanlon](https://twitter.com/rickhanlonii): כתיבה
+* [David McCabe](https://twitter.com/mcc_abe): כתיבה
+* [Sophie Alpert](https://twitter.com/sophiebits): כתיבה
+* [Pete Hunt](https://twitter.com/floydophone): כתיבה
+* [Andrew Clark](https://twitter.com/acdlite): כתיבה
+* [Matt Carroll](https://twitter.com/mattcarrollcode): עריכה, כתיבה
+* [Natalia Tepluhina](https://twitter.com/n_tepluhina): סקירות, ייעוץ
+* [Sebastian Markbåge](https://twitter.com/sebmarkbage): משוב
+
+## עיצוב {/*design*/}
+
+* [Dan Lebowitz](https://twitter.com/lebo): עיצוב האתר
+* [Razvan Gradinar](https://dribbble.com/GradinarRazvan): עיצוב sandbox
+* [Maggie Appleton](https://maggieappleton.com/): מערכת דיאגרמות
+* [Sophie Alpert](https://twitter.com/sophiebits): הסברים בקידוד צבעים
+
+## פיתוח {/*development*/}
+
+* [Jared Palmer](https://twitter.com/jaredpalmer): פיתוח האתר
+* [ThisDotLabs](https://www.thisdot.co/) ([Dane Grant](https://twitter.com/danecando), [Dustin Goodman](https://twitter.com/dustinsgoodman)): פיתוח האתר
+* [CodeSandbox](https://codesandbox.io/) ([Ives van Hoorne](https://twitter.com/CompuIves), [Alex Moldovan](https://twitter.com/alexnmoldovan), [Jasper De Moor](https://twitter.com/JasperDeMoor), [Danilo Woznica](https://twitter.com/danilowoz)): אינטגרציית sandbox
+* [Dan Abramov](https://twitter.com/dan_abramov): פיתוח האתר
+* [Rick Hanlon](https://twitter.com/rickhanlonii): פיתוח האתר
+* [Harish Kumar](https://www.strek.in/): פיתוח ותחזוקה
+* [Luna Ruan](https://twitter.com/lunaruan): שיפורי sandbox
+
+אנחנו רוצים להודות גם לאינספור בודקי אלפא וחברי קהילה שנתנו לנו משוב לאורך הדרך.
diff --git a/src/content/community/index.md b/src/content/community/index.md
index 1e28a27f0..a87624525 100644
--- a/src/content/community/index.md
+++ b/src/content/community/index.md
@@ -1,32 +1,32 @@
---
-title: React Community
+title: קהילת React
---
<Intro>
-React has a community of millions of developers. On this page we've listed some React-related communities that you can be a part of; see the other pages in this section for additional online and in-person learning materials.
+ל-React יש קהילה של מיליוני מפתחים. בעמוד הזה ריכזנו קהילות הקשורות ל-React שאפשר להיות חלק מהן; בעמודים האחרים באזור הזה תמצאו חומרי לימוד נוספים אונליין ובמפגשים פרונטליים.
</Intro>
-## Code of Conduct {/*code-of-conduct*/}
+## קוד התנהגות {/*code-of-conduct*/}
-Before participating in React's communities, [please read our Code of Conduct.](https://github.com/facebook/react/blob/main/CODE_OF_CONDUCT.md) We have adopted the [Contributor Covenant](https://www.contributor-covenant.org/) and we expect that all community members adhere to the guidelines within.
+לפני השתתפות בקהילות של React, [אנא קראו את קוד ההתנהגות שלנו.](https://github.com/facebook/react/blob/main/CODE_OF_CONDUCT.md) אימצנו את [Contributor Covenant](https://www.contributor-covenant.org/) ואנחנו מצפים שכל חברי הקהילה יעמדו בהנחיות המופיעות בו.
## Stack Overflow {/*stack-overflow*/}
-Stack Overflow is a popular forum to ask code-level questions or if you're stuck with a specific error. Read through the [existing questions](https://stackoverflow.com/questions/tagged/reactjs) tagged with **reactjs** or [ask your own](https://stackoverflow.com/questions/ask?tags=reactjs)!
+Stack Overflow הוא פורום פופולרי לשאלות ברמת קוד או כשנתקעים עם שגיאה ספציפית. אפשר לעיין ב-[שאלות הקיימות](https://stackoverflow.com/questions/tagged/reactjs) עם התגית **reactjs** או [לשאול שאלה חדשה](https://stackoverflow.com/questions/ask?tags=reactjs)!
-## Popular Discussion Forums {/*popular-discussion-forums*/}
+## פורומי דיון פופולריים {/*popular-discussion-forums*/}
-There are many online forums which are a great place for discussion about best practices and application architecture as well as the future of React. If you have an answerable code-level question, Stack Overflow is usually a better fit.
+יש הרבה פורומים אונליין שהם מקום מצוין לדיון על best practices, ארכיטקטורת אפליקציות וגם העתיד של React. אם יש לכם שאלה נקודתית שאפשר לענות עליה ברמת קוד, בדרך כלל Stack Overflow הוא המקום המתאים יותר.
-Each community consists of many thousands of React users.
+כל קהילה כוללת אלפי משתמשי React.
-* [DEV's React community](https://dev.to/t/react)
-* [Hashnode's React community](https://hashnode.com/n/reactjs)
-* [Reactiflux online chat](https://discord.gg/reactiflux)
-* [Reddit's React community](https://www.reddit.com/r/reactjs/)
+* [קהילת React של DEV](https://dev.to/t/react)
+* [קהילת React של Hashnode](https://hashnode.com/n/reactjs)
+* [צ'אט Reactiflux](https://discord.gg/reactiflux)
+* [קהילת React ב-Reddit](https://www.reddit.com/r/reactjs/)
-## News {/*news*/}
+## חדשות {/*news*/}
-For the latest news about React, [follow **@reactjs** on Twitter](https://twitter.com/reactjs) and the [official React blog](/blog/) on this website.
+לחדשות האחרונות על React, [עקבו אחרי **@reactjs** ב-Twitter](https://twitter.com/reactjs) וגם אחרי [הבלוג הרשמי של React](/blog/) באתר הזה.
diff --git a/src/content/community/meetups.md b/src/content/community/meetups.md
index a12a5349c..b4e3fdaee 100644
--- a/src/content/community/meetups.md
+++ b/src/content/community/meetups.md
@@ -1,10 +1,10 @@
---
-title: React Meetups
+title: מפגשי React
---
<Intro>
-Do you have a local React.js meetup? Add it here! (Please keep the list alphabetical)
+מכירים מפגש React.js מקומי? הוסיפו אותו כאן! (אנא שמרו על הרשימה בסדר אלפביתי)
</Intro>
@@ -222,3 +222,4 @@ Do you have a local React.js meetup? Add it here! (Please keep the list alphabet
* [Tampa, FL - ReactJS](https://www.meetup.com/ReactJS-Tampa-Bay/)
* [Tucson, AZ - ReactJS](https://www.meetup.com/Tucson-ReactJS-Meetup/)
* [Washington, DC - ReactJS](https://www.meetup.com/React-DC/)
+
diff --git a/src/content/community/team.md b/src/content/community/team.md
index 9ef95d64a..9ba800a20 100644
--- a/src/content/community/team.md
+++ b/src/content/community/team.md
@@ -1,99 +1,99 @@
---
-title: "Meet the Team"
+title: "הכירו את הצוות"
---
<Intro>
-React development is led by a dedicated team working full time at Meta. It also receives contributions from people all over the world.
+פיתוח React מוביל צוות ייעודי שעובד במשרה מלאה ב-Meta. בנוסף לכך, הפרויקט מקבל תרומות מאנשים בכל העולם.
</Intro>
-## React Core {/*react-core*/}
+## צוות הליבה של React {/*react-core*/}
-The React Core team members work full time on the core component APIs, the engine that powers React DOM and React Native, React DevTools, and the React documentation website.
+חברי צוות הליבה של React עובדים במשרה מלאה על ממשקי ה-API המרכזיים של קומפוננטות, על המנוע שמפעיל את React DOM ואת React Native, על React DevTools ועל אתר התיעוד של React.
-Current members of the React team are listed in alphabetical order below.
+חברי צוות React הנוכחיים מופיעים למטה לפי סדר אלפביתי.
<TeamMember name="Andrew Clark" permalink="andrew-clark" photo="/images/team/acdlite.jpg" github="acdlite" twitter="acdlite" threads="acdlite" title="Engineer at Vercel">
- Andrew got started with web development by making sites with WordPress, and eventually tricked himself into doing JavaScript. His favorite pastime is karaoke. Andrew is either a Disney villain or a Disney princess, depending on the day.
+ Andrew התחיל בפיתוח אתרים דרך בנייה ב-WordPress, ובסוף "הערים" על עצמו להיכנס ל-JavaScript. התחביב האהוב עליו הוא קריוקי. Andrew הוא או נבל של דיסני או נסיכה של דיסני, תלוי ביום.
</TeamMember>
<TeamMember name="Andrey Lunyov" permalink="andrey-lunyov" photo="/images/team/andrey-lunyov.jpg" github="alunyov" twitter="alunyov" threads="alunyov" title="Engineer at Meta">
- Andrey started his career as a designer and then gradually transitioned into web development. After joining the React Data team at Meta he worked on adding an incremental JavaScript compiler to Relay, and then later on, worked on removing the same compiler from Relay. Outside of work, Andrey likes to play music and engage in various sports.
+ Andrey התחיל את הקריירה כמעצב ואז עבר בהדרגה לפיתוח ווב. אחרי שהצטרף לצוות React Data ב-Meta הוא עבד על הוספת קומפיילר JavaScript אינקרמנטלי ל-Relay, ובהמשך גם על הסרה של אותו קומפיילר מ-Relay. מחוץ לעבודה Andrey אוהב לנגן ולעסוק בספורט.
</TeamMember>
<TeamMember name="Dan Abramov" permalink="dan-abramov" photo="/images/team/gaearon.jpg" github="gaearon" twitter="dan_abramov" title="Independent Engineer">
- Dan got into programming after he accidentally discovered Visual Basic inside Microsoft PowerPoint. He has found his true calling in turning [Sebastian](#sebastian-markbåge)'s tweets into long-form blog posts. Dan occasionally wins at Fortnite by hiding in a bush until the game ends.
+ Dan נכנס לתכנות אחרי שגילה במקרה את Visual Basic בתוך Microsoft PowerPoint. הוא מצא את הייעוד שלו בלהפוך ציוצים של [Sebastian](#sebastian-markbåge) לפוסטים ארוכים בבלוג. מדי פעם Dan מנצח ב-Fortnite בכך שהוא מתחבא בשיח עד סוף המשחק.
</TeamMember>
<TeamMember name="Eli White" permalink="eli-white" photo="/images/team/eli-white.jpg" github="TheSavior" twitter="Eli_White" threads="elicwhite" title="Engineering Manager at Meta">
- Eli got into programming after he got suspended from middle school for hacking. He has been working on React and React Native since 2017. He enjoys eating treats, especially ice cream and apple pie. You can find Eli trying quirky activities like parkour, indoor skydiving, and aerial silks.
+ Eli נכנס לתכנות אחרי שהושעה מחטיבת הביניים בגלל האקינג. הוא עובד על React ו-React Native מאז 2017. הוא נהנה מלאכול מתוקים, במיוחד גלידה ופאי תפוחים. אפשר למצוא את Eli מנסה פעילויות לא שגרתיות כמו פארקור, צניחה חופשית באולם ובדי אוויר.
</TeamMember>
<TeamMember name="Jason Bonta" permalink="jason-bonta" photo="/images/team/jasonbonta.jpg" threads="someextent" title="Engineering Manager at Meta">
- Jason likes having large volumes of Amazon packages delivered to the office so that he can build forts. Despite literally walling himself off from his team at times and not understanding how for-of loops work, we appreciate him for the unique qualities he brings to his work.
+ Jason אוהב להזמין כמויות גדולות של חבילות מאמזון למשרד כדי לבנות מהן מבצרים. למרות שלפעמים הוא ממש בונה חומה בינו לבין הצוות שלו ולא תמיד מבין איך לולאות for-of עובדות, אנחנו מעריכים אותו על התכונות הייחודיות שהוא מביא לעבודה.
</TeamMember>
<TeamMember name="Joe Savona" permalink="joe-savona" photo="/images/team/joe.jpg" github="josephsavona" twitter="en_JS" threads="joesavona" title="Engineer at Meta">
- Joe was planning to major in math and philosophy but got into computer science after writing physics simulations in Matlab. Prior to React, he worked on Relay, RSocket.js, and the Skip programming language. While he’s not building some sort of reactive system he enjoys running, studying Japanese, and spending time with his family.
+ Joe תכנן ללמוד מתמטיקה ופילוסופיה, אבל הגיע למדעי המחשב אחרי שכתב סימולציות פיזיקה ב-Matlab. לפני React הוא עבד על Relay, על RSocket.js ועל שפת התכנות Skip. כשהוא לא בונה מערכת תגובתית כלשהי הוא נהנה מריצה, מלימוד יפנית ומזמן עם המשפחה.
</TeamMember>
<TeamMember name="Josh Story" permalink="josh-story" photo="/images/team/josh.jpg" github="gnoff" twitter="joshcstory" title="Engineer at Vercel">
- Josh majored in Mathematics and discovered programming while in college. His first professional developer job was to program insurance rate calculations in Microsoft Excel, the paragon of Reactive Programming which must be why he now works on React. In between that time Josh has been an IC, Manager, and Executive at a few startups. outside of work he likes to push his limits with cooking.
+ Josh למד מתמטיקה וגילה תכנות במהלך הלימודים. עבודת הפיתוח המקצועית הראשונה שלו הייתה לתכנת חישובי תעריפי ביטוח ב-Microsoft Excel, פסגת ה-Reactive Programming, וכנראה לכן הוא עובד היום על React. בין לבין Josh היה IC, מנהל ואקזקיוטיב בכמה סטארטאפים. מחוץ לעבודה הוא אוהב לאתגר את עצמו בבישול.
</TeamMember>
<TeamMember name="Lauren Tan" permalink="lauren-tan" photo="/images/team/lauren.jpg" github="poteto" twitter="potetotes" threads="potetotes" personal="no.lol" title="Engineer at Meta">
- Lauren’s programming career peaked when she first discovered the `<marquee>` tag. She’s been chasing that high ever since. When she’s not adding bugs into React, she enjoys dropping cheeky memes in chat, and playing all too many video games with her partner, and her dog Zelda.
+ הקריירה של Lauren בתכנות הגיעה לשיא כשגילתה לראשונה את תגית `<marquee>`. מאז היא רודפת אחרי התחושה הזו. כשהיא לא מוסיפה באגים ל-React, היא נהנית לזרוק ממים שובבים בצ'אט ולשחק יותר מדי משחקי וידאו עם בן/בת הזוג שלה ועם הכלבה Zelda.
</TeamMember>
<TeamMember name="Luna Wei" permalink="luna-wei" photo="/images/team/luna-wei.jpg" github="lunaleaps" twitter="lunaleaps" threads="lunaleaps" title="Engineer at Meta">
- Luna first learnt the fundamentals of python at the age of 6 from her father. Since then, she has been unstoppable. Luna aspires to be a gen z, and the road to success is paved with environmental advocacy, urban gardening and lots of quality time with her Voo-Doo’d (as pictured).
+ Luna למדה את יסודות Python בגיל 6 מאביה. מאז אי אפשר לעצור אותה. Luna שואפת להיות דור Z אמיתי, והדרך להצלחה אצלה מרוצפת באקטיביזם סביבתי, גינון עירוני והרבה זמן איכות עם Voo-Doo שלה (כמו בתמונה).
</TeamMember>
<TeamMember name="Matt Carroll" permalink="matt-carroll" photo="/images/team/matt-carroll.png" github="mattcarrollcode" twitter="mattcarrollcode" threads="mattcarrollcode" title="Developer Advocate at Meta">
- Matt stumbled into coding, and since then, has become enamored with creating things in communities that can’t be created alone. Prior to React, he worked on YouTube, the Google Assistant, Fuchsia, and Google Cloud AI and Evernote. When he's not trying to make better developer tools he enjoys the mountains, jazz, and spending time with his family.
+ Matt הגיע לקודינג במקרה, ומאז נשבה בקסם של יצירה בקהילות שבהן אפשר לבנות דברים שאי אפשר לבנות לבד. לפני React הוא עבד על YouTube, על Google Assistant, על Fuchsia ועל Google Cloud AI ו-Evernote. כשהוא לא מנסה לשפר כלי פיתוח הוא נהנה מהרים, ג'אז וזמן משפחה.
</TeamMember>
<TeamMember name="Mofei Zhang" permalink="mofei-zhang" photo="/images/team/mofei-zhang.png" github="mofeiZ" threads="z_mofei" title="Engineer at Meta">
- Mofei started programming when she realized it can help her cheat in video games. She focused on operating systems in undergrad / grad school, but now finds herself happily tinkering on React. Outside of work, she enjoys debugging bouldering problems and planning her next backpacking trip(s).
+ Mofei התחילה לתכנת כשהבינה שזה יכול לעזור לה לרמות במשחקי וידאו. בלימודי התואר היא התמקדה במערכות הפעלה, והיום היא נהנית להתעסק ב-React. מחוץ לעבודה היא נהנית מדיבוג מסלולי בולדרינג ומתכנון טיולי התרמילאות הבאים שלה.
</TeamMember>
<TeamMember name="Noah Lemen" permalink="noah-lemen" photo="/images/team/noahlemen.jpg" github="noahlemen" twitter="noahlemen" threads="noahlemen" personal="noahle.men" title="Engineer at Meta">
- Noah’s interest in UI programming sparked during his education in music technology at NYU. At Meta, he's worked on internal tools, browsers, web performance, and is currently focused on React. Outside of work, Noah can be found tinkering with synthesizers or spending time with his cat.
+ העניין של Noah בתכנות UI התחיל בזמן לימודי טכנולוגיית מוזיקה ב-NYU. ב-Meta הוא עבד על כלים פנימיים, דפדפנים וביצועי ווב, וכיום מתמקד ב-React. מחוץ לעבודה אפשר למצוא אותו מתעסק בסינתיסייזרים או מבלה עם החתול שלו.
</TeamMember>
<TeamMember name="Rick Hanlon" permalink="rick-hanlon" photo="/images/team/rickhanlonii.jpg" github="rickhanlonii" twitter="rickhanlonii" threads="rickhanlonii" personal="rickhanlon.codes" title="Engineer at Meta">
- Ricky majored in theoretical math and somehow found himself on the React Native team for a couple years before joining the React team. When he's not programming you can find him snowboarding, biking, climbing, golfing, or closing GitHub issues that do not match the issue template.
+ Ricky למד מתמטיקה תאורטית ואיכשהו מצא את עצמו בצוות React Native לכמה שנים לפני שהצטרף לצוות React. כשאינו מתכנת אפשר למצוא אותו בסנובורד, רכיבה, טיפוס, גולף או סוגר Issues ב-GitHub שלא תואמים לתבנית.
</TeamMember>
<TeamMember name="Sathya Gunasekaran " permalink="sathya-gunasekaran" photo="/images/team/sathya.jpg" github="gsathya" twitter="_gsathya" threads="gsathya.03" title="Engineer at Meta">
- Sathya hated the Dragon Book in school but somehow ended up working on compilers all his career. When he's not compiling React components, he's either drinking coffee or eating yet another Dosa.
+ Sathya שנא את Dragon Book בלימודים אבל איכשהו סיים קריירה שלמה סביב קומפיילרים. כשהוא לא מקמפל קומפוננטות React הוא כנראה שותה קפה או אוכל עוד דוסה.
</TeamMember>
<TeamMember name="Sebastian Markbåge" permalink="sebastian-markbåge" photo="/images/team/sebmarkbage.jpg" github="sebmarkbage" twitter="sebmarkbage" threads="sebmarkbage" title="Engineer at Vercel">
- Sebastian majored in psychology. He's usually quiet. Even when he says something, it often doesn't make sense to the rest of us until a few months later. The correct way to pronounce his surname is "mark-boa-geh" but he settled for "mark-beige" out of pragmatism -- and that's how he approaches React.
+ Sebastian למד פסיכולוגיה. בדרך כלל הוא שקט. גם כשהוא אומר משהו, לעיתים קרובות זה לא ברור לשאר הצוות עד כמה חודשים אחר כך. ההגייה הנכונה של שם המשפחה שלו היא "mark-boa-geh" אבל מטעמי פרגמטיות הוא הסתפק ב-"mark-beige" וכך גם הגישה שלו ל-React.
</TeamMember>
<TeamMember name="Sebastian Silbermann" permalink="sebastian-silbermann" photo="/images/team/sebsilbermann.jpg" github="eps1lon" twitter="sebsilbermann" threads="sebsilbermann" title="Independent Engineer">
- Sebastian learned programming to make the browser games he played during class more enjoyable. Eventually this lead to contributing to as much open source code as possible. Outside of coding he's busy making sure people don't confuse him with the other Sebastians and Zilberman of the React community.
+ Sebastian למד תכנות כדי להפוך את משחקי הדפדפן ששיחק בהם בזמן שיעור למהנים יותר. בסוף זה הוביל לתרומות לכמה שיותר קוד קוד פתוח. מחוץ לקוד הוא עסוק בלהבטיח שלא יבלבלו בינו לבין ה-Sebastian האחרים ועם Zilberman בקהילת React.
</TeamMember>
<TeamMember name="Seth Webster" permalink="seth-webster" photo="/images/team/seth.jpg" github="sethwebster" twitter="sethwebster" threads="sethwebster" personal="sethwebster.com" title="Engineering Manager at Meta">
- Seth started programming as a kid growing up in Tucson, AZ. After school, he was bitten by the music bug and was a touring musician for about 10 years before returning to *work*, starting with Intuit. In his spare time, he loves [taking pictures](https://www.sethwebster.com) and flying for animal rescues in the northeastern United States.
+ Seth התחיל לתכנת כילד שגדל ב-Tucson, AZ. אחרי הלימודים הוא "נדבק" במוזיקה והיה מוזיקאי מופיע במשך כ-10 שנים לפני שחזר לעבודה, החל מ-Intuit. בזמן הפנוי הוא אוהב [לצלם](https://www.sethwebster.com) ולטוס להצלת בעלי חיים בצפון-מזרח ארצות הברית.
</TeamMember>
<TeamMember name="Sophie Alpert" permalink="sophie-alpert" photo="/images/team/sophiebits.jpg" github="sophiebits" twitter="sophiebits" threads="sophiebits" personal="sophiebits.com" title="Independent Engineer">
- Four days after React was released, Sophie rewrote the entirety of her then-current project to use it, which she now realizes was perhaps a bit reckless. After she became the project's #1 committer, she wondered why she wasn't getting paid by Facebook like everyone else was and joined the team officially to lead React through its adolescent years. Though she quit that job years ago, somehow she's still in the team's group chats and “providing value”.
+ ארבעה ימים אחרי ש-React שוחרר, Sophie כתבה מחדש את כל הפרויקט שעליו עבדה אז כדי להשתמש בו, מה שהיום היא מבינה שהיה אולי קצת נועז מדי. אחרי שהפכה לתורמת מספר 1 בפרויקט, היא תהתה למה היא לא מקבלת שכר מ-Facebook כמו כולם והצטרפה רשמית לצוות כדי להוביל את React בשנות ההתבגרות שלו. למרות שהיא עזבה את התפקיד הזה לפני שנים, איכשהו היא עדיין בקבוצות הצ'אט של הצוות ו"מייצרת ערך".
</TeamMember>
<TeamMember name="Tianyu Yao" permalink="tianyu-yao" photo="/images/team/tianyu.jpg" github="tyao1" twitter="tianyu0" title="Engineer at Meta">
- Tianyu’s interest in computers started as a kid because he loves video games. So he majored in computer science and still plays childish games like League of Legends. When he is not in front of a computer, he enjoys playing with his two kittens, hiking and kayaking.
+ העניין של Tianyu במחשבים התחיל בילדות כי הוא אוהב משחקי וידאו. אז הוא למד מדעי המחשב ועדיין משחק משחקים "ילדותיים" כמו League of Legends. כשהוא לא מול מחשב הוא נהנה לשחק עם שני הגורים שלו, לטייל בטבע ולשוט בקיאק.
</TeamMember>
<TeamMember name="Yuzhi Zheng" permalink="yuzhi-zheng" photo="/images/team/yuzhi.jpg" github="yuzhi" twitter="yuzhiz" threads="yuzhiz" title="Engineering Manager at Meta">
- Yuzhi studied Computer Science in school. She liked the instant gratification of seeing code come to life without having to physically be in a laboratory. Now she’s a manager in the React org. Before management, she used to work on the Relay data fetching framework. In her spare time, Yuzhi enjoys optimizing her life via gardening and home improvement projects.
+ Yuzhi למדה מדעי המחשב בבית הספר. היא אהבה את הסיפוק המיידי שבלראות קוד מתעורר לחיים בלי להיות פיזית במעבדה. היום היא מנהלת בארגון React. לפני הניהול היא עבדה על מסגרת הנתונים Relay. בזמן הפנוי היא נהנית לאופטם את החיים דרך גינון ופרויקטים לשיפור הבית.
</TeamMember>
-## Past contributors {/*past-contributors*/}
+## תורמים בעבר {/*past-contributors*/}
-You can find the past team members and other people who significantly contributed to React over the years on the [acknowledgements](/community/acknowledgements) page.
+את חברי הצוות לשעבר ואנשים נוספים שתרמו באופן משמעותי ל-React לאורך השנים אפשר למצוא בעמוד [תודות](/community/acknowledgements).
diff --git a/src/content/community/versioning-policy.md b/src/content/community/versioning-policy.md
index fad926c57..c54eca98a 100644
--- a/src/content/community/versioning-policy.md
+++ b/src/content/community/versioning-policy.md
@@ -1,165 +1,165 @@
---
-title: Versioning Policy
+title: מדיניות גרסאות
---
<Intro>
-All stable builds of React go through a high level of testing and follow semantic versioning (semver). React also offers unstable release channels to encourage early feedback on experimental features. This page describes what you can expect from React releases.
+כל הגרסאות היציבות של React עוברות רמת בדיקות גבוהה ופועלות לפי ניהול גרסאות סמנטי (semver). React מציעה גם ערוצי הפצה לא יציבים כדי לעודד משוב מוקדם על יכולות ניסיוניות. הדף הזה מסביר למה אפשר לצפות משחרורי React.
</Intro>
-## Stable releases {/*stable-releases*/}
+## שחרורים יציבים {/*stable-releases*/}
-Stable React releases (also known as "Latest" release channel) follow [semantic versioning (semver)](https://semver.org/) principles.
+שחרורי React יציבים (מוכרים גם כערוץ "Latest") פועלים לפי עקרונות [semantic versioning (semver)](https://semver.org/).
-That means that with a version number **x.y.z**:
+כלומר, במספר גרסה **x.y.z**:
-* When releasing **critical bug fixes**, we make a **patch release** by changing the **z** number (ex: 15.6.2 to 15.6.3).
-* When releasing **new features** or **non-critical fixes**, we make a **minor release** by changing the **y** number (ex: 15.6.2 to 15.7.0).
-* When releasing **breaking changes**, we make a **major release** by changing the **x** number (ex: 15.6.2 to 16.0.0).
+* כשמשחררים **תיקוני באגים קריטיים**, מבצעים **patch release** על ידי שינוי המספר **z** (לדוגמה: 15.6.2 ל-15.6.3).
+* כשמשחררים **יכולות חדשות** או **תיקונים לא קריטיים**, מבצעים **minor release** על ידי שינוי המספר **y** (לדוגמה: 15.6.2 ל-15.7.0).
+* כשמשחררים **שינויים שוברים**, מבצעים **major release** על ידי שינוי המספר **x** (לדוגמה: 15.6.2 ל-16.0.0).
-Major releases can also contain new features, and any release can include bug fixes.
+שחרורי major יכולים לכלול גם יכולות חדשות, וכל שחרור יכול לכלול תיקוני באגים.
-Minor releases are the most common type of release.
+שחרורי minor הם סוג השחרור הנפוץ ביותר.
-### Breaking Changes {/*breaking-changes*/}
+### שינויים שוברים {/*breaking-changes*/}
-Breaking changes are inconvenient for everyone, so we try to minimize the number of major releases – for example, React 15 was released in April 2016 and React 16 was released in September 2017, and React 17 was released in October 2020.
+שינויים שוברים לא נוחים לכולם, לכן אנחנו מנסים לצמצם את מספר שחרורי ה-major. לדוגמה, React 15 שוחרר באפריל 2016, React 16 בספטמבר 2017, ו-React 17 באוקטובר 2020.
-Instead, we release new features in minor versions. That means that minor releases are often more interesting and compelling than majors, despite their unassuming name.
+במקום זאת, אנחנו משחררים יכולות חדשות בגרסאות minor. לכן שחרורי minor לעיתים קרובות מעניינים ומשמעותיים יותר מ-major, למרות השם הצנוע שלהם.
-### Commitment to stability {/*commitment-to-stability*/}
+### מחויבות ליציבות {/*commitment-to-stability*/}
-As we change React over time, we try to minimize the effort required to take advantage of new features. When possible, we'll keep an older API working, even if that means putting it in a separate package. For example, [mixins have been discouraged for years](https://legacy.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html) but they're supported to this day [via create-react-class](https://legacy.reactjs.org/docs/react-without-es6.html#mixins) and many codebases continue to use them in stable, legacy code.
+כשאנחנו משנים את React לאורך זמן, אנחנו מנסים לצמצם את המאמץ שנדרש כדי ליהנות מיכולות חדשות. כשאפשר, נשמור על API ישן עובד גם אם זה אומר להעביר אותו לחבילה נפרדת. לדוגמה, [לא ממליצים על mixins כבר שנים](https://legacy.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html), אבל עדיין יש להם תמיכה [באמצעות create-react-class](https://legacy.reactjs.org/docs/react-without-es6.html#mixins), ובסיסי קוד רבים ממשיכים להשתמש בהם בקוד לגאסי יציב.
-Over a million developers use React, collectively maintaining millions of components. The Facebook codebase alone has over 50,000 React components. That means we need to make it as easy as possible to upgrade to new versions of React; if we make large changes without a migration path, people will be stuck on old versions. We test these upgrade paths on Facebook itself – if our team of less than 10 people can update 50,000+ components alone, we hope the upgrade will be manageable for anyone using React. In many cases, we write [automated scripts](https://github.com/reactjs/react-codemod) to upgrade component syntax, which we then include in the open-source release for everyone to use.
+יותר ממיליון מפתחים משתמשים ב-React, וביחד מתחזקים מיליוני קומפוננטות. בבסיס הקוד של Facebook לבדו יש יותר מ-50,000 קומפוננטות React. לכן אנחנו צריכים להפוך את השדרוג לגרסאות חדשות לקל ככל האפשר. אם נעשה שינויים גדולים בלי נתיב מיגרציה, אנשים ייתקעו על גרסאות ישנות. אנחנו בודקים את נתיבי השדרוג האלה גם ב-Facebook עצמה. אם צוות של פחות מ-10 אנשים יכול לעדכן לבד יותר מ-50,000 קומפוננטות, אנחנו מקווים שגם לאחרים יהיה אפשר לנהל את השדרוג. בהרבה מקרים אנחנו כותבים [סקריפטים אוטומטיים](https://github.com/reactjs/react-codemod) לשדרוג תחביר קומפוננטות, ואז מפרסמים אותם בקוד פתוח כדי שכולם יוכלו להשתמש.
-### Gradual upgrades via warnings {/*gradual-upgrades-via-warnings*/}
+### שדרוגים הדרגתיים דרך אזהרות {/*gradual-upgrades-via-warnings*/}
-Development builds of React include many helpful warnings. Whenever possible, we add warnings in preparation for future breaking changes. That way, if your app has no warnings on the latest release, it will be compatible with the next major release. This allows you to upgrade your apps one component at a time.
+גרסאות הפיתוח של React כוללות הרבה אזהרות מועילות. כשאפשר, אנחנו מוסיפים אזהרות כהכנה לשינויים שוברים עתידיים. כך, אם לאפליקציה שלך אין אזהרות בגרסה האחרונה, היא תהיה תואמת גם לגרסת ה-major הבאה. זה מאפשר לשדרג אפליקציות קומפוננטה אחרי קומפוננטה.
-Development warnings won't affect the runtime behavior of your app. That way, you can feel confident that your app will behave the same way between the development and production builds -- the only differences are that the production build won't log the warnings and that it is more efficient. (If you ever notice otherwise, please file an issue.)
+אזהרות פיתוח לא משפיעות על התנהגות זמן הריצה של האפליקציה. לכן אפשר להיות בטוחים שהאפליקציה תתנהג אותו הדבר בין build פיתוח ל-build ייצור. ההבדלים היחידים הם שבייצור לא יופיעו אזהרות, וה-build יעיל יותר. (אם ראית משהו אחר, פתחו issue.)
-### What counts as a breaking change? {/*what-counts-as-a-breaking-change*/}
+### מה נחשב לשינוי שובר? {/*what-counts-as-a-breaking-change*/}
-In general, we *don't* bump the major version number for changes to:
+בדרך כלל אנחנו *לא* מעלים מספר major עבור שינויים ב:
-* **Development warnings.** Since these don't affect production behavior, we may add new warnings or modify existing warnings in between major versions. In fact, this is what allows us to reliably warn about upcoming breaking changes.
-* **APIs starting with `unstable_`.** These are provided as experimental features whose APIs we are not yet confident in. By releasing these with an `unstable_` prefix, we can iterate faster and get to a stable API sooner.
-* **Alpha and Canary versions of React.** We provide alpha versions of React as a way to test new features early, but we need the flexibility to make changes based on what we learn in the alpha period. If you use these versions, note that APIs may change before the stable release.
-* **Undocumented APIs and internal data structures.** If you access internal property names like `__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED` or `__reactInternalInstance$uk43rzhitjg`, there is no warranty. You are on your own.
+* **אזהרות פיתוח.** מכיוון שהן לא משפיעות על ייצור, אנחנו יכולים להוסיף אזהרות חדשות או לשנות אזהרות קיימות בין גרסאות major. למעשה, זה מה שמאפשר לנו להתריע בצורה אמינה על שינויים שוברים עתידיים.
+* **APIs שמתחילים ב-`unstable_`.** אלה יכולות ניסיוניות שעדיין אין לנו ביטחון מלא ב-API שלהן. שחרור עם הקידומת `unstable_` מאפשר לנו להתקדם מהר יותר ולהגיע מוקדם יותר ל-API יציב.
+* **גרסאות Alpha ו-Canary של React.** אנחנו מספקים גרסאות alpha כדי לבדוק יכולות חדשות מוקדם, אבל צריכים גמישות לבצע שינויים לפי מה שנלמד בתקופת ה-alpha. אם משתמשים בגרסאות האלה, חשוב לדעת ש-APIs יכולים להשתנות לפני שחרור יציב.
+* **APIs לא מתועדים ומבני נתונים פנימיים.** אם ניגשים לשמות פנימיים כמו `__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED` או `__reactInternalInstance$uk43rzhitjg`, אין שום הבטחה. אתם לבד.
-This policy is designed to be pragmatic: certainly, we don't want to cause headaches for you. If we bumped the major version for all of these changes, we would end up releasing more major versions and ultimately causing more versioning pain for the community. It would also mean that we can't make progress in improving React as fast as we'd like.
+המדיניות הזו פרגמטית: אנחנו לא רוצים לייצר לכם כאב ראש. אם היינו מעלים major על כל השינויים האלה, היינו מוציאים הרבה יותר גרסאות major ובסוף גורמים ליותר כאב סביב ניהול גרסאות בקהילה. זה גם היה מאט אותנו בשיפור React.
-That said, if we expect that a change on this list will cause broad problems in the community, we will still do our best to provide a gradual migration path.
+עם זאת, אם אנחנו מצפים ששינוי מרשימה זו יגרום בעיות רחבות בקהילה, עדיין נעשה כמיטב יכולתנו לספק נתיב מיגרציה הדרגתי.
-### If a minor release includes no new features, why isn't it a patch? {/*if-a-minor-release-includes-no-new-features-why-isnt-it-a-patch*/}
+### אם בגרסת minor אין יכולות חדשות, למה זו לא גרסת patch? {/*if-a-minor-release-includes-no-new-features-why-isnt-it-a-patch*/}
-It's possible that a minor release will not include new features. [This is allowed by semver](https://semver.org/#spec-item-7), which states **"[a minor version] MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes."**
+ייתכן שגרסת minor לא תכלול יכולות חדשות. [semver מאפשר זאת](https://semver.org/#spec-item-7), וקובע ש-**"[minor version] MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes."**
-However, it does raise the question of why these releases aren't versioned as patches instead.
+ובכל זאת עולה השאלה למה לא לגרס את השחרורים האלה כ-patch.
-The answer is that any change to React (or other software) carries some risk of breaking in unexpected ways. Imagine a scenario where a patch release that fixes one bug accidentally introduces a different bug. This would not only be disruptive to developers, but also harm their confidence in future patch releases. It's especially regrettable if the original fix is for a bug that is rarely encountered in practice.
+התשובה היא שכל שינוי ב-React (או בכל תוכנה אחרת) נושא סיכון לשבירה לא צפויה. דמיינו מצב שבו patch שמתקן באג אחד מכניס בטעות באג אחר. זה לא רק מפריע למפתחים, אלא גם פוגע באמון בגרסאות patch עתידיות. זה מצער במיוחד כשהתיקון המקורי נועד לבאג שכמעט לא פוגשים בפועל.
-We have a pretty good track record for keeping React releases free of bugs, but patch releases have an even higher bar for reliability because most developers assume they can be adopted without adverse consequences.
+יש לנו היסטוריה טובה של שחרורי React נקיים מבאגים, אבל לגרסאות patch יש רף אמינות אפילו גבוה יותר כי רוב המפתחים מניחים שאפשר לאמץ אותן ללא השלכות שליליות.
-For these reasons, we reserve patch releases only for the most critical bugs and security vulnerabilities.
+לכן אנחנו שומרים שחרורי patch רק לבאגים הקריטיים ביותר ולפגיעויות אבטחה.
-If a release includes non-essential changes — such as internal refactors, changes to implementation details, performance improvements, or minor bugfixes — we will bump the minor version even when there are no new features.
+אם שחרור כולל שינויים לא חיוניים, למשל ריפקטור פנימי, שינויים בפרטי מימוש, שיפורי ביצועים או תיקוני באגים קטנים, נעלה את גרסת ה-minor גם אם אין יכולות חדשות.
-## All release channels {/*all-release-channels*/}
+## כל ערוצי ההפצה {/*all-release-channels*/}
-React relies on a thriving open source community to file bug reports, open pull requests, and [submit RFCs](https://github.com/reactjs/rfcs). To encourage feedback we sometimes share special builds of React that include unreleased features.
+React נשענת על קהילת קוד פתוח פעילה שמדווחת באגים, פותחת pull requests ו-[מגישה RFCs](https://github.com/reactjs/rfcs). כדי לעודד משוב אנחנו לפעמים משתפים גרסאות מיוחדות של React שכוללות יכולות שעדיין לא שוחררו.
<Note>
-This section will be most relevant to developers who work on frameworks, libraries, or developer tooling. Developers who use React primarily to build user-facing applications should not need to worry about our prerelease channels.
+הסעיף הזה רלוונטי בעיקר למפתחים שעובדים על frameworks, ספריות או כלי פיתוח. מפתחים שמשתמשים ב-React בעיקר לבניית אפליקציות למשתמשי קצה לרוב לא צריכים להתעסק בערוצי prerelease.
</Note>
-Each of React's release channels is designed for a distinct use case:
+כל ערוץ הפצה של React מיועד לשימוש שונה:
-- [**Latest**](#latest-channel) is for stable, semver React releases. It's what you get when you install React from npm. This is the channel you're already using today. **User-facing applications that consume React directly use this channel.**
-- [**Canary**](#canary-channel) tracks the main branch of the React source code repository. Think of these as release candidates for the next semver release. **[Frameworks or other curated setups may choose to use this channel with a pinned version of React.](/blog/2023/05/03/react-canaries) You can also use Canaries for integration testing between React and third party projects.**
-- [**Experimental**](#experimental-channel) includes experimental APIs and features that aren't available in the stable releases. These also track the main branch, but with additional feature flags turned on. Use this to try out upcoming features before they are released.
+- [**Latest**](#latest-channel) מיועד לגרסאות React יציבות לפי semver. זה מה שמקבלים כשמתקינים React מ-npm. זה הערוץ שבו אתם כבר משתמשים היום. **אפליקציות למשתמשי קצה שצורכות React ישירות משתמשות בערוץ הזה.**
+- [**Canary**](#canary-channel) עוקב אחרי הענף הראשי של מאגר הקוד של React. אפשר לחשוב עליו כעל release candidates לגרסת ה-semver הבאה. **[Frameworks או setups מנוהלים אחרים יכולים לבחור בערוץ הזה עם גרסה נעולה של React.](/blog/2023/05/03/react-canaries) אפשר גם להשתמש ב-Canary לבדיקות אינטגרציה בין React לפרויקטי צד שלישי.**
+- [**Experimental**](#experimental-channel) כולל APIs ויכולות ניסיוניות שלא זמינות בגרסאות יציבות. גם הערוץ הזה עוקב אחרי הענף הראשי, אבל עם דגלי יכולות נוספים מופעלים. משתמשים בו כדי לנסות יכולות עתידיות לפני שחרור.
-All releases are published to npm, but only Latest uses semantic versioning. Prereleases (those in the Canary and Experimental channels) have versions generated from a hash of their contents and the commit date, e.g. `18.3.0-canary-388686f29-20230503` for Canary and `0.0.0-experimental-388686f29-20230503` for Experimental.
+כל הגרסאות מתפרסמות ל-npm, אבל רק Latest משתמש ב-semantic versioning. גרסאות prerelease (בערוצי Canary ו-Experimental) מקבלות מספר גרסה שנוצר מ-hash של התוכן ותאריך הקומיט, למשל `18.3.0-canary-388686f29-20230503` עבור Canary ו-`0.0.0-experimental-388686f29-20230503` עבור Experimental.
-**Both Latest and Canary channels are officially supported for user-facing applications, but with different expectations**:
+**גם Latest וגם Canary נתמכים רשמית לאפליקציות למשתמשי קצה, אבל עם ציפיות שונות**:
-* Latest releases follow the traditional semver model.
-* Canary releases [must be pinned](/blog/2023/05/03/react-canaries) and may include breaking changes. They exist for curated setups (like frameworks) that want to gradually release new React features and bugfixes on their own release schedule.
+* גרסאות Latest פועלות לפי מודל semver המסורתי.
+* גרסאות Canary [חייבות להיות נעולות לגרסה](/blog/2023/05/03/react-canaries) ועלולות לכלול שינויים שוברים. הן מיועדות ל-setup מנוהל (כמו frameworks) שרוצה לשחרר יכולות חדשות ותיקוני באגים של React בקצב שחרור משלו.
-The Experimental releases are provided for testing purposes only, and we provide no guarantees that behavior won't change between releases. They do not follow the semver protocol that we use for releases from Latest.
+גרסאות Experimental ניתנות לצורכי בדיקה בלבד, ואין לנו הבטחה שההתנהגות לא תשתנה בין שחרורים. הן לא פועלות לפי semver כמו הערוץ Latest.
-By publishing prereleases to the same registry that we use for stable releases, we are able to take advantage of the many tools that support the npm workflow, like [unpkg](https://unpkg.com) and [CodeSandbox](https://codesandbox.io).
+פרסום גרסאות prerelease לאותו רג'יסטרי שבו אנחנו משתמשים לגרסאות יציבות מאפשר לנו להיעזר בכלים שתומכים בזרימת העבודה של npm, כמו [unpkg](https://unpkg.com) ו-[CodeSandbox](https://codesandbox.io).
-### Latest channel {/*latest-channel*/}
+### ערוץ Latest {/*latest-channel*/}
-Latest is the channel used for stable React releases. It corresponds to the `latest` tag on npm. It is the recommended channel for all React apps that are shipped to real users.
+Latest הוא הערוץ של גרסאות React יציבות. הוא תואם לתגית `latest` ב-npm. זה הערוץ המומלץ לכל אפליקציות React שמופצות למשתמשים אמיתיים.
-**If you're not sure which channel you should use, it's Latest.** If you're using React directly, this is what you're already using. You can expect updates to Latest to be extremely stable. Versions follow the semantic versioning scheme, as [described earlier.](#stable-releases)
+**אם לא בטוחים באיזה ערוץ לבחור, בוחרים Latest.** אם אתם משתמשים ב-React ישירות, זה כנראה מה שאתם כבר עושים. אפשר לצפות לעדכונים יציבים מאוד בערוץ הזה. המספור פועל לפי semver, כפי ש-[תואר קודם](#stable-releases).
-### Canary channel {/*canary-channel*/}
+### ערוץ Canary {/*canary-channel*/}
-The Canary channel is a prerelease channel that tracks the main branch of the React repository. We use prereleases in the Canary channel as release candidates for the Latest channel. You can think of Canary as a superset of Latest that is updated more frequently.
+ערוץ Canary הוא ערוץ prerelease שעוקב אחרי הענף הראשי של מאגר React. אנחנו משתמשים בשחרורי Canary כ-release candidates לערוץ Latest. אפשר לראות ב-Canary superset של Latest שמתעדכן בתדירות גבוהה יותר.
-The degree of change between the most recent Canary release and the most recent Latest release is approximately the same as you would find between two minor semver releases. However, **the Canary channel does not conform to semantic versioning.** You should expect occasional breaking changes between successive releases in the Canary channel.
+רמת השינוי בין שחרור Canary האחרון לשחרור Latest האחרון דומה בקירוב למה שרואים בין שתי גרסאות minor ב-semver. עם זאת, **ערוץ Canary לא עומד ב-semantic versioning.** יש לצפות לשינויים שוברים מדי פעם בין שחרורים עוקבים בערוץ הזה.
-**Do not use prereleases in user-facing applications directly unless you're following the [Canary workflow](/blog/2023/05/03/react-canaries).**
+**אל תשתמשו ב-prerelease ישירות באפליקציות למשתמשי קצה אלא אם אתם פועלים לפי [תהליך Canary](/blog/2023/05/03/react-canaries).**
-Releases in Canary are published with the `canary` tag on npm. Versions are generated from a hash of the build's contents and the commit date, e.g. `18.3.0-canary-388686f29-20230503`.
+שחרורי Canary מתפרסמים עם התגית `canary` ב-npm. הגרסאות נוצרות מ-hash של תוכן הבנייה ותאריך הקומיט, למשל `18.3.0-canary-388686f29-20230503`.
-#### Using the canary channel for integration testing {/*using-the-canary-channel-for-integration-testing*/}
+#### שימוש בערוץ canary לבדיקות אינטגרציה {/*using-the-canary-channel-for-integration-testing*/}
-The Canary channel also supports integration testing between React and other projects.
+ערוץ Canary תומך גם בבדיקות אינטגרציה בין React לפרויקטים אחרים.
-All changes to React go through extensive internal testing before they are released to the public. However, there are a myriad of environments and configurations used throughout the React ecosystem, and it's not possible for us to test against every single one.
+כל שינוי ב-React עובר בדיקות פנימיות נרחבות לפני שהוא מגיע לציבור. אבל באקו-סיסטם של React יש אינספור סביבות וקונפיגורציות, ואי אפשר לבדוק כולן.
-If you're the author of a third party React framework, library, developer tool, or similar infrastructure-type project, you can help us keep React stable for your users and the entire React community by periodically running your test suite against the most recent changes. If you're interested, follow these steps:
+אם אתם מחברי framework, ספרייה, כלי פיתוח או פרויקט תשתיתי דומה עבור React, תוכלו לעזור לנו לשמור על יציבות React למשתמשים שלכם ולכל הקהילה על ידי הרצה תקופתית של חבילת הבדיקות מול השינויים האחרונים. אם זה רלוונטי עבורכם, פעלו כך:
-- Set up a cron job using your preferred continuous integration platform. Cron jobs are supported by both [CircleCI](https://circleci.com/docs/2.0/triggers/#scheduled-builds) and [Travis CI](https://docs.travis-ci.com/user/cron-jobs/).
-- In the cron job, update your React packages to the most recent React release in the Canary channel, using `canary` tag on npm. Using the npm cli:
+- הגדירו cron job בפלטפורמת ה-CI המועדפת עליכם. גם [CircleCI](https://circleci.com/docs/2.0/triggers/#scheduled-builds) וגם [Travis CI](https://docs.travis-ci.com/user/cron-jobs/) תומכות בכך.
+- בתוך ה-cron job עדכנו את חבילות React לגרסה האחרונה בערוץ Canary באמצעות התגית `canary` ב-npm. עם npm cli:
```console
npm update react@canary react-dom@canary
```
- Or yarn:
+ או עם yarn:
```console
yarn upgrade react@canary react-dom@canary
```
-- Run your test suite against the updated packages.
-- If everything passes, great! You can expect that your project will work with the next minor React release.
-- If something breaks unexpectedly, please let us know by [filing an issue](https://github.com/facebook/react/issues).
+- הריצו את חבילת הבדיקות שלכם מול החבילות המעודכנות.
+- אם הכול עובר, מצוין. סביר שהפרויקט שלכם יעבוד גם עם גרסת ה-minor הבאה של React.
+- אם משהו נשבר בצורה לא צפויה, עדכנו אותנו על ידי [פתיחת issue](https://github.com/facebook/react/issues).
-A project that uses this workflow is Next.js. You can refer to their [CircleCI configuration](https://github.com/zeit/next.js/blob/c0a1c0f93966fe33edd93fb53e5fafb0dcd80a9e/.circleci/config.yml) as an example.
+פרויקט שמשתמש בתהליך הזה הוא Next.js. אפשר לראות את [קונפיגורציית CircleCI](https://github.com/zeit/next.js/blob/c0a1c0f93966fe33edd93fb53e5fafb0dcd80a9e/.circleci/config.yml) שלהם כדוגמה.
-### Experimental channel {/*experimental-channel*/}
+### ערוץ Experimental {/*experimental-channel*/}
-Like Canary, the Experimental channel is a prerelease channel that tracks the main branch of the React repository. Unlike Canary, Experimental releases include additional features and APIs that are not ready for wider release.
+כמו Canary, גם Experimental הוא ערוץ prerelease שעוקב אחרי הענף הראשי של מאגר React. בשונה מ-Canary, שחרורי Experimental כוללים יכולות ו-APIs נוספים שעדיין לא מוכנים לשחרור רחב.
-Usually, an update to Canary is accompanied by a corresponding update to Experimental. They are based on the same source revision, but are built using a different set of feature flags.
+בדרך כלל, עדכון ל-Canary ילווה בעדכון מקביל ל-Experimental. שניהם מבוססים על אותו source revision, אבל נבנים עם סט דגלי יכולות שונה.
-Experimental releases may be significantly different than releases to Canary and Latest. **Do not use Experimental releases in user-facing applications.** You should expect frequent breaking changes between releases in the Experimental channel.
+שחרורי Experimental יכולים להיות שונים משמעותית מ-Canary ומ-Latest. **אל תשתמשו בשחרורי Experimental באפליקציות למשתמשי קצה.** יש לצפות לשינויים שוברים תכופים בין שחרורים בערוץ הזה.
-Releases in Experimental are published with the `experimental` tag on npm. Versions are generated from a hash of the build's contents and the commit date, e.g. `0.0.0-experimental-68053d940-20210623`.
+שחרורי Experimental מתפרסמים עם התגית `experimental` ב-npm. הגרסאות נוצרות מ-hash של תוכן הבנייה ותאריך הקומיט, למשל `0.0.0-experimental-68053d940-20210623`.
-#### What goes into an experimental release? {/*what-goes-into-an-experimental-release*/}
+#### מה נכנס לשחרור experimental? {/*what-goes-into-an-experimental-release*/}
-Experimental features are ones that are not ready to be released to the wider public, and may change drastically before they are finalized. Some experiments may never be finalized -- the reason we have experiments is to test the viability of proposed changes.
+יכולות ניסיוניות הן יכולות שעדיין לא מוכנות לשחרור רחב, ועלולות להשתנות בצורה דרמטית לפני שהן נסגרות סופית. חלק מהניסויים לעולם לא יבשילו. הסיבה לקיומם היא בדיקת ההיתכנות של שינויים מוצעים.
-For example, if the Experimental channel had existed when we announced Hooks, we would have released Hooks to the Experimental channel weeks before they were available in Latest.
+למשל, אם ערוץ Experimental היה קיים כשפרסמנו את Hooks, היינו משחררים את Hooks לערוץ Experimental שבועות לפני שהיו זמינים ב-Latest.
-You may find it valuable to run integration tests against Experimental. This is up to you. However, be advised that Experimental is even less stable than Canary. **We do not guarantee any stability between Experimental releases.**
+ייתכן שיהיה לכם ערך בהרצת בדיקות אינטגרציה מול Experimental. זו החלטה שלכם. עם זאת, חשוב להבין ש-Experimental יציב אפילו פחות מ-Canary. **אנחנו לא מבטיחים יציבות בין שחרורי Experimental.**
-#### How can I learn more about experimental features? {/*how-can-i-learn-more-about-experimental-features*/}
+#### איך אפשר ללמוד עוד על יכולות ניסיוניות? {/*how-can-i-learn-more-about-experimental-features*/}
-Experimental features may or may not be documented. Usually, experiments aren't documented until they are close to shipping in Canary or Latest.
+יכולות ניסיוניות עשויות להיות מתועדות או שלא. בדרך כלל אנחנו לא מתעדים ניסויים עד שהם קרובים לשחרור ב-Canary או ב-Latest.
-If a feature is not documented, they may be accompanied by an [RFC](https://github.com/reactjs/rfcs).
+אם יכולת אינה מתועדת, ייתכן שיש לה [RFC](https://github.com/reactjs/rfcs).
-We will post to the [React blog](/blog) when we're ready to announce new experiments, but that doesn't mean we will publicize every experiment.
+נפרסם ב-[בלוג React](/blog) כשנהיה מוכנים להכריז על ניסויים חדשים, אבל זה לא אומר שנפרסם כל ניסוי.
-You can always refer to our public GitHub repository's [history](https://github.com/facebook/react/commits/main) for a comprehensive list of changes.
+תמיד אפשר לעקוב אחרי [ההיסטוריה](https://github.com/facebook/react/commits/main) במאגר GitHub הציבורי שלנו כדי לקבל רשימה מלאה של שינויים.
diff --git a/src/content/community/videos.md b/src/content/community/videos.md
index 3fad95786..ccf4c71cd 100644
--- a/src/content/community/videos.md
+++ b/src/content/community/videos.md
@@ -1,10 +1,10 @@
---
-title: React Videos
+title: סרטוני React
---
<Intro>
-Videos dedicated to the discussion of React and the React ecosystem.
+סרטונים שמוקדשים לדיון על React ועל האקוסיסטם של React.
</Intro>
@@ -12,72 +12,72 @@ Videos dedicated to the discussion of React and the React ecosystem.
### React 18 Keynote {/*react-18-keynote*/}
-In the keynote, we shared our vision for the future of React starting with React 18.
+ב-keynote שיתפנו את החזון שלנו לעתיד של React, החל מ-React 18.
-Watch the full keynote from [Andrew Clark](https://twitter.com/acdlite), [Juan Tejada](https://twitter.com/_jstejada), [Lauren Tan](https://twitter.com/potetotes), and [Rick Hanlon](https://twitter.com/rickhanlonii) here:
+צפו כאן בהרצאת ה-keynote המלאה של [Andrew Clark](https://twitter.com/acdlite), [Juan Tejada](https://twitter.com/_jstejada), [Lauren Tan](https://twitter.com/potetotes) ו-[Rick Hanlon](https://twitter.com/rickhanlonii):
<YouTubeIframe src="https://www.youtube.com/embed/FZ0cG47msEk" title="YouTube video player" />
### React 18 for Application Developers {/*react-18-for-application-developers*/}
-For a demo of upgrading to React 18, see [Shruti Kapoor](https://twitter.com/shrutikapoor08)’s talk here:
+להדגמה של שדרוג ל-React 18, ראו את ההרצאה של [Shruti Kapoor](https://twitter.com/shrutikapoor08) כאן:
<YouTubeIframe src="https://www.youtube.com/embed/ytudH8je5ko" title="YouTube video player" />
### Streaming Server Rendering with Suspense {/*streaming-server-rendering-with-suspense*/}
-React 18 also includes improvements to server-side rendering performance using Suspense.
+React 18 כוללת גם שיפורים לביצועי רינדור בצד השרת באמצעות Suspense.
-Streaming server rendering lets you generate HTML from React components on the server, and stream that HTML to your users. In React 18, you can use `Suspense` to break down your app into smaller independent units which can be streamed independently of each other without blocking the rest of the app. This means users will see your content sooner and be able to start interacting with it much faster.
+Streaming server rendering מאפשר לייצר HTML מקומפוננטות React בשרת, ולהזרים את ה-HTML למשתמשים. ב-React 18 אפשר להשתמש ב-`Suspense` כדי לפרק את האפליקציה ליחידות עצמאיות קטנות יותר, שאפשר להזרים בנפרד בלי לחסום את שאר האפליקציה. המשמעות היא שהמשתמשים יראו את התוכן מוקדם יותר ויוכלו להתחיל אינטראקציה מהר יותר.
-For a deep dive, see [Shaundai Person](https://twitter.com/shaundai)’s talk here:
+לצלילה עמוקה יותר, ראו את ההרצאה של [Shaundai Person](https://twitter.com/shaundai) כאן:
<YouTubeIframe src="https://www.youtube.com/embed/pj5N-Khihgc" title="YouTube video player" />
### The first React working group {/*the-first-react-working-group*/}
-For React 18, we created our first Working Group to collaborate with a panel of experts, developers, library maintainers, and educators. Together we worked to create our gradual adoption strategy and refine new APIs such as `useId`, `useSyncExternalStore`, and `useInsertionEffect`.
+לקראת React 18 יצרנו את Working Group הראשון שלנו, כדי לשתף פעולה עם פאנל של מומחים, מפתחים, מתחזקי ספריות ואנשי חינוך. יחד בנינו את אסטרטגיית האימוץ ההדרגתי ושייפנו APIs חדשים כמו `useId`, `useSyncExternalStore` ו-`useInsertionEffect`.
-For an overview of this work, see [Aakansha' Doshi](https://twitter.com/aakansha1216)'s talk:
+לסקירה של העבודה הזו, ראו את ההרצאה של [Aakansha' Doshi](https://twitter.com/aakansha1216):
<YouTubeIframe src="https://www.youtube.com/embed/qn7gRClrC9U" title="YouTube video player" />
### React Developer Tooling {/*react-developer-tooling*/}
-To support the new features in this release, we also announced the newly formed React DevTools team and a new Timeline Profiler to help developers debug their React apps.
+כדי לתמוך בפיצ'רים החדשים בשחרור הזה, הכרזנו גם על צוות React DevTools החדש ועל Timeline Profiler חדש כדי לעזור למפתחים לדבג אפליקציות React.
-For more information and a demo of new DevTools features, see [Brian Vaughn](https://twitter.com/brian_d_vaughn)’s talk:
+למידע נוסף ולהדגמה של הפיצ'רים החדשים ב-DevTools, ראו את ההרצאה של [Brian Vaughn](https://twitter.com/brian_d_vaughn):
<YouTubeIframe src="https://www.youtube.com/embed/oxDfrke8rZg" title="YouTube video player" />
### React without memo {/*react-without-memo*/}
-Looking further into the future, [Xuan Huang (黄玄)](https://twitter.com/Huxpro) shared an update from our React Labs research into an auto-memoizing compiler. Check out this talk for more information and a demo of the compiler prototype:
+במבט לעתיד הרחוק יותר, [Xuan Huang (黄玄)](https://twitter.com/Huxpro) שיתף עדכון ממחקר React Labs שלנו על קומפיילר שמבצע auto-memoization. לצפייה במידע נוסף ובהדגמת אב-טיפוס של הקומפיילר:
<YouTubeIframe src="https://www.youtube.com/embed/lGEMwh32soc" title="YouTube video player" />
### React docs keynote {/*react-docs-keynote*/}
-[Rachel Nabors](https://twitter.com/rachelnabors) kicked off a section of talks about learning and designing with React with a keynote about our investment in React's new docs ([now shipped as react.dev](/blog/2023/03/16/introducing-react-dev)):
+[Rachel Nabors](https://twitter.com/rachelnabors) פתחה מקבץ הרצאות על למידה ועיצוב עם React באמצעות keynote על ההשקעה שלנו בתיעוד החדש של React ([כיום זמין כ-react.dev](/blog/2023/03/16/introducing-react-dev)):
<YouTubeIframe src="https://www.youtube.com/embed/mneDaMYOKP8" title="YouTube video player" />
-### And more... {/*and-more*/}
+### ועוד... {/*and-more*/}
-**We also heard talks on learning and designing with React:**
+**שמענו גם הרצאות על למידה ועיצוב עם React:**
* Debbie O'Brien: [Things I learnt from the new React docs](https://youtu.be/-7odLW_hG7s).
* Sarah Rainsberger: [Learning in the Browser](https://youtu.be/5X-WEQflCL0).
* Linton Ye: [The ROI of Designing with React](https://youtu.be/7cPWmID5XAk).
* Delba de Oliveira: [Interactive playgrounds with React](https://youtu.be/zL8cz2W0z34).
-**Talks from the Relay, React Native, and PyTorch teams:**
+**הרצאות מצוותי Relay, React Native ו-PyTorch:**
* Robert Balicki: [Re-introducing Relay](https://youtu.be/lhVGdErZuN4).
* Eric Rozell and Steven Moyes: [React Native Desktop](https://youtu.be/9L4FFrvwJwY).
* Roman Rädle: [On-device Machine Learning for React Native](https://youtu.be/NLj73vrc2I8)
-**And talks from the community on accessibility, tooling, and Server Components:**
+**וגם הרצאות מהקהילה על נגישות, כלי פיתוח ו-Server Components:**
* Daishi Kato: [React 18 for External Store Libraries](https://youtu.be/oPfSC5bQPR8).
* Diego Haz: [Building Accessible Components in React 18](https://youtu.be/dcm8fjBfro8).
@@ -85,39 +85,39 @@ Looking further into the future, [Xuan Huang (黄玄)](https://twitter.com/Huxpr
* Lyle Troxell: [UI tools for artists](https://youtu.be/b3l4WxipFsE).
* Helen Lin: [Hydrogen + React 18](https://youtu.be/HS6vIYkSNks).
-## Older videos {/*older-videos*/}
+## סרטונים ישנים יותר {/*older-videos*/}
### React Conf 2019 {/*react-conf-2019*/}
-A playlist of videos from React Conf 2019.
+פלייליסט סרטונים מ-React Conf 2019.
<YouTubeIframe title="React Conf 2019" src="https://www.youtube-nocookie.com/embed/playlist?list=PLPxbbTqCLbGHPxZpw4xj_Wwg8-fdNxJRh" />
### React Conf 2018 {/*react-conf-2018*/}
-A playlist of videos from React Conf 2018.
+פלייליסט סרטונים מ-React Conf 2018.
<YouTubeIframe title="React Conf 2018" src="https://www.youtube-nocookie.com/embed/playlist?list=PLPxbbTqCLbGE5AihOSExAa4wUM-P42EIJ" />
### React.js Conf 2017 {/*reactjs-conf-2017*/}
-A playlist of videos from React.js Conf 2017.
+פלייליסט סרטונים מ-React.js Conf 2017.
<YouTubeIframe title="React.js Conf 2017" src="https://www.youtube-nocookie.com/embed/playlist?list=PLb0IAmt7-GS3fZ46IGFirdqKTIxlws7e0" />
### React.js Conf 2016 {/*reactjs-conf-2016*/}
-A playlist of videos from React.js Conf 2016.
+פלייליסט סרטונים מ-React.js Conf 2016.
<YouTubeIframe title="React.js Conf 2016" src="https://www.youtube-nocookie.com/embed/playlist?list=PLb0IAmt7-GS0M8Q95RIc2lOM6nc77q1IY" />
### React.js Conf 2015 {/*reactjs-conf-2015*/}
-A playlist of videos from React.js Conf 2015.
+פלייליסט סרטונים מ-React.js Conf 2015.
<YouTubeIframe title="React.js Conf 2015" src="https://www.youtube-nocookie.com/embed/playlist?list=PLb0IAmt7-GS1cbw4qonlQztYV1TAW0sCr" />
### Rethinking Best Practices {/*rethinking-best-practices*/}
-Pete Hunt's talk at JSConf EU 2013 covers three topics: throwing out the notion of templates and building views with JavaScript, “re-rendering” your entire application when your data changes, and a lightweight implementation of the DOM and events - (2013 - 0h30m).
+ההרצאה של Pete Hunt ב-JSConf EU 2013 עוסקת בשלושה נושאים: ויתור על רעיון התבניות ובניית views עם JavaScript, "רינדור מחדש" של כל האפליקציה כשנתונים משתנים, ומימוש קל משקל של DOM ואירועים (2013 - 0h30m).
<YouTubeIframe title="Pete Hunt: React: Rethinking Best Practices - JSConf EU 2013" src="https://www.youtube-nocookie.com/embed/x7cQ3mrcKaY" />
### Introduction to React {/*introduction-to-react*/}
-Tom Occhino and Jordan Walke introduce React at Facebook Seattle - (2013 - 1h20m).
+Tom Occhino ו-Jordan Walke מציגים את React ב-Facebook Seattle (2013 - 1h20m).
<YouTubeIframe title="Tom Occhino and Jordan Walke introduce React at Facebook Seattle" src="https://www.youtube-nocookie.com/embed/XxVg_s8xAms" />
diff --git a/src/content/errors/377.md b/src/content/errors/377.md
index 6269e9d06..54d445e31 100644
--- a/src/content/errors/377.md
+++ b/src/content/errors/377.md
@@ -1,13 +1,13 @@
<Intro>
-In the minified production build of React, we avoid sending down full error messages in order to reduce the number of bytes sent over the wire.
+בגרסת ה-production המכווצת (minified) של React אנחנו נמנעים משליחת הודעות שגיאה מלאות, כדי לצמצם את מספר הבתים שנשלחים ברשת.
</Intro>
-We highly recommend using the development build locally when debugging your app since it tracks additional debug info and provides helpful warnings about potential problems in your apps, but if you encounter an exception while using the production build, this page will reassemble the original error message.
+אנחנו ממליצים מאוד להשתמש מקומית בגרסת הפיתוח כשמדבגים את האפליקציה, כי היא עוקבת אחרי מידע דיבוג נוסף ומספקת אזהרות מועילות על בעיות פוטנציאליות באפליקציה. עם זאת, אם מופיעה חריגה בזמן שימוש בגרסת production, העמוד הזה ירכיב מחדש את הודעת השגיאה המקורית.
-The full text of the error you just encountered is:
+הטקסט המלא של השגיאה שבה נתקלתם הוא:
<ErrorDecoder />
-This error occurs when you pass a BigInt value from a Server Component to a Client Component.
+השגיאה הזו מתרחשת כשמעבירים ערך מסוג BigInt מ-Server Component אל Client Component.
diff --git a/src/content/errors/generic.md b/src/content/errors/generic.md
index 27c3ca52d..7e0d491d9 100644
--- a/src/content/errors/generic.md
+++ b/src/content/errors/generic.md
@@ -1,11 +1,11 @@
<Intro>
-In the minified production build of React, we avoid sending down full error messages in order to reduce the number of bytes sent over the wire.
+בגרסת ה-production המכווצת (minified) של React אנחנו נמנעים משליחת הודעות שגיאה מלאות, כדי לצמצם את מספר הבתים שנשלחים ברשת.
</Intro>
-We highly recommend using the development build locally when debugging your app since it tracks additional debug info and provides helpful warnings about potential problems in your apps, but if you encounter an exception while using the production build, this page will reassemble the original error message.
+אנחנו ממליצים מאוד להשתמש מקומית בגרסת הפיתוח כשמדבגים את האפליקציה, כי היא עוקבת אחרי מידע דיבוג נוסף ומספקת אזהרות מועילות על בעיות פוטנציאליות באפליקציה. עם זאת, אם מופיעה חריגה בזמן שימוש בגרסת production, העמוד הזה ירכיב מחדש את הודעת השגיאה המקורית.
-The full text of the error you just encountered is:
+הטקסט המלא של השגיאה שבה נתקלתם הוא:
<ErrorDecoder />
diff --git a/src/content/errors/index.md b/src/content/errors/index.md
index 25746d25d..7efe4207e 100644
--- a/src/content/errors/index.md
+++ b/src/content/errors/index.md
@@ -1,10 +1,10 @@
<Intro>
-In the minified production build of React, we avoid sending down full error messages in order to reduce the number of bytes sent over the wire.
+בגרסת ה-production המכווצת (minified) של React אנחנו נמנעים משליחת הודעות שגיאה מלאות, כדי לצמצם את מספר הבתים שנשלחים ברשת.
</Intro>
-We highly recommend using the development build locally when debugging your app since it tracks additional debug info and provides helpful warnings about potential problems in your apps, but if you encounter an exception while using the production build, the error message will include just a link to the docs for the error.
+אנחנו ממליצים מאוד להשתמש מקומית בגרסת הפיתוח כשמדבגים את האפליקציה, כי היא עוקבת אחרי מידע דיבוג נוסף ומספקת אזהרות מועילות על בעיות פוטנציאליות באפליקציה. עם זאת, אם מופיעה חריגה בזמן שימוש בגרסת production, הודעת השגיאה תכלול רק קישור לתיעוד של אותה שגיאה.
-For an example, see: [https://react.dev/errors/149](/errors/421).
+לדוגמה, ראו: [https://react.dev/errors/149](/errors/421).
diff --git a/src/content/index.md b/src/content/index.md
index 63dbd33eb..e4de66aa6 100644
--- a/src/content/index.md
+++ b/src/content/index.md
@@ -4,4 +4,4 @@ title: React
permalink: index.html
---
-{/* See HomeContent.js */}
\ No newline at end of file
+{/* ראה HomeContent.js */}
diff --git a/src/content/learn/add-react-to-an-existing-project.md b/src/content/learn/add-react-to-an-existing-project.md
index f494b0ab1..2cd62c2ec 100644
--- a/src/content/learn/add-react-to-an-existing-project.md
+++ b/src/content/learn/add-react-to-an-existing-project.md
@@ -1,59 +1,59 @@
---
-title: Add React to an Existing Project
+title: "הוספת React לפרויקט קיים"
---
<Intro>
-If you want to add some interactivity to your existing project, you don't have to rewrite it in React. Add React to your existing stack, and render interactive React components anywhere.
+אם אתם רוצים להוסיף אינטראקטיביות לפרויקט קיים, אין צורך לכתוב אותו מחדש ב-React. הוסיפו React ל-stack הקיים שלכם, ורנדרו קומפוננטות React אינטראקטיביות בכל מקום.
</Intro>
<Note>
-**You need to install [Node.js](https://nodejs.org/en/) for local development.** Although you can [try React](/learn/installation#try-react) online or with a simple HTML page, realistically most JavaScript tooling you'll want to use for development requires Node.js.
+**צריך להתקין [Node.js](https://nodejs.org/en/) לפיתוח מקומי.** למרות שאפשר [לנסות React](/learn/installation#try-react) אונליין או עם דף HTML פשוט, רוב כלי הפיתוח של JavaScript שתרצו להשתמש בהם דורשים Node.js.
</Note>
-## Using React for an entire subroute of your existing website {/*using-react-for-an-entire-subroute-of-your-existing-website*/}
+## שימוש ב-React עבור תת-נתיב (subroute) שלם באתר קיים {/*using-react-for-an-hele-subroute-of-your-existing-site*/}
-Let's say you have an existing web app at `example.com` built with another server technology (like Rails), and you want to implement all routes starting with `example.com/some-app/` fully with React.
+נניח שיש לכם אפליקציית ווב קיימת ב-`example.com` שבנויה בטכנולוגיית שרת אחרת (למשל Rails), ואתם רוצים שכל הנתיבים שמתחילים ב-`example.com/some-app/` ימומשו במלואם עם React.
-Here's how we recommend to set it up:
+כך אנחנו ממליצים להגדיר זאת:
-1. **Build the React part of your app** using one of the [React-based frameworks](/learn/start-a-new-react-project).
-2. **Specify `/some-app` as the *base path*** in your framework's configuration (here's how: [Next.js](https://nextjs.org/docs/api-reference/next.config.js/basepath), [Gatsby](https://www.gatsbyjs.com/docs/how-to/previews-deploys-hosting/path-prefix/)).
-3. **Configure your server or a proxy** so that all requests under `/some-app/` are handled by your React app.
+1. **בנו את חלק ה-React באפליקציה** באמצעות אחד מ-[frameworks שמבוססים על React](/learn/start-a-new-react-project).
+2. **הגדירו את `/some-app` כ-*base path*** בקונפיגורציית ה-framework (ראו: [Next.js](https://nextjs.org/docs/api-reference/next.config.js/basepath), [Gatsby](https://www.gatsbyjs.com/docs/how-to/previews-deploys-hosting/path-prefix/)).
+3. **הגדירו את השרת או proxy** כך שכל הבקשות תחת `/some-app/` יטופלו על ידי אפליקציית React.
-This ensures the React part of your app can [benefit from the best practices](/learn/start-a-new-react-project#can-i-use-react-without-a-framework) baked into those frameworks.
+כך החלק של React באפליקציה [ייהנה ממיטב הפרקטיקות](/learn/start-a-new-react-project#can-i-use-react-without-a-framework) שמובנות ב-frameworks האלה.
-Many React-based frameworks are full-stack and let your React app take advantage of the server. However, you can use the same approach even if you can't or don't want to run JavaScript on the server. In that case, serve the HTML/CSS/JS export ([`next export` output](https://nextjs.org/docs/advanced-features/static-html-export) for Next.js, default for Gatsby) at `/some-app/` instead.
+רבים מה-frameworks מבוססי React הם full-stack ומאפשרים לאפליקציית React לנצל יכולות שרת. עם זאת, אפשר להשתמש באותה גישה גם אם אינכם יכולים או לא רוצים להריץ JavaScript על השרת. במקרה כזה, אפשר להגיש תחת `some-app/` פלט סטטי של HTML/CSS/JS ([פלט של `next export`](https://nextjs.org/docs/advanced-features/static-html-export) ב-Next.js, וברירת המחדל ב-Gatsby).
-## Using React for a part of your existing page {/*using-react-for-a-part-of-your-existing-page*/}
+## שימוש ב-React עבור חלק מעמוד קיים {/*using-react-for-a-part-of-your-existing-page*/}
-Let's say you have an existing page built with another technology (either a server one like Rails, or a client one like Backbone), and you want to render interactive React components somewhere on that page. That's a common way to integrate React--in fact, it's how most React usage looked at Meta for many years!
+נניח שיש לכם עמוד קיים שבנוי בטכנולוגיה אחרת (שרתית כמו Rails או בצד לקוח), ואתם רוצים לרנדר קומפוננטות React אינטראקטיביות באזור מסוים בעמוד. למעשה, כך חלק גדול מהשימוש ב-React ב-Meta נראה במשך שנים רבות.
-You can do this in two steps:
+אפשר לעשות זאת בשני שלבים:
-1. **Set up a JavaScript environment** that lets you use the [JSX syntax](/learn/writing-markup-with-jsx), split your code into modules with the [`import`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) / [`export`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export) syntax, and use packages (for example, React) from the [npm](https://www.npmjs.com/) package registry.
-2. **Render your React components** where you want to see them on the page.
+1. **הגדירו סביבת JavaScript** שמאפשרת להשתמש ב-[תחביר JSX](/learn/writing-markup-with-jsx), לפצל קוד למודולים עם [`import`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) ו-[`export`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export), ולהשתמש בחבילות מ-[npm](https://www.npmjs.com/), כולל React.
+2. **רנדרו קומפוננטות React** במקומות שבהם אתם רוצים שיופיעו בעמוד.
-The exact approach depends on your existing page setup, so let's walk through some details.
+הגישה המדויקת תלויה ב-setup הנוכחי של העמוד, אז נעבור על הפרטים.
-### Step 1: Set up a modular JavaScript environment {/*step-1-set-up-a-modular-javascript-environment*/}
+### שלב 1: הגדרת סביבת JavaScript מודולרית {/*step-1-set-up-a-modular-javascript-environment*/}
-A modular JavaScript environment lets you write your React components in individual files, as opposed to writing all of your code in a single file. It also lets you use all the wonderful packages published by other developers on the [npm](https://www.npmjs.com/) registry--including React itself! How you do this depends on your existing setup:
+סביבת JavaScript מודולרית מאפשרת לכתוב קומפוננטות React בקבצים נפרדים במקום לרכז הכול בקובץ אחד. בנוסף, היא מאפשרת להשתמש בחבילות שזמינות ב-[npm](https://www.npmjs.com/), כולל React עצמה. איך עושים את זה תלוי ב-setup הקיים שלכם:
-* **If your app is already split into files that use `import` statements,** try to use the setup you already have. Check whether writing `<div />` in your JS code causes a syntax error. If it causes a syntax error, you might need to [transform your JavaScript code with Babel](https://babeljs.io/setup), and enable the [Babel React preset](https://babeljs.io/docs/babel-preset-react) to use JSX.
+* **אם האפליקציה שלכם כבר מפוצלת לקבצים שמשתמשים ב-`import`,** נסו להשתמש ב-setup הקיים. בדקו אם כתיבה של `<div />` בקוד JS גורמת לשגיאת תחביר. אם כן, ייתכן שתצטרכו [להעביר את הקוד דרך Babel](https://babeljs.io/setup) ולהפעיל את [Babel React preset](https://babeljs.io/docs/babel-preset-react) כדי להשתמש ב-JSX.
-* **If your app doesn't have an existing setup for compiling JavaScript modules,** set it up with [Vite](https://vitejs.dev/). The Vite community maintains [many integrations with backend frameworks](https://github.com/vitejs/awesome-vite#integrations-with-backends), including Rails, Django, and Laravel. If your backend framework is not listed, [follow this guide](https://vitejs.dev/guide/backend-integration.html) to manually integrate Vite builds with your backend.
+* **אם לאפליקציה שלכם אין setup לקומפילציה של מודולי JavaScript,** הגדירו זאת עם [Vite](https://vitejs.dev/). קהילת Vite מתחזקת [אינטגרציות רבות עם backends](https://github.com/vitejs/awesome-vite#integrations-with-backends), כולל Rails, Django ו-Laravel. אם ה-framework שלכם לא מופיע שם, [עקבו אחרי המדריך הזה](https://vitejs.dev/guide/backend-integration.html) כדי לשלב ידנית את Vite עם ה-backend.
-To check whether your setup works, run this command in your project folder:
+כדי לבדוק שה-setup עובד, הריצו את הפקודה הזו בתיקיית הפרויקט:
<TerminalBlock>
npm install react react-dom
</TerminalBlock>
-Then add these lines of code at the top of your main JavaScript file (it might be called `index.js` or `main.js`):
+לאחר מכן הוסיפו את שורות הקוד האלה בראש קובץ ה-JavaScript הראשי (למשל `index.js` או `main.js`):
<Sandpack>
@@ -80,17 +80,17 @@ root.render(<h1>Hello, world</h1>);
</Sandpack>
-If the entire content of your page was replaced by a "Hello, world!", everything worked! Keep reading.
+אם כל התוכן בעמוד הוחלף ב-"Hello, world!", הכול עבד. המשיכו לקרוא.
<Note>
-Integrating a modular JavaScript environment into an existing project for the first time can feel intimidating, but it's worth it! If you get stuck, try our [community resources](/community) or the [Vite Chat](https://chat.vitejs.dev/).
+שילוב סביבת JavaScript מודולרית בפרויקט קיים בפעם הראשונה יכול להרגיש מרתיע, אבל זה שווה את זה. אם נתקעתם, נסו את [משאבי הקהילה](/community) או את [Vite Chat](https://chat.vitejs.dev/).
</Note>
-### Step 2: Render React components anywhere on the page {/*step-2-render-react-components-anywhere-on-the-page*/}
+### שלב 2: רינדור קומפוננטות React בכל מקום בעמוד {/*step-2-render-react-components-anywhere-on-the-page*/}
-In the previous step, you put this code at the top of your main file:
+בשלב הקודם שמתם את הקוד הזה בראש הקובץ הראשי:
```js
import { createRoot } from 'react-dom/client';
@@ -103,11 +103,11 @@ const root = createRoot(document.getElementById('app'));
root.render(<h1>Hello, world</h1>);
```
-Of course, you don't actually want to clear the existing HTML content!
+כמובן, אתם לא באמת רוצים למחוק את תוכן ה-HTML הקיים.
-Delete this code.
+מחקו את הקוד הזה.
-Instead, you probably want to render your React components in specific places in your HTML. Open your HTML page (or the server templates that generate it) and add a unique [`id`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id) attribute to any tag, for example:
+במקום זאת, סביר שתרצו לרנדר קומפוננטות React בנקודות ספציפיות ב-HTML שלכם. פתחו את עמוד ה-HTML (או את תבניות השרת שמייצרות אותו) והוסיפו מאפיין [`id`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id) ייחודי לכל תגית יעד, לדוגמה:
```html
<!-- ... somewhere in your html ... -->
@@ -115,7 +115,7 @@ Instead, you probably want to render your React components in specific places in
<!-- ... more html ... -->
```
-This lets you find that HTML element with [`document.getElementById`](https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById) and pass it to [`createRoot`](/reference/react-dom/client/createRoot) so that you can render your own React component inside:
+כך תוכלו למצוא את אלמנט ה-HTML עם [`document.getElementById`](https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById) ולהעביר אותו ל-[`createRoot`](/reference/react-dom/client/createRoot):
<Sandpack>
@@ -146,10 +146,10 @@ root.render(<NavigationBar />);
</Sandpack>
-Notice how the original HTML content from `index.html` is preserved, but your own `NavigationBar` React component now appears inside the `<nav id="navigation">` from your HTML. Read the [`createRoot` usage documentation](/reference/react-dom/client/createRoot#rendering-a-page-partially-built-with-react) to learn more about rendering React components inside an existing HTML page.
+שימו לב שתוכן ה-HTML המקורי מ-`index.html` נשמר, אבל קומפוננטת React בשם `NavigationBar` מופיעה עכשיו בתוך `<nav id="navigation">`. קראו את [תיעוד השימוש ב-`createRoot`](/reference/react-dom/client/createRoot#rendering-a-page-partially-built-with-react) כדי ללמוד עוד על רינדור קומפוננטות React בתוך עמוד HTML קיים.
-When you adopt React in an existing project, it's common to start with small interactive components (like buttons), and then gradually keep "moving upwards" until eventually your entire page is built with React. If you ever reach that point, we recommend migrating to [a React framework](/learn/start-a-new-react-project) right after to get the most out of React.
+כשמאמצים React בפרויקט קיים, נפוץ להתחיל בקומפוננטות אינטראקטיביות קטנות (כמו כפתורים), ואז להתקדם בהדרגה "למעלה" עד שלבסוף כל העמוד בנוי ב-React. אם הגעתם לנקודה הזו, אנחנו ממליצים לעבור ל-[React framework](/learn/start-a-new-react-project) כדי להפיק את המקסימום מ-React.
-## Using React Native in an existing native mobile app {/*using-react-native-in-an-existing-native-mobile-app*/}
+## שימוש ב-React Native באפליקציית מובייל native קיימת {/*using-react-native-in-an-existing-native-mobile-app*/}
-[React Native](https://reactnative.dev/) can also be integrated into existing native apps incrementally. If you have an existing native app for Android (Java or Kotlin) or iOS (Objective-C or Swift), [follow this guide](https://reactnative.dev/docs/integration-with-existing-apps) to add a React Native screen to it.
+אפשר לשלב [React Native](https://reactnative.dev/) גם באפליקציות native קיימות בצורה הדרגתית. אם יש לכם אפליקציית native קיימת ל-Android (Java או Kotlin) או ל-iOS (Objective-C או Swift), [עקבו אחרי המדריך הזה](https://reactnative.dev/docs/integration-with-existing-apps) כדי להוסיף לה מסך React Native.
diff --git a/src/content/learn/adding-interactivity.md b/src/content/learn/adding-interactivity.md
index 0d4a3b23f..77328f0d7 100644
--- a/src/content/learn/adding-interactivity.md
+++ b/src/content/learn/adding-interactivity.md
@@ -1,30 +1,30 @@
---
-title: Adding Interactivity
+title: הוספת אינטראקטיביות
---
<Intro>
-Some things on the screen update in response to user input. For example, clicking an image gallery switches the active image. In React, data that changes over time is called *state.* You can add state to any component, and update it as needed. In this chapter, you'll learn how to write components that handle interactions, update their state, and display different output over time.
+כמה דברים על המסך מתעדכנים בתגובה לקלט המשתמש. לדוגמה, לחיצה על גלריית תמונות משנה את התמונה הפעילה. ב-React, נתונים המשתנים עם הזמן נקראים *state.* ניתן להוסיף מצב לכל רכיב, ולעדכן אותו לפי הצורך. בפרק זה, תלמד איך לכתוב רכיבים המטפלים באינטראקציות, לעדכן את הstate ולהציג פלט שונה לאורך זמן.
</Intro>
<YouWillLearn isChapter={true}>
-* [How to handle user-initiated events](/learn/responding-to-events)
-* [How to make components "remember" information with state](/learn/state-a-components-memory)
-* [How React updates the UI in two phases](/learn/render-and-commit)
-* [Why state doesn't update right after you change it](/learn/state-as-a-snapshot)
-* [How to queue multiple state updates](/learn/queueing-a-series-of-state-updates)
-* [How to update an object in state](/learn/updating-objects-in-state)
-* [How to update an array in state](/learn/updating-arrays-in-state)
+* [כיצד לרבות באירועים ביוזמת המשתמש](/learn/responding-to-events)
+* [כיצד לגרום לרכיבים "לזכור" מידע עם מצב](/learn/state-a-components-memory)
+* [איך React מעדכן את ממשק משתמש בשני שלבים](/learn/render-and-commit)
+* [מדוע הstate לא מתעדכן מיד אחרי שאתה משנה אותו](/learn/state-as-a-snapshot)
+* [כיצד ונהלה בתור עדכוני מצב מרובים](/learn/queueing-a-series-of-state-updates)
+* [כיצד לעדכן אובייקט בstate](/learn/updating-objects-in-state)
+* [כיצד לעדכן מערך בstate](/learn/updating-arrays-in-state)
</YouWillLearn>
-## Responding to events {/*responding-to-events*/}
+## מגיבים לאירועים {/*מגיבים-לאירועים*/}
-React lets you add *event handlers* to your JSX. Event handlers are your own functions that will be triggered in response to user interactions like clicking, hovering, focusing on form inputs, and so on.
+תגיב יכול לך להוסיף *מטפלי אירועים* ל-JSX שלך. מטפלי אירועים הם פונקציות משלך שיופעלו בתגובה לאינטראקציות של משתמשים כמו לחיצה, ריחוף, הבדיקות בקלט טפסים וכן הלאה.
-Built-in components like `<button>` only support built-in browser events like `onClick`. However, you can also create your own components, and give their event handler props any application-specific names that you like.
+רכיבים מובנים כמו ``<button>`` תומכים רק באירועי דפדפן מובנים כמו `onClick`. עם זאת, אתה יכול גם ליצור רכיבים משלך, ולתת לprops שלהם למטפל באירועים כל שמות פרטים לאפליקציה שאתה אוהב.
<Sandpack>
@@ -68,22 +68,22 @@ button { margin-right: 10px; }
<LearnMore path="/learn/responding-to-events">
-Read **[Responding to Events](/learn/responding-to-events)** to learn how to add event handlers.
+קרא את **[להגיב לאירועים](/learn/reponding-to-events)** כדי ללמוד כיצד להוסיף מטפלי אירועים.
</LearnMore>
-## State: a component's memory {/*state-a-components-memory*/}
+## מצב: זיכרון של רכיב {/*state-a-components-memory*/}
-Components often need to change what's on the screen as a result of an interaction. Typing into the form should update the input field, clicking "next" on an image carousel should change which image is displayed, clicking "buy" puts a product in the shopping cart. Components need to "remember" things: the current input value, the current image, the shopping cart. In React, this kind of component-specific memory is called *state.*
+רכיבים צריכים לעשות את מה שמופיע על המסך כמו מאינטראקציה. הקלדה בטופס אמורה לעדכן את שדה הקלט, לחיצה על "הבא" בקרוסלת תמונה אמורה לשנות איזו תמונה מוצגת, לחיצה על "קנה" מכניסה מוצר לסל הקניות. רכיבים צריכים "לזכור" דברים: ערך הקלט הנוכחית, התמונה הנוכחית, עגלת הקניות. ב-React, סוג זה של זיכרון ספציפי לרכיב נקרא *מצב.*
-You can add state to a component with a [`useState`](/reference/react/useState) Hook. *Hooks* are special functions that let your components use React features (state is one of those features). The `useState` Hook lets you declare a state variable. It takes the initial state and returns a pair of values: the current state, and a state setter function that lets you update it.
+אתה יכול להוסיף מצב לרכיב עם [`useState`](/reference/react/useState) Hook. *הHooks* הם פונקציות מיוחדות האפשרויות לרכיבים שלך להשתמש בתכונות React (מצב אחד מהתכונות הללו). ה- `useState` Hook יכול לך להכריז על ניהול מצב. זה לוקח את הstate ההתחלתי ומחזיר ערכים זוג: הstate הנוכחי ופונקציה קובעת מצב שמאפשרת לעדכן אותו.
```js
const [index, setIndex] = useState(0);
const [showMore, setShowMore] = useState(false);
```
-Here is how an image gallery uses and updates state on click:
+הנה איך גלריית תמונות משתמשת ומעדכנת מצב בלחיצה:
<Sandpack>
@@ -229,19 +229,19 @@ button {
<LearnMore path="/learn/state-a-components-memory">
-Read **[State: A Component's Memory](/learn/state-a-components-memory)** to learn how to remember a value and update it on interaction.
+קרא את **[מצב: זיכרון של רכיב](/learn/state-a-components-memory)** כדי ללמוד לזכור ערך ולעדכן אותו באינטראקציה.
</LearnMore>
-## Render and commit {/*render-and-commit*/}
+## עיבוד וביצוע {/*עיבוד-וביצוע*/}
-Before your components are displayed on the screen, they must be rendered by React. Understanding the steps in this process will help you think about how your code executes and explain its behavior.
+לפני שהרכיבים שלך יוצגו על המסך, הם חייבים להיות עובדים על ידי React. הבנת את החשבון שלך בפעולה זו תעזור לך על ביצוע הקוד ולהסביר את ההתנהלות.
-Imagine that your components are cooks in the kitchen, assembling tasty dishes from ingredients. In this scenario, React is the waiter who puts in requests from customers and brings them their orders. This process of requesting and serving UI has three steps:
+דמיינו שהרכיבים שלכם הם מטבחים במטבח. בתרחיש זה, תגיב הוא המלצר שמגיש בקשות מלקוחות ומביא להם את ההזמנות שלהם. לתהליך זה של בקשה והגשה של ממשק משתמש יש שלושה שלבים:
-1. **Triggering** a render (delivering the diner's order to the kitchen)
-2. **Rendering** the component (preparing the order in the kitchen)
-3. **Committing** to the DOM (placing the order on the table)
+1. **הפעלת** עיבוד (משלוח הזמנת הסועד למטבח)
+2. **עיבוד** הרכיב (הכנת ההזמנה במטבח)
+3. **מתחייב** ל-DOM (ביצוע ההזמנה על השולחן)
<IllustrationBlock sequential>
<Illustration caption="Trigger" alt="React as a server in a restaurant, fetching orders from the users and delivering them to the Component Kitchen." src="/images/docs/illustrations/i_render-and-commit1.png" />
@@ -251,13 +251,13 @@ Imagine that your components are cooks in the kitchen, assembling tasty dishes f
<LearnMore path="/learn/render-and-commit">
-Read **[Render and Commit](/learn/render-and-commit)** to learn the lifecycle of a UI update.
+קרא את **[render and Commit](/learn/render-and-commit)** כדי ללמוד את המחזור החיים של עדכון ממשק משתמש.
</LearnMore>
-## State as a snapshot {/*state-as-a-snapshot*/}
+## מצב כתמונת מצב {/*מצב-כתמונת-מצב*/}
-Unlike regular JavaScript variables, React state behaves more like a snapshot. Setting it does not change the state variable you already have, but instead triggers a re-render. This can be surprising at first!
+צריך למשתני JavaScript רגילים, מצב תגובה מתנהג יותר כמו תמונת מצב. הגדר את זה לא משנה את הstate הstate יש לך, אלא מפעיל עיבוד מחדש. זה יכול להיות מפתיע בהתחלה!
```js
console.log(count); // 0
@@ -265,7 +265,7 @@ setCount(count + 1); // Request a re-render with 1
console.log(count); // Still 0!
```
-This behavior help you avoid subtle bugs. Here is a little chat app. Try to guess what happens if you press "Send" first and *then* change the recipient to Bob. Whose name will appear in the `alert` five seconds later?
+התנהגות זו עוזרת לך להימנע מבאגים עדינים. הנה אפליקציית צ'אט קטנה. נסו לנחש מה קורה אם תלחצו תחילה על "שלח" ו*אחר כך* תשנה את הנמען לבוב. שמו של מי יופיע ב'התראה' חמש שניות מאוחר יותר?
<Sandpack>
@@ -314,13 +314,13 @@ label, textarea { margin-bottom: 10px; display: block; }
<LearnMore path="/learn/state-as-a-snapshot">
-Read **[State as a Snapshot](/learn/state-as-a-snapshot)** to learn why state appears "fixed" and unchanging inside the event handlers.
+קרא את **[מצב כתמונת מצב](/learn/state-as-a-snapshot)** כדי לדעת מה הstate נראה "קבוע" ולא מדורגות בתוך רופאי המקומות.
</LearnMore>
-## Queueing a series of state updates {/*queueing-a-series-of-state-updates*/}
+## תור לסדרה של עדכוני state {/*תור-סדרה-של-עדכוני-state*/}
-This component is buggy: clicking "+3" increments the score only once.
+רכיב זה הוא באגי: לחיצה על "+3" מגדילה את הניקוד פעם אחת בלבד.
<Sandpack>
@@ -354,7 +354,7 @@ button { display: inline-block; margin: 10px; font-size: 20px; }
</Sandpack>
-[State as a Snapshot](/learn/state-as-a-snapshot) explains why this is happening. Setting state requests a new re-render, but does not change it in the already running code. So `score` continues to be `0` right after you call `setScore(score + 1)`.
+[State as a Snapshot](/learn/state-as-a-snapshot) מסביר מדוע זה קורה. הגדרת בקשת עיבוד מחדש חדש, אך לא משנה אותו בקוד פועל. אז 'ציון' ממשיך להיות '0' מיד אחרי שאתה קורא ל'setScore(score + 1)'.
```js
console.log(score); // 0
@@ -366,7 +366,7 @@ setScore(score + 1); // setScore(0 + 1);
console.log(score); // 0
```
-You can fix this by passing an *updater function* when setting state. Notice how replacing `setScore(score + 1)` with `setScore(s => s + 1)` fixes the "+3" button. This lets you queue multiple state updates.
+אתה יכול לתקן זאת על העברת *פונקציית עדכון* בעת הגדרת הstate. שימו לב כיצד החלפת `setScore(score + 1)` ב-`setScore(s => s + 1)` מתקנת את כפתור "+3". זה יכול לך להכנס לפי עדכוני מצב מרובים.
<Sandpack>
@@ -402,15 +402,15 @@ button { display: inline-block; margin: 10px; font-size: 20px; }
<LearnMore path="/learn/queueing-a-series-of-state-updates">
-Read **[Queueing a Series of State Updates](/learn/queueing-a-series-of-state-updates)** to learn how to queue a sequence of state updates.
+קרא את **[לעמוד בתור סדרה של עדכוני state](/learn/queueing-a-series-of-state-updates)** כדי ללמוד כיצד להעמיד את הרצף של עדכוני state בתור.
</LearnMore>
-## Updating objects in state {/*updating-objects-in-state*/}
+## עדכון אובייקטים בstate {/*עדכון-אובייקטים-בstate*/}
-State can hold any kind of JavaScript value, including objects. But you shouldn't change objects and arrays that you hold in the React state directly. Instead, when you want to update an object and array, you need to create a new one (or make a copy of an existing one), and then update the state to use that copy.
+מצב יכול לבנות כל סוג של ערך JavaScript, כולל אובייקטים. אבל אתה לא צריך לשנות אובייקטים ומערכים שאתה מחזיק בstate. במקום זאת, כאשר נך לעדכן אובייקט ומערך, עליך ליצור רצועת חדש (או ליצור עו של קיים), היכן לעדכן את הstate כדי להשתמש בעותק זה.
-Usually, you will use the `...` spread syntax to copy objects and arrays that you want to change. For example, updating a nested object could look like this:
+בדרך כלל, תשתמש בתחביר התפשטות `...` כדי להעתיק אובייקטים ומערכים שברצונך לשנות. לדוגמה, עדכון אובייקט מקונן יכול להיראות כך:
<Sandpack>
@@ -518,7 +518,7 @@ img { width: 200px; height: 200px; }
</Sandpack>
-If copying objects in code gets tedious, you can use a library like [Immer](https://github.com/immerjs/use-immer) to reduce repetitive code:
+אם העתקת להשתמש בספרים בקוד הופכת מייגעת, אתה יכול להשתמש בשימוש כמו [Immer](https://github.com/immerjs/use-immer) כדי להקטין קוד שחוזר על עצמו:
<Sandpack>
@@ -633,13 +633,13 @@ img { width: 200px; height: 200px; }
<LearnMore path="/learn/updating-objects-in-state">
-Read **[Updating Objects in State](/learn/updating-objects-in-state)** to learn how to update objects correctly.
+קרא את **[עדכון אובייקטים בstate](/learn/updating-objects-in-state)** כדי ללמוד כיצד לעדכן אובייקטים בצורה נכונה.
</LearnMore>
-## Updating arrays in state {/*updating-arrays-in-state*/}
+## עדכון מערכים בstate {/*עדכון-מערכים-בstate*/}
-Arrays are another type of mutable JavaScript objects you can store in state and should treat as read-only. Just like with objects, when you want to update an array stored in state, you need to create a new one (or make a copy of an existing one), and then set state to use the new array:
+מערכים הם סוג נוסף של אובייקטי JavaScript הניתנים לשינוי שאתה יכול לאחסן בstate וצריך להתייחס אליהם כאל קריאה בלבד. בדיוק כמו עם אובייקטים, כאשר אתה רוצה לעדכן מערך מאוחסן בstate, אתה צריך ליצור מערך חדש (או ליצור עותק של קיים), הוא להגדיר את הstate לשימוש במערך החדש:
<Sandpack>
@@ -705,7 +705,7 @@ function ItemList({ artworks, onToggle }) {
</Sandpack>
-If copying arrays in code gets tedious, you can use a library like [Immer](https://github.com/immerjs/use-immer) to reduce repetitive code:
+אם העתקת מערכים בקוד הופכת מייגעת, אתה יכול להשתמש בספרייה כמו [Immer](https://github.com/immerjs/use-immer) כדי להקטין קוד שחוזר על עצמו:
<Sandpack>
@@ -789,12 +789,13 @@ function ItemList({ artworks, onToggle }) {
<LearnMore path="/learn/updating-arrays-in-state">
-Read **[Updating Arrays in State](/learn/updating-arrays-in-state)** to learn how to update arrays correctly.
+קרא את **[עדכון מערכים בstate](/learn/updating-arrays-in-state)** כדי ללמוד כיצד לעדכן מערכים בצורה נכונה.
</LearnMore>
-## What's next? {/*whats-next*/}
+## מה הלאה? {/*מה-הבא*/}
-Head over to [Responding to Events](/learn/responding-to-events) to start reading this chapter page by page!
+עברו אל [מגיבים לאירועים](/learn/responding-to-events) כדי להתחיל לקרוא פרק זה עמוד אחר עמוד!
+
+לחלופין, אם אתה כבר מכיר את הנושאים האלה, למה שלא תקרא על [Managing State](/learn/managing-state)?
-Or, if you're already familiar with these topics, why not read about [Managing State](/learn/managing-state)?
diff --git a/src/content/learn/describing-the-ui.md b/src/content/learn/describing-the-ui.md
index ce49b85c8..692562e64 100644
--- a/src/content/learn/describing-the-ui.md
+++ b/src/content/learn/describing-the-ui.md
@@ -1,30 +1,30 @@
---
-title: Describing the UI
+title: "תיאור ה-UI"
---
<Intro>
-React is a JavaScript library for rendering user interfaces (UI). UI is built from small units like buttons, text, and images. React lets you combine them into reusable, nestable *components.* From web sites to phone apps, everything on the screen can be broken down into components. In this chapter, you'll learn to create, customize, and conditionally display React components.
+React היא ספריית JavaScript לעיבוד ממשקי משתמש (UI). ממשק משתמש בנוי מיחידות קטנות כמו לחצנים, טקסט ותמונות. תגובה מאפשרת לך לשלב אותם לכדי *רכיבים ניתנים חוזרים, ניתנים לקינון.* מאטרי אינטרנט ועד אפליקציות טלפון, ניתן לפרק כל דבר על המסך לרכיבים. תגיב.
</Intro>
<YouWillLearn isChapter={true}>
-* [How to write your first React component](/learn/your-first-component)
-* [When and how to create multi-component files](/learn/importing-and-exporting-components)
-* [How to add markup to JavaScript with JSX](/learn/writing-markup-with-jsx)
-* [How to use curly braces with JSX to access JavaScript functionality from your components](/learn/javascript-in-jsx-with-curly-braces)
-* [How to configure components with props](/learn/passing-props-to-a-component)
-* [How to conditionally render components](/learn/conditional-rendering)
-* [How to render multiple components at a time](/learn/rendering-lists)
-* [How to avoid confusing bugs by keeping components pure](/learn/keeping-components-pure)
-* [Why understanding your UI as trees is useful](/learn/understanding-your-ui-as-a-tree)
+* [כיצד לכתוב את רכיב ה-React הראשון שלך](/learn/your-first-component)
+* [מתי וכיצד ליצור קבצים מרובי רכיבים](/learn/importing-and-exporting-components)
+* [כיצד להוסיף סימון ל-JavaScript עם JSX](/learn/writing-markup-with-jsx)
+* [להשתמש בסוגרים מסולסלים עם JSX כדי לגשת לפונקציונליות JavaScript מהרכיבים שלך](/learn/javascript-in-jsx-with-curly-braces)
+* [כיצד להגדיר רכיבים עם props](/learn/passing-props-to-a-component)
+* [כיצד לעבד רכיבים באופן מותנה](/learn/conditional-rendering)
+* [כיצד לעבד מספר רכיבים בו-זמנית](/learn/rendering-lists)
+* [כיצד מבלבול באגים על ידי שמירה על רכיבים טהורים](/learn/keeping-components-pure)
+* [מדוע הבנת ממשק המשתמש שלך כעצים היא שימושית](/learn/understanding-your-ui-as-a-tree)
</YouWillLearn>
-## Your first component {/*your-first-component*/}
+## הרכיב הראשון שלך {/*הרכיב-הראשון-שלך*/}
-React applications are built from isolated pieces of UI called *components*. A React component is a JavaScript function that you can sprinkle with markup. Components can be as small as a button, or as large as an entire page. Here is a `Gallery` component rendering three `Profile` components:
+יישומי React בנויים מחלקים מבודדים של ממשק משתמש הנקראים *רכיבים*. רכיב React הוא פונקציית JavaScript אתה יכול לפזר עם סימון. רכיבים יכולים להיות קטנים כמו כפתור, או גדולים כמו עמוד שלם. הנה רכיב 'גלריה' המציג שלושה רכיבי 'פרופיל':
<Sandpack>
@@ -58,13 +58,13 @@ img { margin: 0 10px 10px 0; height: 90px; }
<LearnMore path="/learn/your-first-component">
-Read **[Your First Component](/learn/your-first-component)** to learn how to declare and use React components.
+קרא את **[הרכיב הראשון](/learn/your-first-component)** כדי ללמוד כיצד להשתמש ברכיבי React.
</LearnMore>
-## Importing and exporting components {/*importing-and-exporting-components*/}
+## ייבוא וייצוא רכיבים {/*ייבוא-וייצוא-רכיבים*/}
-You can declare many components in one file, but large files can get difficult to navigate. To solve this, you can *export* a component into its own file, and then *import* that component from another file:
+אתה יכול להצהיר על רכיבים רבים בקובץ אחד, אבל קבצים גדולים יכולים להיות קשים לניווט. כדי לפתור זאת, אתה יכול *לייצא* רכיב לקובץ משלו, ולאחר מכן *לייבא* את הרכיב הזה מקובץ אחר:
<Sandpack>
@@ -113,15 +113,15 @@ img { margin: 0 10px 10px 0; }
<LearnMore path="/learn/importing-and-exporting-components">
-Read **[Importing and Exporting Components](/learn/importing-and-exporting-components)** to learn how to split components into their own files.
+קרא את **[ייבוא וייצוא רכיבים](/learn/importing-and-exporting-components)** כדי ללמוד כיצד לפצל רכיבים לקבצים משלהם.
</LearnMore>
-## Writing markup with JSX {/*writing-markup-with-jsx*/}
+## כתיבת סימון עם JSX {/*writing-markup-with-jsx*/}
-Each React component is a JavaScript function that may contain some markup that React renders into the browser. React components use a syntax extension called JSX to represent that markup. JSX looks a lot like HTML, but it is a bit stricter and can display dynamic information.
+כל הרכיב React הוא פונקציית JavaScript שעשויה להכיל סימון ש-React מעבד לדפדפן. רכיבי הגיבו משתמשים בסיומת תחביר הנקראת JSX כדי להציג את הסימון הזה. JSX נראה הרבה כמו HTML, אבל הוא קצת יותר מחמיר ויכול להציע מידע דינמי.
-If we paste existing HTML markup into a React component, it won't always work:
+אם נדביק סימון HTML קיים ברכיב React, זה לא תמיד יעבוד:
<Sandpack>
@@ -150,7 +150,7 @@ img { height: 90px; }
</Sandpack>
-If you have existing HTML like this, you can fix it using a [converter](https://transform.tools/html-to-jsx):
+אם יש לך HTML קיים כזה, אתה יכול לתקן אותו באמצעות [ממיר](https://transform.tools/html-to-jsx):
<Sandpack>
@@ -182,13 +182,13 @@ img { height: 90px; }
<LearnMore path="/learn/writing-markup-with-jsx">
-Read **[Writing Markup with JSX](/learn/writing-markup-with-jsx)** to learn how to write valid JSX.
+קרא את **[כתיבת סימון עם JSX](/learn/writing-markup-with-jsx)** כדי ללמוד כיצד לכתוב JSX חוקי.
</LearnMore>
-## JavaScript in JSX with curly braces {/*javascript-in-jsx-with-curly-braces*/}
+## JavaScript ב-JSX עם פלטה מתולתת {/*javascript-in-jsx-with-curly-braces*/}
-JSX lets you write HTML-like markup inside a JavaScript file, keeping rendering logic and content in the same place. Sometimes you will want to add a little JavaScript logic or reference a dynamic property inside that markup. In this situation, you can use curly braces in your JSX to "open a window" to JavaScript:
+JSX מאפשר לך לכתוב סימון דמוי HTML בתוך קובץ JavaScript, תוך שמירה על רינדור ההיגיון והתוכן באותו מקום. לפעמים תרצה להוסיף קצת הגיון JavaScript או להתייחס למאפיין דינמי בתוך הסימון הזה. בstate זה, אתה יכול להשתמש בסוגרים מסולסלים ב-JSX שלך כדי "לפתוח חלון" ל-JavaScript:
<Sandpack>
@@ -230,13 +230,13 @@ body > div > div { padding: 20px; }
<LearnMore path="/learn/javascript-in-jsx-with-curly-braces">
-Read **[JavaScript in JSX with Curly Braces](/learn/javascript-in-jsx-with-curly-braces)** to learn how to access JavaScript data from JSX.
+קרא את **[JavaScript ב-JSX עם פלטה מתולתת](/learn/javascript-in-jsx-with-curly-braces)** כדי ללמוד כיצד לגשת לנתוני JavaScript מ-JSX.
</LearnMore>
-## Passing props to a component {/*passing-props-to-a-component*/}
+## העברת props לרכיב {/*העברת-props-לרכיב*/}
-React components use *props* to communicate with each other. Every parent component can pass some information to its child components by giving them props. Props might remind you of HTML attributes, but you can pass any JavaScript value through them, including objects, arrays, functions, and even JSX!
+רכיבי React users ב-*props* כדי לתקשר עם זה. כל רכיב הורה יכול להעביר מידע מסוים לרכיבי על ידי מתן props. props יכולים להכיל תכונות HTML, אבל להעביר דרכם כל ערך JavaScript, כולל אובייקטים, מערכים, פונקציות אפילו JSX!
<Sandpack>
@@ -311,15 +311,15 @@ export function getImageUrl(person, size = 's') {
<LearnMore path="/learn/passing-props-to-a-component">
-Read **[Passing Props to a Component](/learn/passing-props-to-a-component)** to learn how to pass and read props.
+קרא את **[העברת props לרכיב](/learn/passing-props-to-a-component)** כדי ללמוד כיצד להעביר ולקרוא props.
</LearnMore>
-## Conditional rendering {/*conditional-rendering*/}
+## עיבוד מותנה {/*עיבוד-מותנה*/}
-Your components will often need to display different things depending on different conditions. In React, you can conditionally render JSX using JavaScript syntax like `if` statements, `&&`, and `? :` operators.
+הרכיבים שלך יצטרכו מסופקים שונים. ב-React, אתה יכול לבצע עיבוד מותנה של JSX באמצעות תחביר JavaScript כמו הצהרות `if`, `&&` ו`? :` מפעילים.
-In this example, the JavaScript `&&` operator is used to conditionally render a checkmark:
+בדוגמה זו, האופרטור '&&' של JavaScript שימוש לעיבוד מותנה של סימן ביקורת:
<Sandpack>
@@ -359,15 +359,15 @@ export default function PackingList() {
<LearnMore path="/learn/conditional-rendering">
-Read **[Conditional Rendering](/learn/conditional-rendering)** to learn the different ways to render content conditionally.
+קרא את **[עיבוד מותנה](/learn/conditional-rendering)** כדי ללמוד את הדרכים השונות לעיבוד תוכן מותנה.
</LearnMore>
-## Rendering lists {/*rendering-lists*/}
+## רשימות עיבוד {/*רשימות-עיבוד*/}
-You will often want to display multiple similar components from a collection of data. You can use JavaScript's `filter()` and `map()` with React to filter and transform your array of data into an array of components.
+קרוב תרצה להציג מספר רכיבים דומים מאוסף נתונים. אתה יכול להשתמש ב-'filter()' ו-'map()' של JavaScript עם React כדי לסנן ולהפוך את המערך שלך לרכיבים.
-For each array item, you will need to specify a `key`. Usually, you will want to use an ID from the database as a `key`. Keys let React keep track of each item's place in the list even if the list changes.
+עבור כל פריט מערך, תפרט 'מפתח'. בדרך כלל, תרצה להשתמש במזהה ממסד עבור `מפתח`. מקשים מסוגלים ל-React לעקוב אחר מקומו של כל פריט ברשימה גם אם הרשימה משתנה.
<Sandpack>
@@ -459,18 +459,18 @@ h2 { font-size: 20px; }
<LearnMore path="/learn/rendering-lists">
-Read **[Rendering Lists](/learn/rendering-lists)** to learn how to render a list of components, and how to choose a key.
+קרא את **[עיבוד רשימות](/learn/rendering-lists)** כדי ללמוד כיצד לעבד רשימה של רכיבים וכיצד לבחור מפתח.
</LearnMore>
-## Keeping components pure {/*keeping-components-pure*/}
+## שמירה על טהרת הרכיבים {/*שמירה-הרכיבים-טהורים*/}
-Some JavaScript functions are *pure.* A pure function:
+חלק מפונקציות JavaScript הן *טהורות.* פונקציה טהורה:
-* **Minds its own business.** It does not change any objects or variables that existed before it was called.
-* **Same inputs, same output.** Given the same inputs, a pure function should always return the same result.
+* ** דואג לעניינים שלו.** זה לא משנה אובייקטים או משתנים שהיו קיימים לפני שנקרא.
+* **אותן כניסות, אותו פלט.** בהינתן אותן כניסות, פונקציה טהורה צריכה תמיד להחזיר את אותה תוצאה.
-By strictly only writing your components as pure functions, you can avoid an entire class of baffling bugs and unpredictable behavior as your codebase grows. Here is an example of an impure component:
+על ידי כתיבת הרכיבים שלך כפונקציות טהורות בלבד, אתה יכול למנוע מחלקה שלמה של באגים מביכים והתנהגות בלתי צפויה ככל שבסיס הקוד שלך גדל. הנה דוגמה לרכיב לא טהור:
<Sandpack>
@@ -496,7 +496,7 @@ export default function TeaSet() {
</Sandpack>
-You can make this component pure by passing a prop instead of modifying a preexisting variable:
+אתה יכול להפוך את הרכיב הזה לטהור על ידי העברת props במקום שינוי משתנה קיים:
<Sandpack>
@@ -520,43 +520,44 @@ export default function TeaSet() {
<LearnMore path="/learn/keeping-components-pure">
-Read **[Keeping Components Pure](/learn/keeping-components-pure)** to learn how to write components as pure, predictable functions.
+קרא את **[Keeping Components Pure](/learn/keeping-components-pure)** כדי ללמוד כיצד לכתוב רכיבים כפונקציות טהורות וניתנות לחיזוי.
</LearnMore>
-## Your UI as a tree {/*your-ui-as-a-tree*/}
+## ממשק המשתמש שלך כעץ {/*הממשק-שלך-כעץ*/}
-React uses trees to model the relationships between components and modules.
+תגובה משתמש בצים כדי לדגמן את היחסים בין רכיבים ומודולים.
-A React render tree is a representation of the parent and child relationship between components.
+עץ רינדור React הוא ייצוג של יחסי ההורה והילד בין רכיבים.
<Diagram name="generic_render_tree" height={250} width={500} alt="A tree graph with five nodes, with each node representing a component. The root node is located at the top the tree graph and is labelled 'Root Component'. It has two arrows extending down to two nodes labelled 'Component A' and 'Component C'. Each of the arrows is labelled with 'renders'. 'Component A' has a single 'renders' arrow to a node labelled 'Component B'. 'Component C' has a single 'renders' arrow to a node labelled 'Component D'.">
-An example React render tree.
+עץ רינדור תגובה לדוגמה.
</Diagram>
-Components near the top of the tree, near the root component, are considered top-level components. Components with no child components are leaf components. This categorization of components is useful for understanding data flow and rendering performance.
+רכיבים ליד ראש העץ, ליד מרכיב השורש, נחשבים לרכיבים ברמה העליונה. רכיבים ללא רכיבי צאצא הם רכיבי עלים. סיווג זה של רכיבים שימושי להבנת זרימת הנתונים וביצועי העיבוד.
-Modelling the relationship between JavaScript modules is another useful way to understand your app. We refer to it as a module dependency tree.
+מודלים של הקשר בין מודולי JavaScript היא דרך שימושית נוספת להבין את האפליקציה שלך. אנו מתחרים אליו כאל עץ תלות מודול.
<Diagram name="generic_dependency_tree" height={250} width={500} alt="A tree graph with five nodes. Each node represents a JavaScript module. The top-most node is labelled 'RootModule.js'. It has three arrows extending to the nodes: 'ModuleA.js', 'ModuleB.js', and 'ModuleC.js'. Each arrow is labelled as 'imports'. 'ModuleC.js' node has a single 'imports' arrow that points to a node labelled 'ModuleD.js'.">
-An example module dependency tree.
+עץ תלות מודול לדוגמה.
</Diagram>
-A dependency tree is often used by build tools to bundle all the relevant JavaScript code for the client to download and render. A large bundle size regresses user experience for React apps. Understanding the module dependency tree is helpful to debug such issues.
+עץ תל כלי משמש כדרך בנייה כדי לאגד את כל קוד ה-JavaScript הרלונטי עבור הלקוח להורדה ולעיבוד. גודל חבילה גדול מחזיר את חוויית המשתמש עבור אפליקציות React. הבנת עץ התלות של המודול מועיל לאיתור באגים מסוג זה.
<LearnMore path="/learn/understanding-your-ui-as-a-tree">
-Read **[Your UI as a Tree](/learn/understanding-your-ui-as-a-tree)** to learn how to create a render and module dependency trees for a React app and how they're useful mental models for improving user experience and performance.
+קרא את **[ממשק המשתמש שלך כעץ](/learn/understanding-your-ui-as-a-tree)** כדי ללמוד כיצד ליצור עיבוד ועצי תלות במודול עבור אפליקציית.
</LearnMore>
-## What's next? {/*whats-next*/}
+## מה הלאה? {/*מה-הבא*/}
-Head over to [Your First Component](/learn/your-first-component) to start reading this chapter page by page!
+עברו אל [הרכיב הראשון שלך](/learn/your-first-component) כדי להתחיל לקרוא את זה עמוד אחר עמוד!
+
+או, אם אתה כבר מכיר את הנושאים האלה, למה שלא תקרא על [הוספת אינטראקטיביות](/learn/adding-interactivity)?
-Or, if you're already familiar with these topics, why not read about [Adding Interactivity](/learn/adding-interactivity)?
diff --git a/src/content/learn/editor-setup.md b/src/content/learn/editor-setup.md
index 0a12fa5b4..7cb77d9c9 100644
--- a/src/content/learn/editor-setup.md
+++ b/src/content/learn/editor-setup.md
@@ -15,48 +15,48 @@ title: התקנת עורך קוד
</YouWillLearn>
-## העורך שלך {/*your-editor*/}
+## העורך שלך {/*העורך-שלך*/}
-אחד מעורכי הקוד הפופולריים ביותר (אם לא הכי) הוא [VS Code](https://code.visualstudio.com/). יש לו תוספים רבים שניתן להתקין והוא מתממשק טוב עם שירותים כמו גיטהאב. ניתן להוסיף את רוב הפיצ׳רים הכתובים כאן בהמשך ל-VS Code כתוספים.
+אחד מעורכי הקוד הפופולריים (אם לא הכי) הוא [קוד VS](https://code.visualstudio.com/). יש לו תוספים רבים להתקין והוא מתממשק טוב עם שירותים כמו גיטהאב. ניתן להוסיף את רוב הפיצ'רים הכתובים כאן בהמשך ל-VS Code כתוספים.
עורכי קוד נוספים שמשתמשים בהם בקהילת ריאקט כוללים:
* וובסטורם - [WebStorm](https://www.jetbrains.com/webstorm/) הוא סביבת פיתוח שעוצבה במיוחד לפיתוח בעזרת JavaScript.
-* סאבליים טקסט - [Sublime Text](https://www.sublimetext.com/) תומך ב-syntax highlighting של JSX ו-TypeScript.
-* וים - [Vim](https://www.vim.org/) הוא עורך קוד גמיש מאוד שנבנה על מנת לאפשר פיתוח מהיר. הוא כלול ברוב מערכות ההפעלה מבוססות Unix וב-MacOS.
+* סאבליים טקסט - [טקסט נשגב](https://www.sublimetext.com/) תומך ב-syntax highlighting של JSX ו-TypeScript.
+* וים - [Vim](https://www.vim.org/) הוא עורך קוד גמיש מאוד שנבנה על מנת לאפשר פיתוח מהיר. הוא כולל מערכות ההפעלה מבוססות Unix וב-MacOS.
-## פיצ׳רים מומלצים בעורכי קוד {/*recommended-text-editor-features*/}
+## פיצ'רים מומלצים בעורכי קוד {/*תכונות-עורך-טקסט-מומלץ*/}
-חלק מעורכי הקוד מגיעים עם פיצ׳רים אלה ישר מהקופסה, אבל אחרים דורשים את הוספתם באמצעות תוסף. בדוק מה מובנה בעורך הקוד שלך ליתר ביטחון.
+חלק מעורכי הקוד מגיעים עם היכולות האלה כבר מהקופסה, אבל אחרים דורשים להוסיף אותן דרך תוסף. מומלץ לבדוק מה כבר מובנה בעורך הקוד שלכם.
-### Linting {/*linting*/}
+### מוך {/*מוך*/}
-לינטרים מוצאים בעיות בקוד שלך בזמן שאתה כותב אותו, מה שמאפשר תיקון מוקדם. לינטר פופולרי ומומלץ הוא [ESLint](https://eslint.org/).
+לינטרים מוצאים בעיות בקוד שלך בזמן שאתה כותב אותו מוקדם, מה שמאפשר תיקון. לינטר פופולרי ומומלץ הוא [ESLint](https://eslint.org/).
* [התקן ESLint עם האופציות המומלצות לריאקט](https://www.npmjs.com/package/eslint-config-react-app) (וודא שיש לך [Node מותקן!](https://nodejs.org/en/download/current/))
-* [Integrate ESLint in VSCode with the official extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)
+* [שלבו את ESLint ב-VS Code עם התוסף הרשמי](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)
-**Make sure that you've enabled all the [`eslint-plugin-react-hooks`](https://www.npmjs.com/package/eslint-plugin-react-hooks) rules for your project.** They are essential and catch the most severe bugs early. The recommended [`eslint-config-react-app`](https://www.npmjs.com/package/eslint-config-react-app) preset already includes them.
+**ודאו הפעלתם את הכללים של [`eslint-plugin-react-hooks`](https://www.npmjs.com/package/eslint-plugin-react-hooks) בפרויקט שלכם.** הכללים האלה חיוניים ותופסים באגים חמורים קודם. המומלץ המוגדר מראש [`eslint-config-react-app`](https://www.npmjs.com/package/eslint-config-react-app) כבר כולל אותם.
-### Formatting {/*formatting*/}
+### עיצוב {/*עיצוב*/}
-הדרך האחרון שאתה רוצה כשאתה משתף קוד עם מפתח אחר הוא להיכנס לוויכוח [tabs vs spaces](https://www.google.com/search?q=tabs+vs+spaces). למזלנו, [prettier](https://prettier.io/)) ינקה את הקוד שלך על ידי התאמתו לחוקים קיימים. בעת הרצת prettier, כל ה-tabs יהפכו ל-spaces, וגרשיים כפולים או יחידים ישונו בהתאם לקונפיגורציה. בסביבת פיתוח אידיאלית, Prettier ירוץ בעת שמירת קובץ, ויעשה את כל השינויים הללו אוטומטית.
+הדבר האחרון שאתה רוצה שאתה מפתח עם אחר הוא להיכנס לוויכוח [tabs vs spaces](https://www.google.com/search?q=tabs+vs+spaces). למזלנו, [Prettier](https://prettier.io/) יסדר את הקוד אוטומטית לפי חוקים עקביים. בעת הרצת Prettier, טאבים יומרו לרווחים, וסגנון המירכאות יותאם לקונפיגורציה. בסביבת פיתוח אידיאלית, יפה יותר ירוץ בכל שמירה ויבצע את כל ההתאמות האלה אוטומטית.
ניתן להתקין את Prettier ב[VS Code](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) בעזרת הצעדים הבאים:
-1. פתח את VS Code
-2. הרץ את Quick Open (בעזרת Ctrl/Cmd+p)
+1. פתח את הקוד VS
+2. הרץ את פתיחה מהירה (בעזרת Ctrl/Cmd+p)
3. הדבק בפנים את `ext install esbenp.prettier-vscode`
-4. לחץ Enter
+4. לחץ על Enter
-#### Formatting on save {/*formatting-on-save*/}
+#### עיצוב בשמירה {/*פורמט-ב-שמירה*/}
באופן אידיאלי, כדאי לאפשר לתוסף לסדר את הקוד בכל שמירת קובץ. מזל ש-VS Code מאפשר לנו את זה!
-1. ב-VS Code, לחץ `CTRL/CMD + SHIFT + P`.
-2. כתוב "settings"
-3. לחץ Enter
-4. בשורת החיפוש, כתוב "format on save"
-5. וודא כי האופצייה "format on save" מסומנת
+1. ב-VS Code, לחץ על `CTRL/CMD + SHIFT + P`.
+2. כתוב "הגדרות"
+3. לחץ על Enter
+4. בשורת החיפוש, כתוב "פורמט בשמירה"
+5. וודא כי האופצייה "פורמט בשמירה" מסומנת
-> אם קונפיג הESLint שלך מכיל חוקים שקשורים לסידור קוד, הם עלולים להתנגש עם Prettier. אנחנו ממליצים לכבות את חוקים אלו בקונפיג הESLint שלך באמצעות [`eslint-config-prettier`](https://github.com/prettier/eslint-config-prettier), ככה שESLint עובד רק על מנת לתפוס שגיאות לוגיות. אם אתה רוצה להחיל סידור קוד לפני מירג׳וג׳ PR, השתמש ב-[`prettier --check`](https://prettier.io/docs/en/cli.html#--check) ב-CI שלך.
+> אם קונפיגורצית ESLint כולל כללים לעיצוב קוד, היא עלולה להתנגש עם Prettier. אנחנו ממליצים לכבות את הכללים האלה באמצעות [`eslint-config-prettier`](https://github.com/prettier/eslint-config-prettier), כך ש-ESLint יפעל בזיהוי שגיאות לוגיות. אם אתם רוצים לאכוף עיצוב קוד לפני מיזוג Pull Request, השתמשו ב-[`prettier --check`](https://prettier.io/docs/en/cli.html#--check) בתוך CI.
diff --git a/src/content/learn/escape-hatches.md b/src/content/learn/escape-hatches.md
index 23f11f54e..dd0312727 100644
--- a/src/content/learn/escape-hatches.md
+++ b/src/content/learn/escape-hatches.md
@@ -1,35 +1,35 @@
---
-title: Escape Hatches
+title: דרכי מילוט
---
<Intro>
-Some of your components may need to control and synchronize with systems outside of React. For example, you might need to focus an input using the browser API, play and pause a video player implemented without React, or connect and listen to messages from a remote server. In this chapter, you'll learn the escape hatches that let you "step outside" React and connect to external systems. Most of your application logic and data flow should not rely on these features.
+יכול שחלק מהרכיבים שלך יצטרכו לשלוט ולסנכרן עם מערכות מחוץ ל-React. לדוגמא, אפשר ללא צורך למקד קלט באמצעות ה-API של הדפן, להפעיל ולהשהות נגן וידאו מיושם React, או להתחבר ולהאזין להודעות משרת מרוחק. בפרק זה תלמדו את פתחי המילוט המאפשרים לכם "לצאת החוצה" להגיב ולהתחבר למערכות חיצוניות. רוב ההיגיון של היישום והזרימה שלך לא צריך להסתמך על תכונות אלה.
</Intro>
<YouWillLearn isChapter={true}>
-* [How to "remember" information without re-rendering](/learn/referencing-values-with-refs)
-* [How to access DOM elements managed by React](/learn/manipulating-the-dom-with-refs)
-* [How to synchronize components with external systems](/learn/synchronizing-with-effects)
-* [How to remove unnecessary Effects from your components](/learn/you-might-not-need-an-effect)
-* [How an Effect's lifecycle is different from a component's](/learn/lifecycle-of-reactive-effects)
-* [How to prevent some values from re-triggering Effects](/learn/separating-events-from-effects)
-* [How to make your Effect re-run less often](/learn/removing-effect-dependencies)
-* [How to share logic between components](/learn/reusing-logic-with-custom-hooks)
+* [כיצד "לזכור" מידע ללא עיבוד מחדש](/learn/referencing-values-with-refs)
+* [כיצד לגשת לרכיבי DOM המנוהל על ידי React](/learn/manipulating-the-dom-with-refs)
+* [כיצד לסנכרן רכיבים עם מערכות חיצוניות](/למד/סנכרון-עם-אפקטים)
+* [כיצד להוציא אפקטים מיותרים מהרכיבים שלך](/learn/you-might-not-need-an-effect)
+* [איך מחזור החיים של אפקט שונה ממחזור החיים של הרכיב](/learn/lifecycle-of-reactive-effects)
+* [כיצד למנוע מכמה ערכים להפעיל מחדש אפקטים](/learn/separating-events-from-effects)
+* [כיצד לגרום לאפקט שלך להופיע מחדש בתדירות נמוכה יותר](/learn/removing-effect-dependencies)
+* [כיצד שיתוף לוגיקה בין רכיבים](/learn/reusing-logic-with-custom-hooks)
</YouWillLearn>
-## Referencing values with refs {/*referencing-values-with-refs*/}
+## הפניה לערכים עם refs {/*referencing-values-with-refs*/}
-When you want a component to "remember" some information, but you don't want that information to [trigger new renders](/learn/render-and-commit), you can use a *ref*:
+כאשר אתה רוצה רכיב "יזכור" מידע מסוים, אבל אתה לא רוצה שהמידע הזה [תפעיל עיבודים חדשים](/learn/render-and-commit), אתה יכול להשתמש ב-*ref*:
```js
const ref = useRef(0);
```
-Like state, refs are retained by React between re-renders. However, setting state re-renders a component. Changing a ref does not! You can access the current value of that ref through the `ref.current` property.
+בדומה לstate, השופטים נשמרים על ידי תגובה בין עיבודים חוזרים. עם זאת, הגדרת מצב מעבד מחדש רכיב. החלפת שופט לא! אתה יכול לגשת לערך הנוכחי של אותו ref דרך המאפיין 'ref.current'.
<Sandpack>
@@ -54,17 +54,17 @@ export default function Counter() {
</Sandpack>
-A ref is like a secret pocket of your component that React doesn't track. For example, you can use refs to store [timeout IDs](https://developer.mozilla.org/en-US/docs/Web/API/setTimeout#return_value), [DOM elements](https://developer.mozilla.org/en-US/docs/Web/API/Element), and other objects that don't impact the component's rendering output.
+שופט הוא כמו כיס סודי של הרכיב שלך ש-React לא עוקב אחריו. לדוגמה, אתה יכול להשתמש ב-refs כדי לאחסן [מזהי זמן קצוב](https://developer.mozilla.org/en-US/docs/Web/API/setTimeout#return_value), [רכיבי DOM](https://developer.mozilla.org/en-US/docs רכיב/Web/API/Element משפיעים), ואובייקטים אחרים עיבוד
<LearnMore path="/learn/referencing-values-with-refs">
-Read **[Referencing Values with Refs](/learn/referencing-values-with-refs)** to learn how to use refs to remember information.
+קרא את **[התייחסות לערכים עם Refs](/learn/referencing-values-with-refs)** כדי ללמוד להשתמש ב-Refs כדי לזכור מידע.
</LearnMore>
-## Manipulating the DOM with refs {/*manipulating-the-dom-with-refs*/}
+## מניפולציה של ה-DOM עם שו"פים {/*מניפולציה-של-הדום-עם-שופים*/}
-React automatically updates the DOM to match your render output, so your components won't often need to manipulate it. However, sometimes you might need access to the DOM elements managed by React—for example, to focus a node, scroll to it, or measure its size and position. There is no built-in way to do those things in React, so you will need a ref to the DOM node. For example, clicking the button will focus the input using a ref:
+תגיב מותאם אוטומטית את העיבוד, כך שהרכיבים שלך לא יצטרכו בטווח זמן לתפעל אותו. עם זאת, לפעמים אפשר שתזדקק לגישה לרכיבי ה-DOM המנוהל על ידי React - לדוגמה, כדי למקד צומת, לגלול אליו או למדוד את גודלו ומיקומו. אין דרך מובנית לעשות את הדברים האלה ב-React, אז תצטרך ref לצומת DOM. לדוגמה, לחיצה על הכפתור תעסוק בקלט באמצעות ref:
<Sandpack>
@@ -93,15 +93,15 @@ export default function Form() {
<LearnMore path="/learn/manipulating-the-dom-with-refs">
-Read **[Manipulating the DOM with Refs](/learn/manipulating-the-dom-with-refs)** to learn how to access DOM elements managed by React.
+קרא את **[מניפולציה של ה-DOM עם Refs](/learn/manipulating-the-dom-with-refs)** כדי ללמוד כיצד לגשת לרכיבי DOM המנוהל על ידי React.
</LearnMore>
-## Synchronizing with Effects {/*synchronizing-with-effects*/}
+## סנכרון עם אפקטים {/*סנכרון-עם-אפקטים*/}
-Some components need to synchronize with external systems. For example, you might want to control a non-React component based on the React state, set up a server connection, or send an analytics log when a component appears on the screen. Unlike event handlers, which let you handle particular events, *Effects* let you run some code after rendering. Use them to synchronize your component with a system outside of React.
+חלק מהרכיבים צריכים להסתנכרן עם מערכות חיצוניות. לדוגמה, ייתכן שתרצה לשלוט ברכיב שאינו React בהתבסס על מצב React, להגדיר חיבור לשרת, או לשלוח יומן ניתוח כאשר רכיב מופיע על המסך. מטפל באירועים, המאפשרים לך להריץ באירועים, *אפקטים* מאפשרים לך להריץ קוד מסוים לאחר העיבוד. השתמש בהם כדי לסנכרן את הרכיב שלך עם מערכת מחוץ ל-React.
-Press Play/Pause a few times and see how the video player stays synchronized to the `isPlaying` prop value:
+הקש על הפעל/השהה כמה פעמים וראה כיצד נגן הווידאו נשאר מסונכרן לערך ה-'isPlaying':
<Sandpack>
@@ -145,7 +145,7 @@ video { width: 250px; }
</Sandpack>
-Many Effects also "clean up" after themselves. For example, an Effect that sets up a connection to a chat server should return a *cleanup function* that tells React how to disconnect your component from that server:
+אפקטים רבים גם "מנקים" אחרי אנשים. לדוגמה, אפקט שמגדיר חיבור לשרת צ'אט צריך להחזיר *פונקציית ניקוי* שאומרת ל-React כיצד לנתק את הרכיב שלך מהשרת הזה:
<Sandpack>
@@ -183,23 +183,23 @@ input { display: block; margin-bottom: 20px; }
</Sandpack>
-In development, React will immediately run and clean up your Effect one extra time. This is why you see `"✅ Connecting..."` printed twice. This ensures that you don't forget to implement the cleanup function.
+בפיתוח, React יפעיל מיד ותנקה את האפקט שלך פעם נוספת. אתה רואה את `"✅ מתחבר..."` מודפס פעמיים. זה מבטיח שלא תשכח ליישם את פונקציית הניקוי.
<LearnMore path="/learn/synchronizing-with-effects">
-Read **[Synchronizing with Effects](/learn/synchronizing-with-effects)** to learn how to synchronize components with external systems.
+קרא את **[סנכרון עם אפקטים](/learn/synchronizing-with-effects)** כדי ללמוד כיצד לסנכרן רכיבים עם מערכות חיצוניות.
</LearnMore>
-## You Might Not Need An Effect {/*you-might-not-need-an-effect*/}
+## אולי לא תזדקק לאפקט {/*ייתכן-לא-תצטרך-אפקט*/}
-Effects are an escape hatch from the React paradigm. They let you "step outside" of React and synchronize your components with some external system. If there is no external system involved (for example, if you want to update a component's state when some props or state change), you shouldn't need an Effect. Removing unnecessary Effects will make your code easier to follow, faster to run, and less error-prone.
+אפקטים הם פתח מילוט מפרדיגמת React. הם מאפשרים לך "לצאת החוצה" מ-React ולסנכרן את הרכיבים שלך עם מערכת חיצונית. אם אין מערכת חיצונית מעורבת (לדוגמה, אם רוצה לעדכן מצב של רכיב כאשר אתה props או מצב משתנים), אתה לא אמור להזדק לאפקט. הסרת אפקטים מיותרים תהפוך את הקוד שלך לקל יותר לעקוב, מהר יותר להפעלה ונוטה פחות לשגיאות.
-There are two common cases in which you don't need Effects:
-- **You don't need Effects to transform data for rendering.**
-- **You don't need Effects to handle user events.**
+ישנם שני מקרים נפוצים שבהם אתה לא צריך אפקטים:
+- **לא צריך אפקטים כדי להפוך נתונים לעיבוד.**
+- **לא צריך אפקטים כדי לטפל באירועי משתמש.**
-For example, you don't need an Effect to adjust some state based on other state:
+לדוגמה, אתה לא צריך אפקט כדי להתאים מצב מסוים על סמך מצב אחר:
```js {5-9}
function Form() {
@@ -215,7 +215,7 @@ function Form() {
}
```
-Instead, calculate as much as you can while rendering:
+במקום זאת, חשב כמה שאתה יכול תוך כדי רינדור:
```js {4-5}
function Form() {
@@ -227,19 +227,19 @@ function Form() {
}
```
-However, you *do* need Effects to synchronize with external systems.
+עם זאת, אתה *דווקא* צריך אפקטים כדי לסנכרן עם מערכות חיצוניות.
<LearnMore path="/learn/you-might-not-need-an-effect">
-Read **[You Might Not Need an Effect](/learn/you-might-not-need-an-effect)** to learn how to remove unnecessary Effects.
+קרא את **[ייתכן שלא תזדק לאפקט](/learn/you-might-not-need-an-effect)** כדי לממש אפקטים מיותרים.
</LearnMore>
-## Lifecycle of reactive effects {/*lifecycle-of-reactive-effects*/}
+## מחזור חיים של אפקטים תגובתיים {/*מחזור-חיים-של-אפקטים-תגובתיים*/}
-Effects have a different lifecycle from components. Components may mount, update, or unmount. An Effect can only do two things: to start synchronizing something, and later to stop synchronizing it. This cycle can happen multiple times if your Effect depends on props and state that change over time.
+לאפקטים יש מחזור חיים שונה ממרכיבים. רכיבים עשויים לעלות, לעדכן או לבטל את הטעינה. אפקט יכול לעשות רק שני דברים: להתחיל לסנכרן משהו, ובהמשך להפסיק לסנכרן אותו. מחזור זה יכול לקרות מספר פעמים אם ההשפעה שלך תלויה בprops ובstates המשתנים עם הזמן.
-This Effect depends on the value of the `roomId` prop. Props are *reactive values,* which means they can change on a re-render. Notice that the Effect *re-synchronizes* (and re-connects to the server) if `roomId` changes:
+אפקט זה תלוי בערך של הפרופס של `roomId`. props הם * ערכים תגובתיים,* מה שאומר שהם יכולים להשתנות בעיבוד מחדש. שימו לב שהאפקט *מסנכרן מחדש* (ומתחבר מחדש לשרת) אם `roomId` ranking:
<Sandpack>
@@ -302,25 +302,25 @@ button { margin-left: 10px; }
</Sandpack>
-React provides a linter rule to check that you've specified your Effect's dependencies correctly. If you forget to specify `roomId` in the list of dependencies in the above example, the linter will find that bug automatically.
+React מספק כלל linter כדי לבדוק את התלות של האפקט שלך בצורה נכונה. אם תשכח לציין 'roomId' ברשימת התלות בדוגמה לעיל, ה-linter יביא את הבאג הזה באופן אוטומטי.
<LearnMore path="/learn/lifecycle-of-reactive-effects">
-Read **[Lifecycle of Reactive Events](/learn/lifecycle-of-reactive-effects)** to learn how an Effect's lifecycle is different from a component's.
+קרא את **[מחזור חיים של אירועים תגובתיים](/learn/lifecycle-of-reactive-effects)** כדי ללמוד מחזור החיים של אפקט שונה מזה של רכיב.
</LearnMore>
-## Separating events from Effects {/*separating-events-from-effects*/}
+## הפרדת אירועים מהאפקטים {/*הפרדת-אירועים-מהאפקטים*/}
<Wip>
-This section describes an **experimental API that has not yet been released** in a stable version of React.
+סעיף זה מתאר **API ניסיוני שעדיין לא שוחרר** בגרסה יציבה של React.
</Wip>
-Event handlers only re-run when you perform the same interaction again. Unlike event handlers, Effects re-synchronize if any of the values they read, like props or state, are different than during last render. Sometimes, you want a mix of both behaviors: an Effect that re-runs in response to some values but not others.
+מטפלי אירועים פועלים מחדש רק כאשר אתה מבצע שוב את אותה אינטראקציה. שלא כמו מטפלי אירועים, אפקטים מסתנכרנים מחדש אם אחד מהערכים שהם קוראים, כמו props או מצב, שונה מאשר במהלך העיבוד האחרון. לפעמים, אתה רוצה שילוב של שתי ההתנהגויות: אפקט המופעל מחדש בתגובה לערכים מסוימים אך לא לאחרים.
-All code inside Effects is *reactive.* It will run again if some reactive value it reads has changed due to a re-render. For example, this Effect will re-connect to the chat if either `roomId` or `theme` have changed:
+כל הקוד בתוך אפקטים הוא *reactive.* הוא יפעל שוב אם הוא קורא השתנה עקב עיבוד מחדש. לדוגמה, אפקט זה יתחבר מחדש לצ'אט אם 'roomId' או 'theme' השתנו:
<Sandpack>
@@ -448,7 +448,7 @@ label { display: block; margin-top: 10px; }
</Sandpack>
-This is not ideal. You want to re-connect to the chat only if the `roomId` has changed. Switching the `theme` shouldn't re-connect to the chat! Move the code reading `theme` out of your Effect into an *Effect Event*:
+זה לא אידיאלי. אתה רוצה להתחבר מחדש לצ'אט רק אם ה-'roomId' השתנה. החלפת `נושא` לא אמורה להתחבר מחדש לצ'אט! העבר את הקוד שקורא את ה-'theme' מהאפקט שלך ל-*Effect Event*:
<Sandpack>
@@ -581,19 +581,19 @@ label { display: block; margin-top: 10px; }
</Sandpack>
-Code inside Effect Events isn't reactive, so changing the `theme` no longer makes your Effect re-connect.
+הקוד בתוך אירועי אפקט אינו תגובתי, כך ששינוי `הנושא` כבר לא גורם לאפקט להתחבר מחדש.
<LearnMore path="/learn/separating-events-from-effects">
-Read **[Separating Events from Effects](/learn/separating-events-from-effects)** to learn how to prevent some values from re-triggering Effects.
+קרא את **[הפרדת אירועים מאפקטים](/learn/separating-events-from-effects)** כדי ללמוד כיצד למנוע מכמה ערכים להפעיל מחדש אפקטים.
</LearnMore>
-## Removing Effect dependencies {/*removing-effect-dependencies*/}
+## הסרת תלויות אפקט {/*הסרת-אפקט-תלות*/}
-When you write an Effect, the linter will verify that you've included every reactive value (like props and state) that the Effect reads in the list of your Effect's dependencies. This ensures that your Effect remains synchronized with the latest props and state of your component. Unnecessary dependencies may cause your Effect to run too often, or even create an infinite loop. The way you remove them depends on the case.
+כאשר אתה כותב אפקט, ה-linter יוודא שכללת כל ערך תגובתי (כמו props וstate) שהאפקט קורא ברשימת התלות של האפקט שלך. זה מבטיח שהאפקט שלך יישאר מסונכרן עם הprops וstate העדכניים ביותר של הרכיב שלך. תלות מיותרות עלולה לגרום לאפקט שלך לפעול בזמן, או אפילו ליצור לולאה אינסופית. הדרך תלויה במקרה.
-For example, this Effect depends on the `options` object which gets re-created every time you edit the input:
+לדוגמה, אפקט זה תלוי באובייקט 'אפשרויות' שנוצר מחדש בכל פעם שאתה עורך את הקלט:
<Sandpack>
@@ -668,7 +668,7 @@ button { margin-left: 10px; }
</Sandpack>
-You don't want the chat to re-connect every time you start typing a message in that chat. To fix this problem, move creation of the `options` object inside the Effect so that the Effect only depends on the `roomId` string:
+אתה לא רוצה שהצ'אט יתחבר מחדש בכל פעם שאתה מתחיל להקליד הודעה בצ'אט זה. כדי לתקן זו בעיה, העבר את היצירה של אובייקט ה-'options' בתוך האפקט כך שהאפקט תלוי רק במחרוזת 'roomId':
<Sandpack>
@@ -742,19 +742,19 @@ button { margin-left: 10px; }
</Sandpack>
-Notice that you didn't start by editing the dependency list to remove the `options` dependency. That would be wrong. Instead, you changed the surrounding code so that the dependency became *unnecessary.* Think of the dependency list as a list of all the reactive values used by your Effect's code. You don't intentionally choose what to put on that list. The list describes your code. To change the dependency list, change the code.
+שים לב שלא התחלת בעריכת רשימת התלות כדי להסיר את התלות 'אפשרויות'. זה יהיה שגוי. במקום זאת, שינית את הקוד שמסביב כך שהתלות הפכה ל*מיותרת.* תחשוב על רשימת התלות כעל רשימה של כל הערכים התגובתיים המשמשים את הקוד של האפקט שלך. אתה לא בוחר בכוונה מה לשים ברשימה הזו. הרשימה מתארת את הקוד שלך. כדי לשנות את רשימת התלות, שנה את הקוד.
<LearnMore path="/learn/removing-effect-dependencies">
-Read **[Removing Effect Dependencies](/learn/removing-effect-dependencies)** to learn how to make your Effect re-run less often.
+קרא את **[הסרת תלות אפקט](/learn/removing-effect-dependencies)** כדי ללמוד כיצד לגרום לאפקט לפעול שוב בתדירות נמוכה יותר.
</LearnMore>
-## Reusing logic with custom Hooks {/*reusing-logic-with-custom-hooks*/}
+## שימוש חוזר בהיגיון עם ווים מותאמים אישית {/*שימוש-חוזר-בהיגיון-עם-ווים-מותאמים-אישית*/}
-React comes with built-in Hooks like `useState`, `useContext`, and `useEffect`. Sometimes, you’ll wish that there was a Hook for some more specific purpose: for example, to fetch data, to keep track of whether the user is online, or to connect to a chat room. To do this, you can create your own Hooks for your application's needs.
+תגובה מגיעה עם Hooks מובנים כמו `useState`, `useContext` ו-`useEffect`. לפעמים, תרצה שיהיה Hook למטרה ספציפית יותר: למשל, נתונים, לעקוב אם אתה משתמש מקומי או להתחבר לחדר צ'אט. כדי לעשות זאת, אתה יכול ליצור Hooks משלך לצרכי היישום שלך.
-In this example, the `usePointerPosition` custom Hook tracks the cursor position, while `useDelayedValue` custom Hook returns a value that's "lagging behind" the value you passed by a certain number of milliseconds. Move the cursor over the sandbox preview area to see a moving trail of dots following the cursor:
+בדוגמה זו, ה-Hook המותאם אישית `usePointerPosition` עוקב אחר מיקום הסמן, בעוד `useDelayedValue` Hook המותאם אישית מחזיר ערך ש"פוגר מאחורי" הערך שעברת במספר מסוים של אלפיות שניות. הזז את הסמן מעל אזור התצוגה המקדימה של ארגז החול כדי לראות שובל נע של נקודות בעקבות הסמן:
<Sandpack>
@@ -835,14 +835,15 @@ body { min-height: 300px; }
</Sandpack>
-You can create custom Hooks, compose them together, pass data between them, and reuse them between components. As your app grows, you will write fewer Effects by hand because you'll be able to reuse custom Hooks you already wrote. There are also many excellent custom Hooks maintained by the React community.
+אתה יכול ליצור הHooks מותאמים באופן אישי, לחבר אותם יחד, להעביר נתונים, ולעשות בהם שימוש חוזר בין רכיבים. ככל שהאפליקציה שלך תגדל, תכתוב פחות אפקטים ביד אם תעשה שימוש חוזר ב-Hooks מותאמים אישית כתבת. יש גם הרבה הHooks מותאמים אישיים מצוינים שמתוחזקים על ידי קהילת React.
<LearnMore path="/learn/reusing-logic-with-custom-hooks">
-Read **[Reusing Logic with Custom Hooks](/learn/reusing-logic-with-custom-hooks)** to learn how to share logic between components.
+קרא את **[שימוש חוזר בבלוגיקה עם ווים מותאמים אישית](/learn/reusing-logic-with-custom-hooks)** כדי ללמוד כיצד לשתף לוגיקה בין רכיבים.
</LearnMore>
-## What's next? {/*whats-next*/}
+## מה הלאה? {/*מה-הבא*/}
+
+עברו אל [התייחסות לערכים עם Refs](/learn/referencing-values-with-refs) כדי להתחיל לקרוא פרק זה עמוד אחר עמוד!
-Head over to [Referencing Values with Refs](/learn/referencing-values-with-refs) to start reading this chapter page by page!
diff --git a/src/content/learn/extracting-state-logic-into-a-reducer.md b/src/content/learn/extracting-state-logic-into-a-reducer.md
index 5c08c0123..41d8e020f 100644
--- a/src/content/learn/extracting-state-logic-into-a-reducer.md
+++ b/src/content/learn/extracting-state-logic-into-a-reducer.md
@@ -1,25 +1,25 @@
---
-title: Extracting State Logic into a Reducer
+title: "חילוץ לוגיקת state ל-reducer"
---
<Intro>
-Components with many state updates spread across many event handlers can get overwhelming. For these cases, you can consolidate all the state update logic outside your component in a single function, called a _reducer._
+רכיבים עם עדכוני מצב רבים מהמפוארים על פני רופאי אירועים רבים יכולים להיות מהמם. אלה, אתה יכול לאחד את כל עדכון הstate מחוץ לרכיב שלך בפונקציה אחת, הנקראת _reducer._
</Intro>
<YouWillLearn>
-- What a reducer function is
-- How to refactor `useState` to `useReducer`
-- When to use a reducer
-- How to write one well
+- מהי פונקציית reducer
+- איך לשנות את 'useState' ל-'useReducer'
+- מתי להשתמש בreducer
+- איך לכתוב אחד טוב
</YouWillLearn>
-## Consolidate state logic with a reducer {/*consolidate-state-logic-with-a-reducer*/}
+## איחוד היגיון מצב עם reducer {/*consolide-state-logic-with-a-reducer*/}
-As your components grow in complexity, it can get harder to see at a glance all the different ways in which a component's state gets updated. For example, the `TaskApp` component below holds an array of `tasks` in state and uses three different event handlers to add, remove, and edit tasks:
+כמה שהרכיבים שלך גדלים במורכבות, זה יהיה קשה יותר לראות במבט אחד את כל הדרכים השונות שבהן מצב הרכיב מתעדכן. לדוגמה, הרכיב 'TaskApp' למטה מחזיק מערך של 'משימות' בstate ומשתמש בשלושה מטפלי אירועים כדי להוסיף ולערוך משימות:
<Sandpack>
@@ -179,17 +179,17 @@ li {
</Sandpack>
-Each of its event handlers calls `setTasks` in order to update the state. As this component grows, so does the amount of state logic sprinkled throughout it. To reduce this complexity and keep all your logic in one easy-to-access place, you can move that state logic into a single function outside your component, **called a "reducer".**
+כל אחד מעובדי העסקים שלו קורא 'שואל' על מנת לעדכן את הstate. ככל שחשוב זה גדל, כך גדלה כמות ההיגיון של הstate המפוזרת בו. כדי להפחית את המורכבות הזו ולשמור את כל ההיגיון שלך במקום אחד קל לגעת, אתה יכול להעביר את הstate הזה לפונקציה יחידה מחוץ לרכיב שלך, **המכונה "reducer".**
-Reducers are a different way to handle state. You can migrate from `useState` to `useReducer` in three steps:
+reducer הם דרך אחרת בstate. אתה יכול לעבור מ'useState' ל'useReducer' בשלושה שלבים:
-1. **Move** from setting state to dispatching actions.
-2. **Write** a reducer function.
-3. **Use** the reducer from your component.
+1. **עבור** מstate הגדרה לפעולות שיגור.
+2. **כתוב** פונקציית reducer.
+3. **השתמש** בreducer מהרכיב שלך.
-### Step 1: Move from setting state to dispatching actions {/*step-1-move-from-setting-state-to-dispatching-actions*/}
+### שלב 1: מעבר מstate לפעולות שיגור {/*step-1-movefrom-setting-state-to-dispatching-actions*/}
-Your event handlers currently specify _what to do_ by setting state:
+מטפלי האירועים שלך מציינים כעת _מה לעשות_ על ידי הגדרת מצב:
```js
function handleAddTask(text) {
@@ -220,13 +220,13 @@ function handleDeleteTask(taskId) {
}
```
-Remove all the state setting logic. What you are left with are three event handlers:
+הסר את כל הלוגיקה של הגדרות הstate. מה שנותר לך הם שלושה מטפלי אירועים:
-- `handleAddTask(text)` is called when the user presses "Add".
-- `handleChangeTask(task)` is called when the user toggles a task or presses "Save".
-- `handleDeleteTask(taskId)` is called when the user presses "Delete".
+- `handleAddTask(text)` נקרא כאשר המשתמש לוחץ על "הוסף".
+- `handleChangeTask(task)` כאשר המשתמש מחליף משימה או לוחץ על "שמור".
+- `handleDeleteTask(taskId)` נקרא כאשר משתמש לוחץ על "מחק".
-Managing state with reducers is slightly different from directly setting state. Instead of telling React "what to do" by setting state, you specify "what the user just did" by dispatching "actions" from your event handlers. (The state update logic will live elsewhere!) So instead of "setting `tasks`" via an event handler, you're dispatching an "added/changed/deleted a task" action. This is more descriptive of the user's intent.
+ניהול מצב עם reducer שונה במקצת מstate ישיר. במקום להגיד ל-React "מה לעשות" על ידי הגדרת מצב, אתה מציין "מה משתמש בדיוק עשה" על ידי שליחת "פעולות" מרופאי פעולות שלך. (לוגיקת עדכון הstate תתקיים במקום אחר!) אז במקום "להגדיר `משימות`" באמצעות מטפל באירועים, אתה שולח פעולת "הוסף/שונה/מחק משימה". זה מתאר יותר את הכוונת המשתמש.
```js
function handleAddTask(text) {
@@ -252,7 +252,7 @@ function handleDeleteTask(taskId) {
}
```
-The object you pass to `dispatch` is called an "action":
+האובייקט שאתה מעביר ל-'dispatch' נקרא "פעולה":
```js {3-7}
function handleDeleteTask(taskId) {
@@ -266,13 +266,13 @@ function handleDeleteTask(taskId) {
}
```
-It is a regular JavaScript object. You decide what to put in it, but generally it should contain the minimal information about _what happened_. (You will add the `dispatch` function itself in a later step.)
+זהו אובייקט JavaScript רגיל. אתה מחליט מה לשים בו, אבל בדרך כלל הוא צריך להכיל את המינימלי על _מה שקרה_. (תוסיף את פונקציית ה'שליחות' עצמה מאוחרת יותר).
<Note>
-An action object can have any shape.
+לאובייקט פעולה יכול להיות כל צורה.
-By convention, it is common to give it a string `type` that describes what happened, and pass any additional information in other fields. The `type` is specific to a component, so in this example either `'added'` or `'added_task'` would be fine. Choose a name that says what happened!
+לפי המוסכמה, מקובל לתת לו 'סוג' מחרוזת שמתארת את מה שקרה, להעביר כל מידע נוסף בשדות אחרות. ה-`סוג` ספציפי לרכיב, אז בדוגמה או `'added'` או `'added_task'` יהיו בסדר. בחר שם שאומר מה קרה!
```js
dispatch({
@@ -284,9 +284,9 @@ dispatch({
</Note>
-### Step 2: Write a reducer function {/*step-2-write-a-reducer-function*/}
+### שלב 2: כתוב פונקציית reducer {/*שלב-2-כתוב-פונקציית-reducer*/}
-A reducer function is where you will put your state logic. It takes two arguments, the current state and the action object, and it returns the next state:
+פונקציית reducer היא המקום שבו תכניס את היגיון הstate שלך. זה דורש שני ארגומנטים, הstate הנוכחי ואובייקט הפעולה, והוא מחזיר את הstate הבא:
```js
function yourReducer(state, action) {
@@ -294,15 +294,15 @@ function yourReducer(state, action) {
}
```
-React will set the state to what you return from the reducer.
+תגיב תגדיר את הstate למה שאתה מחזיר מפחיד.
-To move your state setting logic from your event handlers to a reducer function in this example, you will:
+כדי להעביר את היגיון הגדרת הstate שלך ממטפלי האירועים שלך לפונקציית reducer בדוגמה זו, תעשה:
-1. Declare the current state (`tasks`) as the first argument.
-2. Declare the `action` object as the second argument.
-3. Return the _next_ state from the reducer (which React will set the state to).
+1. הכריז על הstate הנוכחי (`משימות`) כארגומנט הראשון.
+2. הכריז על אובייקט `פעולה` כארגומנט השני.
+3. החזר את הstate _next_ מפחיד (אשר תגיב יגדיר את הstate אליו).
-Here is all the state setting logic migrated to a reducer function:
+הנה כל הלוגיקה של הגדרות הstate שעברה לפונקציית reducer:
```js
function tasksReducer(tasks, action) {
@@ -331,13 +331,13 @@ function tasksReducer(tasks, action) {
}
```
-Because the reducer function takes state (`tasks`) as an argument, you can **declare it outside of your component.** This decreases the indentation level and can make your code easier to read.
+מכיוון שפונקציית הreducer לוקחת מצב (`משימות`) כארגומנט, אתה יכול **להכריז עליו מחוץ לרכיב שלך.** זה מקטין את רמת ההזחה ויכול להקל על הקריאה של הקוד שלך.
<Note>
-The code above uses if/else statements, but it's a convention to use [switch statements](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/switch) inside reducers. The result is the same, but it can be easier to read switch statements at a glance.
+הקוד שלמעלה משתמש בהצהרות if/else, אבל זה מוסכמה להשתמש ב[switch statements](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/switch) בתוך reducer. התוצאה היא, אבל יכול להיות קל יותר לקרוא את הצהרות מתג במבט חטוף.
-We'll be using them throughout the rest of this documentation like so:
+אנו נשתמש בהם לאורך שאר התיעוד הזה כך:
```js
function tasksReducer(tasks, action) {
@@ -371,19 +371,19 @@ function tasksReducer(tasks, action) {
}
```
-We recommend wrapping each `case` block into the `{` and `}` curly braces so that variables declared inside of different `case`s don't clash with each other. Also, a `case` should usually end with a `return`. If you forget to `return`, the code will "fall through" to the next `case`, which can lead to mistakes!
+אנו ממליצים לעטוף כל בלוק `מקרה` בסוגריים מתולתלים `{` ו`}` כך שמשתנים המוצהרים בתוך `מקרה` שונים לא יתנגשו זה בזה. כמו כן, `מקרה` אמור להסתיים בדרך כלל ב`החזרה`. אם תשכחו `להחזיר`, הקוד "יפול" ל`מקרה` הבא, מה שעלול להוביל לטעויות!
-If you're not yet comfortable with switch statements, using if/else is completely fine.
+אם אתה עדיין לא מרגיש בנוח עם הצהרות החלף, השימוש ב-if/else הוא לגמרי בסדר.
</Note>
<DeepDive>
-#### Why are reducers called this way? {/*why-are-reducers-called-this-way*/}
+#### מדוע קוראים לreducers כך? {/*למה-reducer-בדרך-זו*/}
-Although reducers can "reduce" the amount of code inside your component, they are actually named after the [`reduce()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce) operation that you can perform on arrays.
+למרות שreducers יכולים "להפחית" את כמות הקוד בתוך הרכיב שלך, הם למעשה נקראים על שם פעולת [`reduce()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce) יכולים לבצע על מערכים.
-The `reduce()` operation lets you take an array and "accumulate" a single value out of many:
+פעולת `reduce()` מאפשרת לך לקחת מערך ו"לצבור" ערך בודד מתוך רבים:
```
const arr = [1, 2, 3, 4, 5];
@@ -392,9 +392,9 @@ const sum = arr.reduce(
); // 1 + 2 + 3 + 4 + 5
```
-The function you pass to `reduce` is known as a "reducer". It takes the _result so far_ and the _current item,_ then it returns the _next result._ React reducers are an example of the same idea: they take the _state so far_ and the _action_, and return the _next state._ In this way, they accumulate actions over time into state.
+הפונקציה שאתה מעביר ל-'reduce' ידועה בתור "reducer". הוא לוקח את _התוצאה עד כה_ ואת _הפריט הנוכחי,_ ואז הוא מחזיר את _התוצאה הבאה._ reducerי תגובה הם דוגמה לא רעיון: הם לוקחים את _state עד כה_ ו_פעולה_, ומחזירים את _state הבא._ בדרך זו, הם צוברים לאורך זמן הstate.
-You could even use the `reduce()` method with an `initialState` and an array of `actions` to calculate the final state by passing your reducer function to it:
+אתה יכול אפילו להשתמש בשיטת `reduce()` עם `initialState` ומערך של `פעולות` כדי לחשב את הstate הסופי על ידי העברת פונקציית הreducerה שלך אליו:
<Sandpack>
@@ -453,43 +453,43 @@ export default function tasksReducer(tasks, action) {
</Sandpack>
-You probably won't need to do this yourself, but this is similar to what React does!
+כנראה שלא תצטרכו לעשות זאת בעצמכם, אבל זה דומה למה ש-React עושה!
</DeepDive>
-### Step 3: Use the reducer from your component {/*step-3-use-the-reducer-from-your-component*/}
+### שלב 3: השתמש בreducer מהרכיב שלך {/*step-3-use-the-reducer-from-your-component*/}
-Finally, you need to hook up the `tasksReducer` to your component. Import the `useReducer` Hook from React:
+לבסוף, עליך לחבר את 'משימות reducerות' לרכיב שלך. ייבא את ה- 'useReducer' מ-React:
```js
import { useReducer } from 'react';
```
-Then you can replace `useState`:
+אז אתה יכול להחליף את 'useState':
```js
const [tasks, setTasks] = useState(initialTasks);
```
-with `useReducer` like so:
+עם 'useReducer' כך:
```js
const [tasks, dispatch] = useReducer(tasksReducer, initialTasks);
```
-The `useReducer` Hook is similar to `useState`—you must pass it an initial state and it returns a stateful value and a way to set state (in this case, the dispatch function). But it's a little different.
+ה- `useReducer` Hook דומה ל-`useState` - עליך להעביר לו מצב התחלתי והוא מחזיר ערך stateful ודרך להגדיר מצב (במקרה זה, פונקציית השילוח). אבל זה קצת שונה.
-The `useReducer` Hook takes two arguments:
+ה- 'useReducer' Hook לוקח שני ארגומנטים:
-1. A reducer function
-2. An initial state
+1. פונקציית reducer
+2. מצב ראשוני
-And it returns:
+וזה מחזיר:
-1. A stateful value
-2. A dispatch function (to "dispatch" user actions to the reducer)
+1. ערך ממלכתי
+2. פונקציית שיגור (כדי "לשלוח" פעולות משתמש לreducer)
-Now it's fully wired up! Here, the reducer is declared at the bottom of the component file:
+עכשיו זה מחובר לגמרי! כאן, הreducer מוצהר בתחתית קובץ הרכיבים:
<Sandpack>
@@ -674,7 +674,7 @@ li {
</Sandpack>
-If you want, you can even move the reducer to a different file:
+אם תרצה, אתה יכול אפילו להעביר את הreducer לקובץ אחר:
<Sandpack>
@@ -862,30 +862,30 @@ li {
</Sandpack>
-Component logic can be easier to read when you separate concerns like this. Now the event handlers only specify _what happened_ by dispatching actions, and the reducer function determines _how the state updates_ in response to them.
+לוגיקה של רכיבים יכולה להיות קלה יותר לקריאה כאשר אתה מפריד בין חששות כמו זה. כעת מטפלי האירועים מציינים רק _מה קרה_ על ידי שיגור פעולות, ופונקציית הreducer קובעת _איך הstate מתעדכן_ בתגובה להן.
-## Comparing `useState` and `useReducer` {/*comparing-usestate-and-usereducer*/}
+## השוואת `useState` ו-`useReducer` {/*comparing-usestate-and-usereducer*/}
-Reducers are not without downsides! Here's a few ways you can compare them:
+לreducers אין חסרונות! הנה כמה דרכים שבהן תוכל להשוות ביניהם:
-- **Code size:** Generally, with `useState` you have to write less code upfront. With `useReducer`, you have to write both a reducer function _and_ dispatch actions. However, `useReducer` can help cut down on the code if many event handlers modify state in a similar way.
-- **Readability:** `useState` is very easy to read when the state updates are simple. When they get more complex, they can bloat your component's code and make it difficult to scan. In this case, `useReducer` lets you cleanly separate the _how_ of update logic from the _what happened_ of event handlers.
-- **Debugging:** When you have a bug with `useState`, it can be difficult to tell _where_ the state was set incorrectly, and _why_. With `useReducer`, you can add a console log into your reducer to see every state update, and _why_ it happened (due to which `action`). If each `action` is correct, you'll know that the mistake is in the reducer logic itself. However, you have to step through more code than with `useState`.
-- **Testing:** A reducer is a pure function that doesn't depend on your component. This means that you can export and test it separately in isolation. While generally it's best to test components in a more realistic environment, for complex state update logic it can be useful to assert that your reducer returns a particular state for a particular initial state and action.
-- **Personal preference:** Some people like reducers, others don't. That's okay. It's a matter of preference. You can always convert between `useState` and `useReducer` back and forth: they are equivalent!
+- **קוד גודל:** בדרך כלל, עם 'useState' אתה צריך לכתוב פחות קוד מראש. עם 'useReducer', אתה צריך לכתוב גם פונקציית reducers _ו_ פעולות שיגור. עם זאת, 'useReducer' יכול לעזור לצמצם את הקוד אם מטפלים אירועים רבים משנים מצב בצורה דומה.
+- **קריאה:** 'useState' קל מאוד לקריאה כאשר עדכוני הstate פשוטים. כשהם נעשים מורכבים יותר, הם יכולים למלא את הקוד של הרכיב והקשות על הסריקה. במקרה זה, 'useReducer' מאפשר לך להפריד בצורה נקייה את _איך_ של לוגיקת העדכון _מה קרה_ של מטפלי אירועים.
+- **ניפוי באגים:** כאשר יש לך באג עם 'useState', זה יכול להיות קשה לדעת _היכן_ הstate הוא גדר בצורה שגויה, ו-_למה_. עם `useReducer`, אתה יכול להוסיף יומן מסוף לreducer שלך כדי לראות את כל עדכון מצב, ו-_למה_ זה קרה (בשל איזו `פעולה`). אם כל `פעולה` נכונה, תדע שהטעות היא בלוגית הreducerה עצמה. עם זאת, אתה צריך לעבור יותר קוד מאשר עם 'useState'.
+- **בדיקה:** reducer היא פונקציה טהורה שאינה תלויה ברכיב שלך. זה אומר שאתה יכול לייצא ולבדוק אותו בנפרד בבידוד. למרות שבדרך כלל עדיף לבדוק רכיבים בסביבה מציאותית יותר, עבור לוגיקה של עדכון מצב מורכב זה יכול להיות שימושי לטעון שreducer שלך מחזיר מצב מסוים עבור מצב ופעולה ראשוניים מסוימים.
+- **העדפה אישית:** יש אנשים שאוהבים reducer, אחרים לא. זה בסדר. זה עניין של העדפה. אתה תמיד יכול להמיר בין 'useState' ו-'useReducer' הלוך ושוב: הם שווים!
-We recommend using a reducer if you often encounter bugs due to incorrect state updates in some component, and want to introduce more structure to its code. You don't have to use reducers for everything: feel free to mix and match! You can even `useState` and `useReducer` in the same component.
+אנו ממלי להשתמש בreducer אם אתה נתקל בקשר בבאגים עקב עדכוני מצב שגויים ברכיבים, וברצונך להכניס מבנה נוסף לקוד שלו. לא חייבים להשתמש במקסימום לכל דבר: אתם מחפשים לערבב ולהתאים! אתה יכול אפילו 'useState' ו-'useReducer' באותו רכיב.
-## Writing reducers well {/*writing-reducers-well*/}
+## reducerי כתיבה היטב {/*reducerי-כתיבה-טוב*/}
-Keep these two tips in mind when writing reducers:
+זכור את שני הטיפים הבאים בעת כתיבת reducer:
-- **Reducers must be pure.** Similar to [state updater functions](/learn/queueing-a-series-of-state-updates), reducers run during rendering! (Actions are queued until the next render.) This means that reducers [must be pure](/learn/keeping-components-pure)—same inputs always result in the same output. They should not send requests, schedule timeouts, or perform any side effects (operations that impact things outside the component). They should update [objects](/learn/updating-objects-in-state) and [arrays](/learn/updating-arrays-in-state) without mutations.
-- **Each action describes a single user interaction, even if that leads to multiple changes in the data.** For example, if a user presses "Reset" on a form with five fields managed by a reducer, it makes more sense to dispatch one `reset_form` action rather than five separate `set_field` actions. If you log every action in a reducer, that log should be clear enough for you to reconstruct what interactions or responses happened in what order. This helps with debugging!
+- **reducer חייבים להיות טהורים.** בדומה ל[עדכון מצב פונקציות](/learn/queueing-a-series-of-state-updates), reducer פועלים על העיבוד! (פעולות עומדות לפי עד לעיבוד הבא.) משמעות הדבר היא שreducers [חייבים להיות טהורים](/learn/keeping-components-pure) - אותן כניסות תמיד מביאות לאותו פלט. אסור להם לשלוח בקשות, לתזמן פסקי זמן או לבצע פעולה לוואי כלשהן (פעולות שמשפיעות על דברים מחוץ לרכיב). עליהם לעדכן את [objects](/learn/updating-objects-in-state) ו-[מערכים](/learn/updating-arrays-in-state) ללא מוטציות.
+- **כל פעולה מתארת אינטראקציה של משתמש בודד, גם אם זה מוביל לשינויים מרובים בנתונים.** לדוגמה, אם לוחץ משתמש על "איפוס" בטופס עם חמש שדות המנוהל על ידי reducer, הגיוני יותר לשלוח פעולת `reset_form` אחת ולא חמש פעולות `set_field` נפרדות. אם אתה רושם כל פעולה בreducer, יומן זה אמור להיות ברור מספיק כדי לשחזר אילו אינטראקציות או תגובות התרחשו באיזה סדר. זה עוזר באיתור באגים!
-## Writing concise reducers with Immer {/*writing-concise-reducers-with-immer*/}
+## כתיבת reducers תמציתיים עם Immer {/*כתיבה-תמצית-reducer-עם-immer*/}
-Just like with [updating objects](/learn/updating-objects-in-state#write-concise-update-logic-with-immer) and [arrays](/learn/updating-arrays-in-state#write-concise-update-logic-with-immer) in regular state, you can use the Immer library to make reducers more concise. Here, [`useImmerReducer`](https://github.com/immerjs/use-immer#useimmerreducer) lets you mutate the state with `push` or `arr[i] =` assignment:
+בדיוק כמו עם [עדכון הstates](/learn/updating-objects-in-state#write-concise-update-logic-with-immer) ו-[מערכים](/learn/updating-arrays-in-state#write-concise-update-logic-with-immer) כדי. כאן, [`useImmerReducer`](https://github.com/immerjs/use-immer#useimmerreducer) תוכל לשנות את הstate עם הקצאת `push` או `arr[i] =`:
<Sandpack>
@@ -1082,34 +1082,34 @@ li {
</Sandpack>
-Reducers must be pure, so they shouldn't mutate state. But Immer provides you with a special `draft` object which is safe to mutate. Under the hood, Immer will create a copy of your state with the changes you made to the `draft`. This is why reducers managed by `useImmerReducer` can mutate their first argument and don't need to return state.
+אפשר להיות טהורים, אז הם לא צריכים לעבור תנועה בstate. אבל אני מספקת לך אובייקט `טיוטה` מיוחד שבטוח מוטציה. מתחת למכסה המנוע, Immer תיצור עותק של הstate שלך עם השינויים שביצעת ב'טיוטה'. אתה יכול לשנות את הטיעון הראשון שלהם ואינם צריכים להחזיר מצב.
<Recap>
-- To convert from `useState` to `useReducer`:
- 1. Dispatch actions from event handlers.
- 2. Write a reducer function that returns the next state for a given state and action.
- 3. Replace `useState` with `useReducer`.
-- Reducers require you to write a bit more code, but they help with debugging and testing.
-- Reducers must be pure.
-- Each action describes a single user interaction.
-- Use Immer if you want to write reducers in a mutating style.
+- להמיר מ'useState' ל'useReducer':
+ 1. שיגור פעולות ממטפלי אירועים.
+ 2. כתוב פונקציית reducer שמחזירה את הstate הבא עבור מצב ופעולה נתונים.
+ 3. החלף את 'useState' ב-'useReducer'.
+- reducer דורשים ממך לכתוב קצת יותר קוד, אבל הם עוזרים בניפוי באגים ובדיקות.
+- reducer חייבים להיות טהורים.
+- כל פעולה מתארת אינטראקציה של משתמש בודד.
+- השתמש ב-Immer אם אתה רוצה לכתוב reducer נוסח מוטציה.
</Recap>
<Challenges>
-#### Dispatch actions from event handlers {/*dispatch-actions-from-event-handlers*/}
+#### שליחת פעולות ממטפלי אירועים {/*משלוח-פעולות-מ-מתמודדים-עם-אירועים*/}
-Currently, the event handlers in `ContactList.js` and `Chat.js` have `// TODO` comments. This is why typing into the input doesn't work, and clicking on the buttons doesn't change the selected recipient.
+נכון לעכשיו, למטפלים ב-`ContactList.js` וב-`Chat.js` יש הערות `// TODO`. זה מה שהקלדה בקלט לא עובדת, ולחיצה על הכפתורים לא משנה את הנמען שנבחר.
-Replace these two `// TODO`s with the code to `dispatch` the corresponding actions. To see the expected shape and the type of the actions, check the reducer in `messengerReducer.js`. The reducer is already written so you won't need to change it. You only need to dispatch the actions in `ContactList.js` and `Chat.js`.
+החלף את שני `// TODO` אלה בקוד כדי `לשלוח` את התאימות לפעולות. ראה את הרצון כדי ואת סוג הפעולות, בדוק את הreducer ב- `messengerReducer.js`. הreducer כבר כתוב כך שלא תתאים אותו. אתה רק צריך לשלוח את הפעולות ב-'ContactList.js' ו-'Chat.js'.
<Hint>
-The `dispatch` function is already available in both of these components because it was passed as a prop. So you need to call `dispatch` with the corresponding action object.
+הפונקציה 'שיגור' כבר זמינה בשני הרכיבים הללו מכיוון שהיא הועברה כעזר. אז אתה צריך לקרוא 'שיגור' עם אובייקט הפעולה המתאים.
-To check the action object shape, you can look at the reducer and see which `action` fields it expects to see. For example, the `changed_selection` case in the reducer looks like this:
+כדי לבדוק את צורת עצם הפעולה, אתה יכול להסתכל על הreducer ולראות אילו שדות 'פעולה' הוא מצפה לראות. לדוגמה, מקרה 'changed_selection' בreducer נראה כך:
```js
case 'changed_selection': {
@@ -1120,7 +1120,7 @@ case 'changed_selection': {
}
```
-This means that your action object should have a `type: 'changed_selection'`. You also see the `action.contactId` being used, so you need to include a `contactId` property into your action.
+זה אומר של עניין הפעולה שלך צריך להיות 'סוג: 'changed_selection''. אתה גם רואה את 'action.contactId' בשימוש, עליך לכלול את מאפיין 'contactId' בפעולה שלך.
</Hint>
@@ -1256,7 +1256,7 @@ textarea {
<Solution>
-From the reducer code, you can infer that actions need to look like this:
+מקוד הreducer, אתה יכול להסיק שפעולות צריכות להיראות כך:
```js
// When the user presses "Alice"
@@ -1272,7 +1272,7 @@ dispatch({
});
```
-Here is the example updated to dispatch the corresponding messages:
+הנה הדוגמה שעודכנה לשליחת ההודעות המתאימות:
<Sandpack>
@@ -1411,12 +1411,12 @@ textarea {
</Solution>
-#### Clear the input on sending a message {/*clear-the-input-on-sending-a-message*/}
+#### נקה את הקלט בשליחת הודעה {/*clear-the-input-on-שליחת-הודעה*/}
-Currently, pressing "Send" doesn't do anything. Add an event handler to the "Send" button that will:
+נכון לעכשיו, לחיצה על "שלח" לא עושה כלום. הוסף מטפל באירועים ללחצן "שלח" שיבצע:
-1. Show an `alert` with the recipient's email and the message.
-2. Clear the message input.
+1. הצג `התראה` עם האימייל של הנמען וההודעה.
+2. נקה את קלט ההודעה.
<Sandpack>
@@ -1555,7 +1555,7 @@ textarea {
<Solution>
-There are a couple of ways you could do it in the "Send" button event handler. One approach is to show an alert and then dispatch an `edited_message` action with an empty `message`:
+ישנן מספר דרכים שבהן תוכל לעשות זאת במטפל באירועים של כפתור "שלח". גישה אחת היא להציג התראה ולאחר מכן לשלוח פעולת `עריכה_הודעה` עם `הודעה` ריקה:
<Sandpack>
@@ -1701,9 +1701,9 @@ textarea {
</Sandpack>
-This works and clears the input when you hit "Send".
+זה עובד ומנקה את הקלט כאשר אתה לוחץ על "שלח".
-However, _from the user's perspective_, sending a message is a different action than editing the field. To reflect that, you could instead create a _new_ action called `sent_message`, and handle it separately in the reducer:
+עם זאת, _מנקודת המבט של המשתמש_, שליחת הודעה היא פעולה שונה מאשר עריכת השדה. כדי לשקף זאת, אתה יכול במקום זאת ליצור פעולה _חדשה_ בשם 'הודעה_שלחה', ולטפל בה בנפרד בreducer:
<Sandpack>
@@ -1854,15 +1854,15 @@ textarea {
</Sandpack>
-The resulting behavior is the same. But keep in mind that action types should ideally describe "what the user did" rather than "how you want the state to change". This makes it easier to later add more features.
+ההתנהגות המתקבלת זהה. אבל זכור שסוגי פעולה צריכים לתאר באופן אידיאלי "מה המשתמש עשה" ולא "איך אתה רוצה שstate תשתנה". זה מקל להוסיף מאוחר יותר תכונות נוספות.
-With either solution, it's important that you **don't** place the `alert` inside a reducer. The reducer should be a pure function--it should only calculate the next state. It should not "do" anything, including displaying messages to the user. That should happen in the event handler. (To help catch mistakes like this, React will call your reducers multiple times in Strict Mode. This is why, if you put an alert in a reducer, it fires twice.)
+עם כל אחד מהפתרונות, חשוב ש**לא** תציב את ה'התראה' בתוך reducer. הוא צריך לחשב רק את הstate הבא. זה לא צריך "לעשות" שום דבר, כולל הצגת הודעות למשתמש. זה אמור לקרות בטיפול. (כדי לעזור לתפוס טעויות כמו זו, תגיב יתקשר לreducers שלך מכניסים מספר פעמים בstate קפדני.
</Solution>
-#### Restore input values when switching between tabs {/*restore-input-values-when-switching-between-tabs*/}
+#### שחזור ערכי קלט בזמן מעבר בין כרטיסיות {/*restore-input-values-when-switching-between-tabs*/}
-In this example, switching between different recipients always clears the text input:
+בדוגמה זו, מעבר בין נמענים שונים תמיד מנקה את קלט הטקסט:
```js
case 'changed_selection': {
@@ -1873,13 +1873,13 @@ case 'changed_selection': {
};
```
-This is because you don't want to share a single message draft between several recipients. But it would be better if your app "remembered" a draft for each contact separately, restoring them when you switch contacts.
+הסיבה לכך היא שאינך רוצה לשתף טיוטת הודעה אחת בין מספר נמענים. אבל זה יהיה טוב יותר אם האפליקציה שלך "תזכור" טיוטה עבור כל איש קשר בנפרד, ותשחזר אותם כאשר אתה מחליף אנשי קשר.
-Your task is to change the way the state is structured so that you remember a separate message draft _per contact_. You would need to make a few changes to the reducer, the initial state, and the components.
+המשימה שלך היא לשנות את האופן שבו הstate בנוי כך שתזכור טיוטת הודעה נפרדת _לכל איש קשר_. תצטרך לבצע כמה שינויים בreducer, בstate ההתחלתי וברכיבים.
<Hint>
-You can structure your state like this:
+אתה יכול לבנות את הstate שלך כך:
```js
export const initialState = {
@@ -1891,7 +1891,7 @@ export const initialState = {
};
```
-The `[key]: value` [computed property](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer#computed_property_names) syntax can help you update the `messages` object:
+התחביר `[key]: value` [מאפיין ממוחשב](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer#computed_property_names) יכול לעזור לך לעדכן את אובייקט `הודעות`:
```js
{
@@ -2053,7 +2053,7 @@ textarea {
<Solution>
-You'll need to update the reducer to store and update a separate message draft per contact:
+יהיה עליך לעדכן את הreducer כדי לאחסן ולעדכן טיוטת הודעה נפרדת לכל איש קשר:
```js
// When the input is edited
@@ -2071,13 +2071,13 @@ case 'edited_message': {
}
```
-You would also update the `Messenger` component to read the message for the currently selected contact:
+תעדכן גם את רכיב 'מסנג'ר' כדי לקרוא את ההודעה של איש הקשר שנבחר כעת:
```js
const message = state.messages[state.selectedId];
```
-Here is the complete solution:
+הנה הפתרון המלא:
<Sandpack>
@@ -2237,19 +2237,19 @@ textarea {
</Sandpack>
-Notably, you didn't need to change any of the event handlers to implement this different behavior. Without a reducer, you would have to change every event handler that updates the state.
+יש לציין שלא היית צריך לשנות אף אחד מהמטפלים באירועים כדי ליישם את ההתנהגות השונה הזו. ללא reducer, תצטרך לשנות כל מטפל באירועים שמעדכן את הstate.
</Solution>
-#### Implement `useReducer` from scratch {/*implement-usereducer-from-scratch*/}
+#### הטמעת 'useReducer' מאפס {/*implement-usereducer-from-scratch*/}
-In the earlier examples, you imported the `useReducer` Hook from React. This time, you will implement _the `useReducer` Hook itself!_ Here is a stub to get you started. It shouldn't take more than 10 lines of code.
+בדוגמאות הקודמות, ייבאת את ה- 'useReducer' מ-React. הפעם, אתה תטמיע את _ה-'useReducer' Hook עצמו!_ הנה בדל שיעזור לך להתחיל. זה לא אמור לקחת יותר מ-10 שורות קוד.
-To test your changes, try typing into the input or select a contact.
+כדי לבדוק את השינויים שלך, נסה להקליד בקלט או בחר איש קשר.
<Hint>
-Here is a more detailed sketch of the implementation:
+להלן סקיצה מפורטת יותר של היישום:
```js
export function useReducer(reducer, initialState) {
@@ -2263,7 +2263,7 @@ export function useReducer(reducer, initialState) {
}
```
-Recall that a reducer function takes two arguments--the current state and the action object--and it returns the next state. What should your `dispatch` implementation do with it?
+נזכיר שפונקציית reducer לוקחת שני ארגומנטים - הstate הנוכחי ואובייקט הפעולה - והיא מחזירה את הstate הבא. מה צריך לעשות עם יישום ה'שליחות' שלך?
</Hint>
@@ -2439,7 +2439,7 @@ textarea {
<Solution>
-Dispatching an action calls a reducer with the current state and the action, and stores the result as the next state. This is what it looks like in code:
+שיגור פעולה קורא לreducer עם הstate הנוכחי והפעולה, ומאחסן את התוצאה כstate הבא. כך זה נראה בקוד:
<Sandpack>
@@ -2614,7 +2614,7 @@ textarea {
</Sandpack>
-Though it doesn't matter in most cases, a slightly more accurate implementation looks like this:
+למרות שזה לא משנה ברוב המקרים, יישום קצת יותר מדויק נראה כך:
```js
function dispatch(action) {
@@ -2622,8 +2622,9 @@ function dispatch(action) {
}
```
-This is because the dispatched actions are queued until the next render, [similar to the updater functions.](/learn/queueing-a-series-of-state-updates)
+מה היא הסיבה שהפעולות שנשלחו לפי עד לעיבוד הבא, [בדומה לפונקציות העדכון.](/learn/queueing-a-series-of-state-updates)
</Solution>
</Challenges>
+
diff --git a/src/content/learn/importing-and-exporting-components.md b/src/content/learn/importing-and-exporting-components.md
index b458ef402..58ed1ff10 100644
--- a/src/content/learn/importing-and-exporting-components.md
+++ b/src/content/learn/importing-and-exporting-components.md
@@ -1,26 +1,26 @@
---
-title: Importing and Exporting Components
+title: ייבוא וייצוא קומפוננטות
---
<Intro>
-The magic of components lies in their reusability: you can create components that are composed of other components. But as you nest more and more components, it often makes sense to start splitting them into different files. This lets you keep your files easy to scan and reuse components in more places.
+הקסם של קומפוננטות טמון בשימוש החוזר בהן: אפשר ליצור קומפוננטות שמורכבות מקומפוננטות אחרות. אבל ככל שמקננים יותר קומפוננטות, בדרך כלל כדאי להתחיל לפצל אותן לקבצים נפרדים. כך הקבצים נשארים קריאים יותר, ואפשר להשתמש באותן קומפוננטות במקומות נוספים.
</Intro>
<YouWillLearn>
-* What a root component file is
-* How to import and export a component
-* When to use default and named imports and exports
-* How to import and export multiple components from one file
-* How to split components into multiple files
+* מהו קובץ קומפוננטת שורש
+* איך לייבא ולייצא קומפוננטה
+* מתי להשתמש בייבוא/ייצוא סטייל ברירת מחדל ומתי סטייל בשם
+* איך לייבא ולייצא כמה קומפוננטות מאותו קובץ
+* איך לפצל קומפוננטות לכמה קבצים
</YouWillLearn>
-## The root component file {/*the-root-component-file*/}
+## קובץ קומפוננט השורש {/*the-root-component-file*/}
-In [Your First Component](/learn/your-first-component), you made a `Profile` component and a `Gallery` component that renders it:
+ב-[הקומפוננטה הראשונה שלכם](/learn/your-first-component), יצרתם קומפוננטת `פרופיל` וקומפוננטת `גלריה` שמרנדרת אותה:
<Sandpack>
@@ -52,17 +52,17 @@ img { margin: 0 10px 10px 0; height: 90px; }
</Sandpack>
-These currently live in a **root component file,** named `App.js` in this example. Depending on your setup, your root component could be in another file, though. If you use a framework with file-based routing, such as Next.js, your root component will be different for every page.
+כרגע שתיהן נמצאות ב-** קובץ קומפוננטת השורש**, שנקרא בדוגמה הזו `App.js`. בהתאם ל-setup שלכם, קומפוננטת השורש יכולה להיות בקובץ אחר. אם אתם משתמשים ב-framework עם ניתוב מבוסס קבצים, כמו Next.js, קומפוננטת השורש תהיה שונה בכל עמוד.
-## Exporting and importing a component {/*exporting-and-importing-a-component*/}
+## ייצוא וייבוא של קומפוננטה {/*ייצוא-ויבוא-רכיב*/}
-What if you want to change the landing screen in the future and put a list of science books there? Or place all the profiles somewhere else? It makes sense to move `Gallery` and `Profile` out of the root component file. This will make them more modular and reusable in other files. You can move a component in three steps:
+מה אם תרצו גם לשנות את הפתיחה ולשים שם רשימת ספרי מדע? או להעביר את כל הפרופילים למקום אחר? במקרה כזה הגיוני להעביר את `גלריה` ו`פרופיל` מחוץ לקובץ השורש. כך הן יהיו מודולריות יותר וקל יותר לעשות שימוש חוזר בקבצים אחרים. אפשר להעביר קומפוננטה בשלושה צעדים:
-1. **Make** a new JS file to put the components in.
-2. **Export** your function component from that file (using either [default](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/export#using_the_default_export) or [named](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/export#using_named_exports) exports).
-3. **Import** it in the file where you’ll use the component (using the corresponding technique for importing [default](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/import#importing_defaults) or [named](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/import#import_a_single_export_from_a_module) exports).
+1. **צרו** קובץ JS חדש שיכיל את הקומפוננטות.
+2. **ייצאו** את קומפוננטת הפונקציה מהקובץ (באמצעות ייצוא [ברירת מחדל](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/export#using_the_default_export) או [שם](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/export#using_named_exports)).
+3. **ייבאו** אותה בקובץ שבו תשתמשו בה (באמצעות תחביר הייבוא המתאים לייצוא [default](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/import#importing_defaults) או [שם](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/import#import_a_single_export_from_a_module)).
-Here both `Profile` and `Gallery` have been moved out of `App.js` into a new file called `Gallery.js`. Now you can change `App.js` to import `Gallery` from `Gallery.js`:
+כאן גם `פרופיל` וגם `Gallery` הועברו מ-`App.js` לקובץ חדש בשם `Gallery.js`. עכשיו אפשר לעדכן את `App.js` כך שייבא את `Gallery` מתוך `Gallery.js`:
<Sandpack>
@@ -104,60 +104,60 @@ img { margin: 0 10px 10px 0; height: 90px; }
</Sandpack>
-Notice how this example is broken down into two component files now:
+שימו לב איך הדוגמה מחולקת עכשיו לשני קובצי קומפוננטות:
1. `Gallery.js`:
- - Defines the `Profile` component which is only used within the same file and is not exported.
- - Exports the `Gallery` component as a **default export.**
-2. `App.js`:
- - Imports `Gallery` as a **default import** from `Gallery.js`.
- - Exports the root `App` component as a **default export.**
+ - מגדיר את הקומפוננטה `פרופיל`, שמשמשת רק בתוך אותו קובץ זה לא יוצאת.
+ - מייצא את הקומפוננטה `גלריה` כ-**ייצוא ברירת מחדל**.
+2. 'App.js':
+ - מייבא את `Gallery` לפי **ייבוא ברירת מחדל** מתוך `Gallery.js`.
+ - מייצא את קומפוננטת השורש `App` כ-**ייצוא ברירת מחדל**.
<Note>
-You may encounter files that leave off the `.js` file extension like so:
+אפשר שתיתקלו בקבצים שמשמיטים את סיומת `.js`, למשל:
```js
import Gallery from './Gallery';
```
-Either `'./Gallery.js'` or `'./Gallery'` will work with React, though the former is closer to how [native ES Modules](https://developer.mozilla.org/docs/Web/JavaScript/Guide/Modules) work.
+גם `'./Gallery.js'` וגם `'./Gallery'` יעבדו ב-React, אבל אפשרות ראשונה קרובה יותר לאופן של [Native ES Modules](https://developer.mozilla.org/docs/Web/JavaScript/Guide/Modules).
</Note>
<DeepDive>
-#### Default vs named exports {/*default-vs-named-exports*/}
+#### ייצוא ברירת מחדל לעומת ייצוא בשם {/*default-vs-named-exports*/}
-There are two primary ways to export values with JavaScript: default exports and named exports. So far, our examples have only used default exports. But you can use one or both of them in the same file. **A file can have no more than one _default_ export, but it can have as many _named_ exports as you like.**
+יש שתי דרכים עיקריות לייצא ערכים ב-JavaScript: ייצוא ברירת מחדל וייצוא בשם. עד עכשיו הדוגמאות השתמשו רק ב-default, אבל אפשר להשתמש באחת מהשיטות אושתיהן בקובץ. **ל יכול קובץ להיות לכל היותר ייצוא _default_ אחד, אבל אפשר שיהיו בו כמה ייצואי _named_ שרוצים.**
-
+
-How you export your component dictates how you must import it. You will get an error if you try to import a default export the same way you would a named export! This chart can help you keep track:
+האופן שבו אתם מייצאים קומפוננטה קובעים איך צריך לייבא אותה. אם תנסו לייבא ברירת מחדל כמו בשם, תקבלו שגיאה. הטבלה הבאה עוזרת לעשות סדר:
-| Syntax | Export statement | Import statement |
+| תחביר | הצהרת ייצוא | הצהרת ייבוא |
| ----------- | ----------- | ----------- |
-| Default | `export default function Button() {}` | `import Button from './Button.js';` |
-| Named | `export function Button() {}` | `import { Button } from './Button.js';` |
+| ברית מחדל | `יצוא פונקציית ברירת המחדל Button() {}` | `לחצן ייבוא מ'./Button.js';` |
+| בשם | `Export function Button() {}` | `ייבוא{ Button } מ-'./Button.js';` |
-When you write a _default_ import, you can put any name you want after `import`. For example, you could write `import Banana from './Button.js'` instead and it would still provide you with the same default export. In contrast, with named imports, the name has to match on both sides. That's why they are called _named_ imports!
+כשכותבים ייבוא _default_, אפשר לבחור כל שם אחרי `יבוא`. אפשר למשל לכתוב `יבוא בננה מ'./Button.js'`, ועדיין תקבל את אותו ייצוא ברירת המחדל. לעומת זאת, בשם חייב להיות זה בשני הצדדים. לכן קוראים לו ייבוא _named_.
-**People often use default exports if the file exports only one component, and use named exports if it exports multiple components and values.** Regardless of which coding style you prefer, always give meaningful names to your component functions and the files that contain them. Components without names, like `export default () => {}`, are discouraged because they make debugging harder.
+**בדרך כלל משתמשים ב-default export כשקובץ מייצא קומפוננטה אחת בלבד, וב-named exports תוך כמה קומפוננטות או ערכים שת.** בלי קשר לסגנון בחירתו, חשוב לתת שמות משמעותיים לפונקציות הקומפוננטה ולקבצים שמכילים אותן. קומפוננטות ללא שם, כמו `ייצוא ברירת מחדל () => {}`, פחות מומלצות כי הן מקשות על דיבוג.
</DeepDive>
-## Exporting and importing multiple components from the same file {/*exporting-and-importing-multiple-components-from-the-same-file*/}
+## ייצוא וייבוא של כמה קומפוננטות מאותו קובץ {/*ייצוא-ויבוא-רכיבים-מרובים-מה-אותו-קובץ*/}
-What if you want to show just one `Profile` instead of a gallery? You can export the `Profile` component, too. But `Gallery.js` already has a *default* export, and you can't have _two_ default exports. You could create a new file with a default export, or you could add a *named* export for `Profile`. **A file can only have one default export, but it can have numerous named exports!**
+מה אם תרצו להציג רק `פרופיל` אחד במקום גלריה שלמה? אפשר גם לייצא את `פרופיל`. אבל ל-`Gallery.js` כבר יש ייצוא *ברירת מחדל*, ואי אפשר שיהיו שני ייצואי ברירת מחדל בקובץ. אפשר ליצור קובץ חדש עם ייצוא ברירת מחדל, או להוסיף ייצוא *שם* עבור `פרופיל`. **ל יכול להיות רק יצוא ברירת מחדל אחד, אבל הוא יכול להכיל הרבה יצוא בשם.**
<Note>
-To reduce the potential confusion between default and named exports, some teams choose to only stick to one style (default or named), or avoid mixing them in a single file. Do what works best for you!
+לצמצם בלבול בין ברירת מחדל ל-named, יש צוותים שעובדים רק במבנה אחד, או חזק בתוך אותו קובץ. בחרו את מה שעובד הכי טוב אצלכם.
</Note>
-First, **export** `Profile` from `Gallery.js` using a named export (no `default` keyword):
+קודם **ייצאו** את `פרופיל` מתוך `Gallery.js` באמצעות ייצוא שם (בלי מילת המפתח `ברירת מחדל`):
```js
export function Profile() {
@@ -165,13 +165,13 @@ export function Profile() {
}
```
-Then, **import** `Profile` from `Gallery.js` to `App.js` using a named import (with the curly braces):
+לאחר **ייבאו** את `פרופיל` מ-`Gallery.js` אל `App.js הוא` באמצעות יבוא בשם (עם סוגרים מסולסלים):
```js
import { Profile } from './Gallery.js';
```
-Finally, **render** `<Profile />` from the `App` component:
+לבסוף, **רנדרו** את `<פרופיל />` מתוך הקומפוננטה `אפליקציה`:
```js
export default function App() {
@@ -179,7 +179,7 @@ export default function App() {
}
```
-Now `Gallery.js` contains two exports: a default `Gallery` export, and a named `Profile` export. `App.js` imports both of them. Try editing `<Profile />` to `<Gallery />` and back in this example:
+עכשיו `Gallery.js` כולל שני ייצואים: ייצוא ברירת מחדל של `Gallery`, ויצוא בשם `פרופיל`. הקובץ `App.js` מייבא את שניהם. נסו להחליף בדוגמה בין `<Profile />` ל-`<Gallery />` וחזרה:
<Sandpack>
@@ -222,24 +222,24 @@ img { margin: 0 10px 10px 0; height: 90px; }
</Sandpack>
-Now you're using a mix of default and named exports:
+עכשיו אתם משתמשים בשילוב של יצוא ברירת מחדל ושמו:
* `Gallery.js`:
- - Exports the `Profile` component as a **named export called `Profile`.**
- - Exports the `Gallery` component as a **default export.**
+ - מייצא את הקומפוננטה `פרופיל` כ-** בשם ייצוא בשם `פרופיל`**.
+ - מייצא את הקומפוננטה `גלריה` כ-**ייצוא ברירת מחדל**.
* `App.js`:
- - Imports `Profile` as a **named import called `Profile`** from `Gallery.js`.
- - Imports `Gallery` as a **default import** from `Gallery.js`.
- - Exports the root `App` component as a **default export.**
+ - מייבא את `פרופיל` לפי **ייבואבשם `פרופיל`** מתוך `Gallery.js`.
+ - מייבא את `Gallery` לפי **ייבוא ברירת מחדל** מתוך `Gallery.js`.
+ - מייצא את קומפוננטת השורש `App` כ-**ייצוא ברירת מחדל**.
<Recap>
-On this page you learned:
+בעמוד הזה למדתם:
-* What a root component file is
-* How to import and export a component
-* When and how to use default and named imports and exports
-* How to export multiple components from the same file
+* מהו קובץ קומפוננטת שורש
+* איך לייבא ולייצא קומפוננטה
+* מתי ואיך להשתמש בייבוא/ייצוא ברירת מחדל ו-named
+* איך לייצא כמה קומפוננטות מאותו קובץ
</Recap>
@@ -247,22 +247,22 @@ On this page you learned:
<Challenges>
-#### Split the components further {/*split-the-components-further*/}
+#### פצלו את הקומפוננטות עוד יותר {/*פיצול-הרכיבים-לאחר*/}
-Currently, `Gallery.js` exports both `Profile` and `Gallery`, which is a bit confusing.
+כרגע `Gallery.js` מייצא גם את `פרופיל` וגם את `Gallery`, וזה מעט מבלבל.
-Move the `Profile` component to its own `Profile.js`, and then change the `App` component to render both `<Profile />` and `<Gallery />` one after another.
+העבירו את הקומפוננטה `פרופיל` לקובץ נפרד בשם `Profile.js`, ואז עדכנו את הקומפוננטה `אפליקציה` כך שתרנדר גם את `<Profile />` וגם את `<Gallery />` אחד אחרי השני.
-You may use either a default or a named export for `Profile`, but make sure that you use the corresponding import syntax in both `App.js` and `Gallery.js`! You can refer to the table from the deep dive above:
+אפשר להשתמש בייצוא ברירת מחדל או בשם עבור `פרופיל`, אבל ודאו את המשתמשים בתחביר הייבוא המתאים גם ב-`App.js` וגם ב-`Gallery.js`. אפשר להיעזר בטבלה מה-Deep Dive למעלה:
-| Syntax | Export statement | Import statement |
+| תחביר | הצהרת ייצוא | הצהרת ייבוא |
| ----------- | ----------- | ----------- |
-| Default | `export default function Button() {}` | `import Button from './Button.js';` |
-| Named | `export function Button() {}` | `import { Button } from './Button.js';` |
+| ברית מחדל | `יצוא פונקציית ברירת המחדל Button() {}` | `לחצן ייבוא מ'./Button.js';` |
+| בשם | `Export function Button() {}` | `ייבוא{ Button } מ-'./Button.js';` |
<Hint>
-Don't forget to import your components where they are called. Doesn't `Gallery` use `Profile`, too?
+אל תשכחו לייבא קומפוננטות במקום שבו קוראים להן. גם `גלריה` משתמשת ב-`פרופיל`, נכון?
</Hint>
@@ -313,11 +313,11 @@ img { margin: 0 10px 10px 0; height: 90px; }
</Sandpack>
-After you get it working with one kind of exports, make it work with the other kind.
+אחרי שזה עובד עם סוג ייצוא אחד, נסו לגרום לזה לעבוד גם עם הסוג השני.
<Solution>
-This is the solution with named exports:
+זהו הפתרון עם יצוא בשם:
<Sandpack>
@@ -367,7 +367,7 @@ img { margin: 0 10px 10px 0; height: 90px; }
</Sandpack>
-This is the solution with default exports:
+זהו הפתרון עם יצוא ברירת מחדל:
<Sandpack>
@@ -420,3 +420,4 @@ img { margin: 0 10px 10px 0; height: 90px; }
</Solution>
</Challenges>
+
diff --git a/src/content/learn/index.md b/src/content/learn/index.md
index b57655bc4..9b5d7cb1e 100644
--- a/src/content/learn/index.md
+++ b/src/content/learn/index.md
@@ -1,29 +1,29 @@
---
-title: Quick Start
+title: התחלה מהירה
---
<Intro>
-Welcome to the React documentation! This page will give you an introduction to the 80% of React concepts that you will use on a daily basis.
+ברוכים הבאים לתיעוד של תגובה! הדף ייתן לכם היכרות עם 80% מהמושגים ב-React תשתמשו ביום-יום.
</Intro>
<YouWillLearn>
-- How to create and nest components
-- How to add markup and styles
-- How to display data
-- How to render conditions and lists
-- How to respond to events and update the screen
-- How to share data between components
+- איך ליצור קומפוננטות ולקנן ביניהן
+- איך להוסיף סימון (סימון) ועיצוב (סגנונות)
+- איך להציג נתונים
+- איך לרנדר תנאים ורשימות
+- איך להגיב לאירועים ולעדכן את המסך
+- איך לשתף נתונים בין קומפוננטות
</YouWillLearn>
-## Creating and nesting components {/*components*/}
+## יצירה וקינון של קומפוננטות {/*components*/}
-React apps are made out of *components*. A component is a piece of the UI (user interface) that has its own logic and appearance. A component can be as small as a button, or as large as an entire page.
+אפליקציות React בנויות מ-*קומפוננטות*. קומפוננטה היא חלק מה-UI (ממשק משתמש) שיש לו לוגיקה ומראה משל עצמו. קומפוננטה יכולה להיות קטנה כמו כפתור, או גדולה כמו עמוד שלם.
-React components are JavaScript functions that return markup:
+קומפוננטות React הן פונקציות JavaScript שמחזירות סימון (סימון):
```js
function MyButton() {
@@ -33,7 +33,7 @@ function MyButton() {
}
```
-Now that you've declared `MyButton`, you can nest it into another component:
+עכשיו אחרי שהגדרתם את `MyButton`, אפשר לקנן אותה בתוך קומפוננטה אחרת:
```js {5}
export default function MyApp() {
@@ -46,9 +46,9 @@ export default function MyApp() {
}
```
-Notice that `<MyButton />` starts with a capital letter. That's how you know it's a React component. React component names must always start with a capital letter, while HTML tags must be lowercase.
+שימו לב ש-`<MyButton />` מתחיל באות גדולה. כך מזהים קומפוננטת React. שמות קומפוננטות React חייבים להתחיל באות גדולות, בעוד שתגיות HTML חייבות להיות באותיות קטנות.
-Have a look at the result:
+הנה התוצאה:
<Sandpack>
@@ -73,13 +73,13 @@ export default function MyApp() {
</Sandpack>
-The `export default` keywords specify the main component in the file. If you're not familiar with some piece of JavaScript syntax, [MDN](https://developer.mozilla.org/en-US/docs/web/javascript/reference/statements/export) and [javascript.info](https://javascript.info/import-export) have great references.
+המילים `ייצוא ברית מחדל` מציינות את הקומפוננטה טפסים בקובץ. אם חלק מתחביר JavaScript לא מוכר לכם, ל-[MDN](https://developer.mozilla.org/en-US/docs/web/javascript/reference/statements/export) ול-[javascript.info](https://javascript.info/import-export) יש מקורות מעולים.
-## Writing markup with JSX {/*writing-markup-with-jsx*/}
+## כתיבת סימון עם JSX {/*writing-markup-with-jsx*/}
-The markup syntax you've seen above is called *JSX*. It is optional, but most React projects use JSX for its convenience. All of the [tools we recommend for local development](/learn/installation) support JSX out of the box.
+תחביר הסימון (סימון) שראיתם למעלה נקראת *JSX*. הוא אופציונלי, אבל רוב פרויקטי React users בו בגלל הנוחות שלו. כל [הכלים שאנו ממליצים עליהם לפיתוח מקומי](/learn/installation) תומך ב-JSX מהקופסה.
-JSX is stricter than HTML. You have to close tags like `<br />`. Your component also can't return multiple JSX tags. You have to wrap them into a shared parent, like a `<div>...</div>` or an empty `<>...</>` wrapper:
+JSX מחמיר יותר מ-HTML. צריך לסגור תגיות כמו `<br />`. הקומפוננטה שלכם גם לא יכולה להחזיר כמה תגיות JSX נפרדות. צריך לתת להם בהורה משותף, כמו ``<div>`...`</div>`` או עטיפה ריקה `<>...</>`:
```js {3,6}
function AboutPage() {
@@ -92,17 +92,17 @@ function AboutPage() {
}
```
-If you have a lot of HTML to port to JSX, you can use an [online converter.](https://transform.tools/html-to-jsx)
+אם יש לכם הרבה HTML להמיר ל-JSX, אפשר להשתמש ב-[ממיר אונליין](https://transform.tools/html-to-jsx).
-## Adding styles {/*adding-styles*/}
+## הוספת עיצובים {/*adding-styles*/}
-In React, you specify a CSS class with `className`. It works the same way as the HTML [`class`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/class) attribute:
+ב-React מגדירים מחלקת CSS בעזרת `className`. זה עובד כמו המאפיין [`class`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/class) של HTML:
```js
<img className="avatar" />
```
-Then you write the CSS rules for it in a separate CSS file:
+לאחר כותבים את כללי ה-CSS בקובץ CSS נפרד:
```css
/* In your CSS */
@@ -111,11 +111,11 @@ Then you write the CSS rules for it in a separate CSS file:
}
```
-React does not prescribe how you add CSS files. In the simplest case, you'll add a [`<link>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link) tag to your HTML. If you use a build tool or a framework, consult its documentation to learn how to add a CSS file to your project.
+תגובה לא מכתיבה איך להוסיף קובצי CSS. במקרה הפשוט ביותר, תגית [`<link>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link) ל-HTML. אם אתם משתמשים בכלי בנייה (כלי בנייה) או בפריימורק (מסגרת), בדקו בתיעוד שלהם איך להוסיף קובץ CSS לפרויקט.
-## Displaying data {/*displaying-data*/}
+## הצגת נתונים {/*displaying-data*/}
-JSX lets you put markup into JavaScript. Curly braces let you "escape back" into JavaScript so that you can embed some variable from your code and display it to the user. For example, this will display `user.name`:
+JSX יכול להכניס סימון (סימון) ל-JavaScript. סוגרים מסולסלים מאפשרים "לחזור" ל-JavaScript כדי להטמיע מהקוד ולהציג אותו למשתמש. לדוגמה, זה יציג את `user.name`:
```js {3}
return (
@@ -125,7 +125,7 @@ return (
);
```
-You can also "escape into JavaScript" from JSX attributes, but you have to use curly braces *instead of* quotes. For example, `className="avatar"` passes the `"avatar"` string as the CSS class, but `src={user.imageUrl}` reads the JavaScript `user.imageUrl` variable value, and then passes that value as the `src` attribute:
+אפשר גם "לברוח ל-JavaScript" מתוך מאפיינים JSX, אבל צריך להשתמש בסוגריים מסולסלים *במקום* מירכאות. למשל, `className="avatar"` מעביר את המחרוזת `"avatar"` כמחלקת CSS, אבל `src={user.imageUrl}` קורא את הערך של השינוי `user.imageUrl` ב-JavaScript, ואז מעביר אותו למאפיין `src`:
```js {3,4}
return (
@@ -136,7 +136,7 @@ return (
);
```
-You can put more complex expressions inside the JSX curly braces too, for example, [string concatenation](https://javascript.info/operators#string-concatenation-with-binary):
+אפשר לשים גם ביטויים מורכבים יותר סוגריים מסולסלים של JSX, למשל [שרשור מחרוזות](https://javascript.info/operators#string-concatenation-with-binary):
<Sandpack>
@@ -177,11 +177,11 @@ export default function Profile() {
</Sandpack>
-In the above example, `style={{}}` is not a special syntax, but a regular `{}` object inside the `style={ }` JSX curly braces. You can use the `style` attribute when your styles depend on JavaScript variables.
+בדוגמה למעלה, `style={{}}` הוא לא תחביר מיוחד, אלא אובייקט `{}` רגיל בתוך סוגריים מסולסלים של `style={ }` ב-JSX. אפשר להשתמש במאפיין `סגנון` עיצובים תלויים במשתני JavaScript.
-## Conditional rendering {/*conditional-rendering*/}
+## רינדור מותנה {/*עיבוד-מותנה*/}
-In React, there is no special syntax for writing conditions. Instead, you'll use the same techniques as you use when writing regular JavaScript code. For example, you can use an [`if`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/if...else) statement to conditionally include JSX:
+ב-React אין תחביר מיוחד לתנאי תנאי. במקום זה משתמשים באותן טכניקות של JavaScript רגיל. לדוגמה, אפשר להשתמש במשפט [`if`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/if...else) כדי לכלול את JSX בתנאי:
```js
let content;
@@ -197,7 +197,7 @@ return (
);
```
-If you prefer more compact code, you can use the [conditional `?` operator.](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator) Unlike `if`, it works inside JSX:
+אם מעדיפים קוד תמציתי יותר, אפשר להשתמש ב-[אופרטור תנאי `?`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator). צריך ל-`אם`, הוא עובד בתוך JSX:
```js
<div>
@@ -209,7 +209,7 @@ If you prefer more compact code, you can use the [conditional `?` operator.](htt
</div>
```
-When you don't need the `else` branch, you can also use a shorter [logical `&&` syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Logical_AND#short-circuit_evaluation):
+כשלא צריך ענף `else`, אפשר להשתמש גם בתחביר קצר של [אופרטור לוגי `&&`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Logical_AND#short-circuit_evaluation):
```js
<div>
@@ -217,13 +217,13 @@ When you don't need the `else` branch, you can also use a shorter [logical `&&`
</div>
```
-All of these approaches also work for conditionally specifying attributes. If you're unfamiliar with some of this JavaScript syntax, you can start by always using `if...else`.
+כל ההגישות האלה עובדות גם למנות של מאפיינים (תכונות). אם חלק מהתחביר הזה של JavaScript לא מוכר לכם, אפשר להתחיל תמיד עם `אם...אחר`.
-## Rendering lists {/*rendering-lists*/}
+## רינדור רשימות {/*רשימות-עיבוד*/}
-You will rely on JavaScript features like [`for` loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for) and the [array `map()` function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map) to render lists of components.
+תשתמשו ביכולות JavaScript כמו [`for` loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for) ופונקציית [מערך `map()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Ob/Global lists_Ob) קומספו/Global_Ob רשימות/Global_Ob רשימות.
-For example, let's say you have an array of products:
+לדוגמה, נניח שיש לכם מערך של מוצרים:
```js
const products = [
@@ -233,7 +233,7 @@ const products = [
];
```
-Inside your component, use the `map()` function to transform an array of products into an array of `<li>` items:
+בתוך הקומפוננטה, השתמשו ב-`map()` כדי ליצור עוד מוצרים למערך פריטי ``<li>``:
```js
const listItems = products.map(product =>
@@ -247,7 +247,7 @@ return (
);
```
-Notice how `<li>` has a `key` attribute. For each item in a list, you should pass a string or a number that uniquely identifies that item among its siblings. Usually, a key should be coming from your data, such as a database ID. React uses your keys to know what happened if you later insert, delete, or reorder the items.
+שימו לב של-``<li>`` יש מאפיין (תכונה) בשם `מפתח`. עבור כל פריט ברשימה, צריך להעביר מחרוזת או מספר שמזה את הפריט בצורה ייחודית לאחים שלו. בדרך כלל `מפתח` מגיע מהנתונים, כמו ID ממסד נתונים. React Usert ב-keys לדעת מה קרה אם ירצה עוד, מוחקים או שנים סדר של פריטים.
<Sandpack>
@@ -278,9 +278,9 @@ export default function ShoppingList() {
</Sandpack>
-## Responding to events {/*responding-to-events*/}
+## תגובה לאירועים {/*מגיבים-לאירועים*/}
-You can respond to events by declaring *event handler* functions inside your components:
+אפשר להגיב לאירועים על ידי הגדרת פונקציות *מטפל באירועים* בתוך הקומפוננטות:
```js {2-4,7}
function MyButton() {
@@ -296,19 +296,19 @@ function MyButton() {
}
```
-Notice how `onClick={handleClick}` has no parentheses at the end! Do not _call_ the event handler function: you only need to *pass it down*. React will call your event handler when the user clicks the button.
+שימו לב של-`onClick={handleClick}` אין סוגרים בסוף. אל _תקראו_ לפונקציית המטפל בעצמכם, צריך רק *להעביר אותה*. תגיב תקרא למטפל כשהמשתמש ילחץ על הכפתור.
-## Updating the screen {/*updating-the-screen*/}
+## עדכון המסך {/*עדכון-המסך*/}
-Often, you'll want your component to "remember" some information and display it. For example, maybe you want to count the number of times a button is clicked. To do this, add *state* to your component.
+לעתים קרובות תרצו שהקומפוננטה "תזכור" מידע ותציג אותו. למשל, אפשר לספור כמה פעמים נלחץ כפתור. כדי לעשות את זה, משתמשים ב-*state*.
-First, import [`useState`](/reference/react/useState) from React:
+קודם מייבאים את [`useState`](/reference/react/useState) מ-React:
```js
import { useState } from 'react';
```
-Now you can declare a *state variable* inside your component:
+עכשיו אפשר להגדיר משתנה `state` בתוך הקומפוננטה:
```js
function MyButton() {
@@ -316,9 +316,9 @@ function MyButton() {
// ...
```
-You’ll get two things from `useState`: the current state (`count`), and the function that lets you update it (`setCount`). You can give them any names, but the convention is to write `[something, setSomething]`.
+`useState` מחזיר שני דברים: ה-`state` הנוכחי (`count`) ופונקציה שמעדכנת אותו (`setCount`). אפשר לתת להם כל שם, אבל הקונבנציה היא `[משהו, setSomething]`.
-The first time the button is displayed, `count` will be `0` because you passed `0` to `useState()`. When you want to change state, call `setCount()` and pass the new value to it. Clicking this button will increment the counter:
+בפעם הראשונה שהכפתור מוצג, `count` יהיה `0` כי העברתם `0` ל-`useState()`. כשרוצים לשנות, קוראים ל-`setCount()` ומעבירים אליו את הערך החדש. לחיצה על הכפתור תגדיל את המונה:
```js {5}
function MyButton() {
@@ -336,9 +336,9 @@ function MyButton() {
}
```
-React will call your component function again. This time, `count` will be `1`. Then it will be `2`. And so on.
+תגובה תקרא לפונקציית הקומפוננטה שוב. הפעם `ספירה` תהיה `1`. אחר כך `2`, וכן הלאה.
-If you render the same component multiple times, each will get its own state. Click each button separately:
+אם מרנדרים את אותה קומפוננטה כמה פעמים, כל מופע יקבל `state` משלו. נסו ללחוץ על כל כפתור בנפרד:
<Sandpack>
@@ -379,59 +379,59 @@ button {
</Sandpack>
-Notice how each button "remembers" its own `count` state and doesn't affect other buttons.
+לב שכל כפתור "זוכר" את ה-`count` שלו, ולא משפיע על הכפתורים האחרים.
-## Using Hooks {/*using-hooks*/}
+## שימוש ב-Hooks {/*using-hooks*/}
-Functions starting with `use` are called *Hooks*. `useState` is a built-in Hook provided by React. You can find other built-in Hooks in the [API reference.](/reference/react) You can also write your own Hooks by combining the existing ones.
+לפונקציות שמתחילות ב-`use` קוראים *Hooks*. `useState` הוא Hook מובנה ש-React מספקת. אפשר למצוא Hooks מובנים נוספים ב-[מדריך ה-API](/reference/react). אפשר גם לכתוב Hooks משלכם על ידי שילוב Hooks קיימים.
-Hooks are more restrictive than other functions. You can only call Hooks *at the top* of your components (or other Hooks). If you want to use `useState` in a condition or a loop, extract a new component and put it there.
+ל-Hooks יש מגבלות מחמירות יותר מפונקציות אחרות. אפשר לקרוא ל-Hooks רק *בראש* הקומפוננטות (או Hooks אחרים). אם להשתמש ב-`useState` בתוך תנאי או לולאה, צריך לחלץ קומפוננטה חדשה ולהשתמש בו שם.
-## Sharing data between components {/*sharing-data-between-components*/}
+## שיתוף נתונים בין קומפוננטות {/*sharing-data-between-components*/}
-In the previous example, each `MyButton` had its own independent `count`, and when each button was clicked, only the `count` for the button clicked changed:
+בדוגמה הקודמת, לכל `MyButton` היה `count` עצמאי, וכשלחצו על כפתור רק ה-`count` של אותו כפתור השתנה:
<DiagramGroup>
-<Diagram name="sharing_data_child" height={367} width={407} alt="Diagram showing a tree of three components, one parent labeled MyApp and two children labeled MyButton. Both MyButton components contain a count with value zero.">
+<Diagram name="sharing_data_child" height={367} width={407} alt="תרשים שמציג עץ של שלוש קומפוננטות: הורה אחד בשם MyApp ושני ילדים בשם MyButton. שתי קומפוננטות MyButton מכילות count בערך אפס.">
-Initially, each `MyButton`'s `count` state is `0`
+בהתחלה, ה-`count` של כל `MyButton` הוא `0`
</Diagram>
-<Diagram name="sharing_data_child_clicked" height={367} width={407} alt="The same diagram as the previous, with the count of the first child MyButton component highlighted indicating a click with the count value incremented to one. The second MyButton component still contains value zero." >
+<Diagram name="sharing_data_child_clicked" height={367} width={407} alt="אותו תרשים כמו קודם, עם הדגשה על count של קומפוננטת MyButton הראשונה כדי לציין לחיצה שהגדילה את הערך לאחד. קומפוננטת MyButton השנייה עדיין בערך אפס." >
-The first `MyButton` updates its `count` to `1`
+ה-`MyButton` הראשון מעדכן את ה-`count` שלו ל-`1`
</Diagram>
</DiagramGroup>
-However, often you'll need components to *share data and always update together*.
+עם זאת, הרבה פעמים צריך שקומפוננטות *ישתפו נתונים ויתעדכנו יחד תמיד*.
-To make both `MyButton` components display the same `count` and update together, you need to move the state from the individual buttons "upwards" to the closest component containing all of them.
+כדי ששתי קומפוננטות `MyButton` יציגו את אותו `count` ויתעדכנו יחד, צריך להרים את ה-`state` מהכפתורים למעלה אל הקומפוננטה הקרובה שמכילה את שתיהן.
-In this example, it is `MyApp`:
+בדוגמה הזו זו `MyApp`:
<DiagramGroup>
-<Diagram name="sharing_data_parent" height={385} width={410} alt="Diagram showing a tree of three components, one parent labeled MyApp and two children labeled MyButton. MyApp contains a count value of zero which is passed down to both of the MyButton components, which also show value zero." >
+<Diagram name="sharing_data_parent" height={385} width={410} alt="תרשים שמציג עץ של שלוש קומפוננטות: הורה אחד בשם MyApp ושני ילדים בשם MyButton. ל-MyApp יש count בערך אפס שמועבר לשתי קומפוננטות MyButton, וגם הן מציגות ערך אפס." >
-Initially, `MyApp`'s `count` state is `0` and is passed down to both children
+בהתחלה, ה-`count` של `MyApp` הוא `0`, והוא מועבר לשני הילדים
</Diagram>
-<Diagram name="sharing_data_parent_clicked" height={385} width={410} alt="The same diagram as the previous, with the count of the parent MyApp component highlighted indicating a click with the value incremented to one. The flow to both of the children MyButton components is also highlighted, and the count value in each child is set to one indicating the value was passed down." >
+<Diagram name="sharing_data_parent_clicked" height={385} width={410} alt="אותו תרשים כמו קודם, עם הדגשה על count של קומפוננטת ההורה MyApp שמציינת לחיצה והגדלה של הערך לאחד. גם הזרימה לשתי קומפוננטות MyButton מודגשת, וערך ה-count בכל ילד מוגדר לאחד כדי להראות שהערך הועבר מלמעלה." >
-On click, `MyApp` updates its `count` state to `1` and passes it down to both children
+בלחיצה, `MyApp` מעדכנת את ה-`count` ל-`1` ומעבירה אותו לשני הילדים
</Diagram>
</DiagramGroup>
-Now when you click either button, the `count` in `MyApp` will change, which will change both of the counts in `MyButton`. Here's how you can express this in code.
+עכשיו, כשלוחצים על אחד הכפתורים, ה-`ספירה` ב-`MyApp` מסתובבת, וזה משנה את שני ה-counts בתוך `MyButton`. כך עושים את זה בקוד.
-First, *move the state up* from `MyButton` into `MyApp`:
+קודם *מעבירים את ה-state למעלה* מ-`MyButton` ל-`MyApp`:
```js {2-6,18}
export default function MyApp() {
@@ -456,7 +456,7 @@ function MyButton() {
```
-Then, *pass the state down* from `MyApp` to each `MyButton`, together with the shared click handler. You can pass information to `MyButton` using the JSX curly braces, just like you previously did with built-in tags like `<img>`:
+לאחר *מעבירים את ה-state למטה* מ-`MyApp` לכל `MyButton`, יחד עם מטפל בלחיצה משותף. אפשר להעביר מידע ל-`MyButton` באמצעות סוגריים מסולסלים ב-JSX, בדיוק כמו שעשינו קודם עם תגיות מובנות כמו ``<img>``:
```js {11-12}
export default function MyApp() {
@@ -476,9 +476,9 @@ export default function MyApp() {
}
```
-The information you pass down like this is called _props_. Now the `MyApp` component contains the `count` state and the `handleClick` event handler, and *passes both of them down as props* to each of the buttons.
+למידע שמעבירים כך קוראים _props_. עכשיו `MyApp` מחזיקה את ה-`state` בשם `count` ואת מטפל האירוע `handleClick`, ו-*מעבירה את שניהם כ-props* לכל אחד מהכפתורים.
-Finally, change `MyButton` to *read* the props you have passed from its parent component:
+לבסוף, משנים את `MyButton` כך ש-*תקרא* את ה-`props` שעברו מקומפוננטת ההורה שלה:
```js {1,3}
function MyButton({ count, onClick }) {
@@ -490,7 +490,7 @@ function MyButton({ count, onClick }) {
}
```
-When you click the button, the `onClick` handler fires. Each button's `onClick` prop was set to the `handleClick` function inside `MyApp`, so the code inside of it runs. That code calls `setCount(count + 1)`, incrementing the `count` state variable. The new `count` value is passed as a prop to each button, so they all show the new value. This is called "lifting state up". By moving state up, you've shared it between components.
+כשאתם לוחצים על כפתור, מטפל האירוע `onClick` מופעל. ה-prop `onClick` של כל כפתור מצביע לפונקציה `handleClick` בתוך `MyApp`, ולכן הקוד שלה רץ. הקוד הזה קורא ל-`setCount(count + 1)` ומעדכן את ה-`state` בשם `count`. הערך החדש של `count` מועבר כ-prop לכל כפתור, כך שכולם מציגים את אותו ערך. לזה קוראים "להרים state למעלה" (lifting state up).
<Sandpack>
@@ -531,8 +531,8 @@ button {
</Sandpack>
-## Next Steps {/*next-steps*/}
+## השלבים הבאים {/*next-steps*/}
-By now, you know the basics of how to write React code!
+הזה אתם כבר מכירים את היסודות של כתיבת קוד ב-React!
-Check out the [Tutorial](/learn/tutorial-tic-tac-toe) to put them into practice and build your first mini-app with React.
+עברו ל-[המדריך](/learn/tutorial-tic-tac-toe) כדי לתרגל ולבנות את המיני-אפליקציה הראשונה שלכם ב-React.
diff --git a/src/content/learn/installation.md b/src/content/learn/installation.md
index c5426ea94..85474e8e4 100644
--- a/src/content/learn/installation.md
+++ b/src/content/learn/installation.md
@@ -1,25 +1,25 @@
---
-title: Installation
+title: התקנה
---
<Intro>
-React has been designed from the start for gradual adoption. You can use as little or as much React as you need. Whether you want to get a taste of React, add some interactivity to an HTML page, or start a complex React-powered app, this section will help you get started.
+React תוכנה מלכתחילה לאימוץ הדרגתי. אפשר להשתמש במעט React או בהרבה React לפי הצורך. בין אם אתם רוצים טעימה מ-React, להוסיף אינטראקטיביות HTML, או להתחיל אפליקציה מורכבת להכנסת שמבוססת על React, החלק הזה יעזור לכם להתחיל.
</Intro>
<YouWillLearn isChapter={true}>
-* [How to start a new React project](/learn/start-a-new-react-project)
-* [How to add React to an existing project](/learn/add-react-to-an-existing-project)
-* [How to set up your editor](/learn/editor-setup)
-* [How to install React Developer Tools](/learn/react-developer-tools)
+* [איך מתחילים פרויקט React חדש](/learn/start-a-new-react-project)
+* [איך למצוא React לפרויקט ](/learn/add-react-to-an-existing-project)
+* [איך מגדירים את העורך](/learn/editor-setup)
+* [איך מתקינים React Developer Tools](/learn/react-developer-tools)
</YouWillLearn>
-## Try React {/*try-react*/}
+## נסו את React {/*try-react*/}
-You don't need to install anything to play with React. Try editing this sandbox!
+לא צריך להתקין שום דבר כדי להתנסות ב-React. נסו לערוך את סביבת העבודה הזו (ארגז חול)!
<Sandpack>
@@ -35,23 +35,22 @@ export default function App() {
</Sandpack>
-You can edit it directly or open it in a new tab by pressing the "Fork" button in the upper right corner.
+אפשר לערוך אותו או לפתוח אותו בלשונית חדשה דרך כפתור "פורק" שבפינה הימנית העליונה.
-Most pages in the React documentation contain sandboxes like this. Outside of the React documentation, there are many online sandboxes that support React: for example, [CodeSandbox](https://codesandbox.io/s/new), [StackBlitz](https://stackblitz.com/fork/react), or [CodePen.](https://codepen.io/pen?&editors=0010&layout=left&prefill_data_id=3f4569d1-1b11-4bce-bd46-89090eed5ddb)
+רוב העמודים בתיעוד של תגובה סביבות ארגז חול כאלה. מחוץ לתיעוד של React יש עוד הרבה סביבות מקוונות שתומכות ב-React, למשל [CodeSandbox](https://codesandbox.io/s/new), [StackBlitz](https://stackblitz.com/fork/react), או [CodePen.](https://codepen.io/pen?&editors=0010&layout=left&prefill_data_id=3f4569d1-1b11-4bce-bd46-89090eed5ddb)
-### Try React locally {/*try-react-locally*/}
+### נסו את React מקומית {/*try-react-locally*/}
-To try React locally on your computer, [download this HTML page.](https://gist.githubusercontent.com/gaearon/0275b1e1518599bbeafcde4722e79ed1/raw/db72dcbf3384ee1708c4a07d3be79860db04bff0/example.html) Open it in your editor and in your browser!
+כדי לנסות את הגיבו המקומית במחשב, [הורידו את דף ה-HTML הזה.](https://gist.githubusercontent.com/gaearon/0275b1e1518599bbeafcde4722e79ed1/raw/db72dcbf3384ee17083be40bdff) ובומפו פתחד.html בעורך
-## Start a new React project {/*start-a-new-react-project*/}
+## התחילו פרויקט React חדש {/*start-a-new-react-project*/}
-If you want to build an app or a website fully with React, [start a new React project.](/learn/start-a-new-react-project)
+אם אתם רוצים לבנות אפליקציה או אתר שמבוססים לגמרי על React, [התחילו פרויקט React חדש.](/learn/start-a-new-react-project)
-## Add React to an existing project {/*add-react-to-an-existing-project*/}
+## הוסיפו React לפרויקט קיים {/*add-react-to-an-existing-project*/}
-If want to try using React in your existing app or a website, [add React to an existing project.](/learn/add-react-to-an-existing-project)
+אם אתם רוצים לנסות להשתמש ב-React באפליקציה או באתר קיים, [הוסיפו React לפרויקט קיים.](/learn/add-react-to-an-existing-project)
-## Next steps {/*next-steps*/}
-
-Head to the [Quick Start](/learn) guide for a tour of the most important React concepts you will encounter every day.
+## השלבים הבאים {/*next-steps*/}
+עברו ביותר למדריך [התחלה מהירה](/learn) לסיור ברעיונות חשובים של React שתפגשו ביום-יום.
diff --git a/src/content/learn/javascript-in-jsx-with-curly-braces.md b/src/content/learn/javascript-in-jsx-with-curly-braces.md
index 736065b03..06b95f523 100644
--- a/src/content/learn/javascript-in-jsx-with-curly-braces.md
+++ b/src/content/learn/javascript-in-jsx-with-curly-braces.md
@@ -1,25 +1,25 @@
---
-title: JavaScript in JSX with Curly Braces
+title: "JavaScript ב-JSX עם סוגרים מסולסלים"
---
<Intro>
-JSX lets you write HTML-like markup inside a JavaScript file, keeping rendering logic and content in the same place. Sometimes you will want to add a little JavaScript logic or reference a dynamic property inside that markup. In this situation, you can use curly braces in your JSX to open a window to JavaScript.
+JSX יכול לכתוב סימון דמוי HTML בתוך קובץ JavaScript, תוך שמירה על רינדור ההיגיון והתוכן באותו מקום. לפעמים תרצה להוסיף קצת הגיון JavaScript או להתייחס למאפיין דינמי בתוך הסימון הזה. בstate זה, אתה יכול להשתמש בסוגים מסולסלים ב-JSX שלך כדי לפתוח את החלון ל-JavaScript.
</Intro>
<YouWillLearn>
-* How to pass strings with quotes
-* How to reference a JavaScript variable inside JSX with curly braces
-* How to call a JavaScript function inside JSX with curly braces
-* How to use a JavaScript object inside JSX with curly braces
+* איך להעביר מחרוזות עם מרכאות
+* בתוך איך תייחס לשינוי JavaScript JSX עם פלטה מסולסלת
+* איך לקרוא לפונקציית JavaScript בתוך JSX עם פלטה מסולסלת
+* איך להשתמש באובייקט בתוך JSX עם פלטה מסולסלת
</YouWillLearn>
-## Passing strings with quotes {/*passing-strings-with-quotes*/}
+## מחרוזות עוברות עם מרכאות {/*מעבר-מחרוזות-עם-מרכאות*/}
-When you want to pass a string attribute to JSX, you put it in single or double quotes:
+כאשר אתה רוצה להעביר תכונה מחרוזת ל-JSX, אתה במירכאות בודדות אותה או כפולות:
<Sandpack>
@@ -41,9 +41,9 @@ export default function Avatar() {
</Sandpack>
-Here, `"https://i.imgur.com/7vQD0fPs.jpg"` and `"Gregorio Y. Zara"` are being passed as strings.
+כאן, `"https://i.imgur.com/7vQD0fPs.jpg"` ו`"Gregorio Y. Zara"` מועברים כמחרוזות.
-But what if you want to dynamically specify the `src` or `alt` text? You could **use a value from JavaScript by replacing `"` and `"` with `{` and `}`**:
+אבל מה אם אתה רוצה לציין באופן דינמי את הטקסט 'src' או 'alt'? תוכל **להשתמש בערך מ-JavaScript על ידי החלפת `"` ו-`"` ב-`{` ו-`}`**:
<Sandpack>
@@ -67,11 +67,11 @@ export default function Avatar() {
</Sandpack>
-Notice the difference between `className="avatar"`, which specifies an `"avatar"` CSS class name that makes the image round, and `src={avatar}` that reads the value of the JavaScript variable called `avatar`. That's because curly braces let you work with JavaScript right there in your markup!
+שימו לב להבדל בין `className="avatar"`, המציין את שם מחלקה `"avatar"` שיוצר את התמונה עגולה, וכי הוא `src={avatar}` שקורא את הערך של מדרג JavaScript הנקרא `avatar`. למה היא צריכה לעבוד עם JavaScript ממש שם בסימון שלך!
-## Using curly braces: A window into the JavaScript world {/*using-curly-braces-a-window-into-the-javascript-world*/}
+## שימוש בפלטה מתולתת: חלון אל עולם ה-JavaScript {/*באמצעות-מתולתל-פלטה-חלון-לעולם-ה-javascript*/}
-JSX is a special way of writing JavaScript. That means it’s possible to use JavaScript inside it—with curly braces `{ }`. The example below first declares a name for the scientist, `name`, then embeds it with curly braces inside the `<h1>`:
+JSX היא דרך מיוחדת לכתיבת JavaScript. זה אומר שאפשר להשתמש ב-JavaScript בתוכו - עם סוגים מסולסלים `{ }`. הדוגמה שלהלן מכריזה תחילה על שם למדן, `שם`, והגיעה מטמיעה אותו בסוגריים מסולסלים בתוך ``<h1>``:
<Sandpack>
@@ -86,9 +86,9 @@ export default function TodoList() {
</Sandpack>
-Try changing the `name`'s value from `'Gregorio Y. Zara'` to `'Hedy Lamarr'`. See how the list title changes?
+נסה לשנות את הערך של ה`שם` מ``גרגוריו Y. Zara`` ל``הדי לאמאר``. ראה כיצד כותרת הרשימה?
-Any JavaScript expression will work between curly braces, including function calls like `formatDate()`:
+כל ביטוי JavaScript יעבוד בין סוגרים מסולסלים, כולל קריאות לפונקציות כמו `formatDate()`:
<Sandpack>
@@ -111,18 +111,18 @@ export default function TodoList() {
</Sandpack>
-### Where to use curly braces {/*where-to-use-curly-braces*/}
+### היכן להשתמש בפלטה מתולתלת {/*היכן-לשימוש-פלטה-מתולתלת*/}
-You can only use curly braces in two ways inside JSX:
+אתה יכול להשתמש בסוגרים מתולתלים רק בשתי דרכים בתוך JSX:
-1. **As text** directly inside a JSX tag: `<h1>{name}'s To Do List</h1>` works, but `<{tag}>Gregorio Y. Zara's To Do List</{tag}>` will not.
-2. **As attributes** immediately following the `=` sign: `src={avatar}` will read the `avatar` variable, but `src="{avatar}"` will pass the string `"{avatar}"`.
+1. **כטקסט** בתוך תג JSX: ``<h1>`{name}'s to Do List`</h1>`` עובד, אבל `<{tag}>רשימת המשימות של גרגוריו Y. Zara</{tag}>` לא.
+2. **כמאפיינים** מיד אחרי הסימן `=`: `src={avatar}` יקרא את השינוי `avatar`, אבל `src="{avatar}"` יעביר את המחרוזת `"{avatar}"`.
-## Using "double curlies": CSS and other objects in JSX {/*using-double-curlies-css-and-other-objects-in-jsx*/}
+## שימוש ב-"double curlies": CSS ואובייקטים אחרים ב-JSX {/*using-double-curlies-css-and-other-objects-in-jsx*/}
-In addition to strings, numbers, and other JavaScript expressions, you can even pass objects in JSX. Objects are also denoted with curly braces, like `{ name: "Hedy Lamarr", inventions: 5 }`. Therefore, to pass a JS object in JSX, you must wrap the object in another pair of curly braces: `person={{ name: "Hedy Lamarr", inventions: 5 }}`.
+בנוסף למחרוזות, מספרים וביטויי JavaScript אחרים, אתה יכול אפילו להעביר אובייקטים ב-JSX. אובייקטים מסומנים גם בסוגריים מסולסלים, כמו `{ שם: "הדי לאמאר", המצאות: 5 }`. לכן, כדי להעביר אובייקט JS ב-JSX, עליך לתת את האובייקט בזוג אחר של סוגי מתולתלים: `person={{ name: "Hedy Lamarr", המצאות: 5 }}`.
-You may see this with inline CSS styles in JSX. React does not require you to use inline styles (CSS classes work great for most cases). But when you need an inline style, you pass an object to the `style` attribute:
+אפשר שתראה זאת עם סגנונות CSS מוטבעים ב-JSX. תגיב לא מחייב אותך להשתמש בסגנונות מוטבעים (שיעורי CSS עובדים מצוין ברוב המקרים). אבל כאשר אתה צריך סגנון מוטבע, אתה מעביר אובייקט לתכונה 'סגנון':
<Sandpack>
@@ -148,9 +148,9 @@ ul { padding: 20px 20px 20px 40px; margin: 0; }
</Sandpack>
-Try changing the values of `backgroundColor` and `color`.
+נסה לשנות את הערכים של `צבע רקע` ו`צבע`.
-You can really see the JavaScript object inside the curly braces when you write it like this:
+אתה באמת יכול לראות את האובייקט ה-JavaScript בתוך הפלטה המתולתת כאשר אתה כותב את זה כך:
```js {2-5}
<ul style={
@@ -161,17 +161,17 @@ You can really see the JavaScript object inside the curly braces when you write
}>
```
-The next time you see `{{` and `}}` in JSX, know that it's nothing more than an object inside the JSX curlies!
+בפעם הבאה שתראה את `{{` ו-`}}` ב-JSX, זה לא יותר מאשר אובייקט בתוך ה-JSX curlies!
<Pitfall>
-Inline `style` properties are written in camelCase. For example, HTML `<ul style="background-color: black">` would be written as `<ul style={{ backgroundColor: 'black' }}>` in your component.
+מאפיינים `סגנון` מוטבעים כתובים ב-camelCase. לדוגמה, HTML `<ul style="background-color: black">` ייכתב לפי `<ul style={{ backgroundColor: 'black' }}>` ברכיב שלך.
</Pitfall>
-## More fun with JavaScript objects and curly braces {/*more-fun-with-javascript-objects-and-curly-braces*/}
+## יותר כיף עם אובייקטי JavaScript וסוגרים מסולסלים {/*יותר-כיף-עם-javascript-objects-and-curly-braces*/}
-You can move several expressions into one object, and reference them in your JSX inside curly braces:
+אתה יכול להעביר מספר ביטויים לתוך אובייקט אחד, ולהתייחס אליהם ב-JSX שלך בתוך סוגים מסולסלים:
<Sandpack>
@@ -211,7 +211,7 @@ body > div > div { padding: 20px; }
</Sandpack>
-In this example, the `person` JavaScript object contains a `name` string and a `theme` object:
+בדוגמה זו, אובייקט ה-JavaScript 'אדם' מכיל מחרוזת 'שם' ואובייקט 'נושא':
```js
const person = {
@@ -223,31 +223,31 @@ const person = {
};
```
-The component can use these values from `person` like so:
+הרכיב יכול להשתמש בערכים אלה מ'אדם' כך:
```js
<div style={person.theme}>
<h1>{person.name}'s Todos</h1>
```
-JSX is very minimal as a templating language because it lets you organize data and logic using JavaScript.
+JSX היא מינימלית מאוד כשפת תבניות שהיא מאפשרת לך לארגן נתונים והיגיון באמצעות JavaScript.
<Recap>
-Now you know almost everything about JSX:
+עכשיו אתה יודע כמעט הכל על JSX:
-* JSX attributes inside quotes are passed as strings.
-* Curly braces let you bring JavaScript logic and variables into your markup.
-* They work inside the JSX tag content or immediately after `=` in attributes.
-* `{{` and `}}` is not special syntax: it's a JavaScript object tucked inside JSX curly braces.
+* תכונות JSX בתוך מרכאות מועברות מחרוזות.
+* סוגרים מסולסלים מאפשרים לך להכניס לוגיקה ומשתנים של JavaScript לתוך הסימון שלך.
+* הם פועלים בתוך תוכן תג JSX או מיד אחרי `=` בתכונות.
+* `{{` ו`}}` אינו תחביר מיוחד: זהו חפץ תחוב בתוך סוגרים מסולסלים של JSX.
</Recap>
<Challenges>
-#### Fix the mistake {/*fix-the-mistake*/}
+#### תקן את הטעות {/*תקן-הטעות*/}
-This code crashes with an error saying `Objects are not valid as a React child`:
+קוד זה קורס עם שגיאה האומרת 'אובייקטים לא תקפים כילד תגובה':
<Sandpack>
@@ -287,15 +287,15 @@ body > div > div { padding: 20px; }
</Sandpack>
-Can you find the problem?
+האם אתה יכול למצוא את הבעיה?
<Hint>Look for what's inside the curly braces. Are we putting the right thing there?</Hint>
<Solution>
-This is happening because this example renders *an object itself* into the markup rather than a string: `<h1>{person}'s Todos</h1>` is trying to render the entire `person` object! Including raw objects as text content throws an error because React doesn't know how you want to display them.
+זה קורה בגלל שהדוגמה הזו מעבדת *אובייקט עצמו* בתוך הסימון ולא למחרוזת: ``<h1>`{person}'s Todos`</h1>`` מנסה לעבד את כל האובייקט `person`! הכללת אובייקטים גולמיים כתוכן טקסט זורק שגיאה מה ש-React לא יודע איך אתה רוצה להציג אותם.
-To fix it, replace `<h1>{person}'s Todos</h1>` with `<h1>{person.name}'s Todos</h1>`:
+כדי לתקן את זה, החלף את ``<h1>`המטלות של {person}`</h1>`` ב-``<h1>`{person.name}'s Todos`</h1>``:
<Sandpack>
@@ -337,9 +337,9 @@ body > div > div { padding: 20px; }
</Solution>
-#### Extract information into an object {/*extract-information-into-an-object*/}
+#### חילוץ מידע לתוך אובייקט {/*חלץ-מידע-לאובייקט*/}
-Extract the image URL into the `person` object.
+חלץ את כתובת האתר של התמונה לאובייקט 'אדם'.
<Sandpack>
@@ -381,7 +381,7 @@ body > div > div { padding: 20px; }
<Solution>
-Move the image URL into a property called `person.imageUrl` and read it from the `<img>` tag using the curlies:
+העבר את כתובת האתר של התמונה למאפיין בשם `person.imageUrl` וקרא אותו מהתג ``<img>`` באמצעות התלתלים:
<Sandpack>
@@ -424,13 +424,13 @@ body > div > div { padding: 20px; }
</Solution>
-#### Write an expression inside JSX curly braces {/*write-an-expression-inside-jsx-curly-braces*/}
+#### כתוב ביטוי בתוך סוגרים מתולתלים של JSX {/*כתוב-ביטוי-בפנים-jsx-מתולתל-פלטה*/}
-In the object below, the full image URL is split into four parts: base URL, `imageId`, `imageSize`, and file extension.
+באובייקט שלמטה, כתובת האתר המלאה של התמונה מפוצלת לארבעה חלקים: כתובת אתר בסיסית, `imageId`, `imageSize` וסיומת קובץ.
-We want the image URL to combine these attributes together: base URL (always `'https://i.imgur.com/'`), `imageId` (`'7vQD0fP'`), `imageSize` (`'s'`), and file extension (always `'.jpg'`). However, something is wrong with how the `<img>` tag specifies its `src`.
+אנו שכתובת ה-URL של התמונה תשלב את התכונות הללו: כתובת אתר בסיס (תמיד `'https://i.imgur.com/'`), `imageId` (`'7vQD0fP'`), `imageSize` (`'s'`), וסיומת קובץ (תמיד `'.jpg'`). עם זאת, משהו לא בסדר עם האופן שבו התג ``<img>`` מציין את `src` שלו.
-Can you fix it?
+אתה יכול לתקן את זה?
<Sandpack>
@@ -474,15 +474,15 @@ body > div > div { padding: 20px; }
</Sandpack>
-To check that your fix worked, try changing the value of `imageSize` to `'b'`. The image should resize after your edit.
+כדי לבדוק את התיקון שלך עבד, נסה לשנות את הערך של `imageSize` ל-`'b'`. התמונה צריכה לשנות את גודלה לאחר העריכה.
<Solution>
-You can write it as `src={baseUrl + person.imageId + person.imageSize + '.jpg'}`.
+אתה יכול לכתוב את זה בתור `src={baseUrl + person.imageId + person.imageSize + '.jpg'}`.
-1. `{` opens the JavaScript expression
-2. `baseUrl + person.imageId + person.imageSize + '.jpg'` produces the correct URL string
-3. `}` closes the JavaScript expression
+1. `{` פותח את הביטוי JavaScript
+2. `baseUrl + person.imageId + person.imageSize + '.jpg'` מייצרת את מחרוזת כתובת האתר הנכונה
+3. `}` סוגר את הביטוי JavaScript
<Sandpack>
@@ -525,7 +525,7 @@ body > div > div { padding: 20px; }
</Sandpack>
-You can also move this expression into a separate function like `getImageUrl` below:
+אתה יכול גם להעביר את הביטוי הזה לפונקציה נפרדת כמו `getImageUrl` למטה:
<Sandpack>
@@ -580,8 +580,9 @@ body > div > div { padding: 20px; }
</Sandpack>
-Variables and functions can help you keep the markup simple!
+משתנים ופונקציות יכולים לעזור לך לשמור על הסימון פשוט!
</Solution>
</Challenges>
+
diff --git a/src/content/learn/lifecycle-of-reactive-effects.md b/src/content/learn/lifecycle-of-reactive-effects.md
index 3dc9a75f0..7cdec4921 100644
--- a/src/content/learn/lifecycle-of-reactive-effects.md
+++ b/src/content/learn/lifecycle-of-reactive-effects.md
@@ -1,37 +1,37 @@
---
-title: 'Lifecycle of Reactive Effects'
+title: "מחזור החיים של אפקטים תגובתיים"
---
<Intro>
-Effects have a different lifecycle from components. Components may mount, update, or unmount. An Effect can only do two things: to start synchronizing something, and later to stop synchronizing it. This cycle can happen multiple times if your Effect depends on props and state that change over time. React provides a linter rule to check that you've specified your Effect's dependencies correctly. This keeps your Effect synchronized to the latest props and state.
+לאפקטים יש מחזור חיים. רכיבים רכיבים לעלות, לעד או לטעינה. אפקט יכול לעשות רק שני דברים: להתחיל לסנכרן משהו, ובהמשך להפסיק לסנכרן אותו. מחזור זה יכול לקרות מספר פעמים אם ההשפעה שלך תלויה בprops ובstates המשתנים עם הזמן. React מספק כלל linter כדי לבדוק את התלות של האפקט שלך בצורה נכונה. זה שומר על האפקט שלך מסונכרן עם הprops וstate העדכניים ביותר.
</Intro>
<YouWillLearn>
-- How an Effect's lifecycle is different from a component's lifecycle
-- How to think about each individual Effect in isolation
-- When your Effect needs to re-synchronize, and why
-- How your Effect's dependencies are determined
-- What it means for a value to be reactive
-- What an empty dependency array means
-- How React verifies your dependencies are correct with a linter
-- What to do when you disagree with the linter
+- כיצד מחזור החיים של אפקט שונה ממחזור החיים של רכיב
+- איך לחשוב על כל אפקט בנפרד
+- מתי האפקט שלך צריך לסנכרן מחדש, ומדוע
+- כיצד נקבעות התלות של האפקט שלך
+- מה המשמעות של ערך להיות תגובתי
+- מה המשמעות של מערך תלות ריק
+איך תגיב מוודא שהתלות שלך נכונות עם סרגל
+- מה לעשות כאשר אתה לא מסכים עם הלינטר
</YouWillLearn>
-## The lifecycle of an Effect {/*the-lifecycle-of-an-effect*/}
+## מחזור החיים של אפקט {/*מחזור-החיים-של-אפקט*/}
-Every React component goes through the same lifecycle:
+כל הרכיב של React עובר את אותו מחזור חיים:
-- A component _mounts_ when it's added to the screen.
-- A component _updates_ when it receives new props or state, usually in response to an interaction.
-- A component _unmounts_ when it's removed from the screen.
+- רכיב _מועלה_ כאשר הוא מתווסף למסך.
+- רכיב _מתעדכן_ כאשר הוא מקבל props או מצב חדשים, בדרך כלל בתגובה לאינטראקציה.
+- רכיב _מתבטל_ כאשר הוא מוסר מהמסך.
-**It's a good way to think about components, but _not_ about Effects.** Instead, try to think about each Effect independently from your component's lifecycle. An Effect describes how to [synchronize an external system](/learn/synchronizing-with-effects) to the current props and state. As your code changes, synchronization will need to happen more or less often.
+**זו דרך טובה לחשוב על רכיבים, אבל _לא_ על אפקטים.** במקום זאת, נסה לחשוב על כל אפקט באופן עצמאי ממחזור החיים של הרכיב שלך. אפקט מתאר כיצד [לסנכרן מערכת חיצונית](/ללמוד/סנכרון-עם-אפקטים) לprops ולstate הנוכחיים. ככל שהקוד שלך משתנה, הסנכרון יצטרך להתרחש לעתים קרובות יותר או פחות.
-To illustrate this point, consider this Effect connecting your component to a chat server:
+כדי להמחיש נקודה זו, שקול את האפקט הזה המחבר את הרכיב שלך לשרת צ'אט:
```js
const serverUrl = 'https://localhost:1234';
@@ -48,7 +48,7 @@ function ChatRoom({ roomId }) {
}
```
-Your Effect's body specifies how to **start synchronizing:**
+גוף האפקט שלך מציין כיצד **להתחיל לסנכרן:**
```js {2-3}
// ...
@@ -60,7 +60,7 @@ Your Effect's body specifies how to **start synchronizing:**
// ...
```
-The cleanup function returned by your Effect specifies how to **stop synchronizing:**
+פונקציית הניקוי המוחזרת מהאפקט שלך מציינת כיצד **להפסיק את הסנכרון:**
```js {5}
// ...
@@ -72,19 +72,19 @@ The cleanup function returned by your Effect specifies how to **stop synchronizi
// ...
```
-Intuitively, you might think that React would **start synchronizing** when your component mounts and **stop synchronizing** when your component unmounts. However, this is not the end of the story! Sometimes, it may also be necessary to **start and stop synchronizing multiple times** while the component remains mounted.
+באופן אינטואיטיבי, אתה יכול לחשוב ש-React **יתחיל לסנכרן** כאשר הרכיב שלך נטען ו**תפסיק לסנכרן** כאשר הרכיב שלך יתבטל. עם זאת, זה לא סוף הסיפור! לפעמים, ייתכן שיהיה צורך גם **להתחיל ולהיות את הסינכרון מספר פעמים** בזמן שהרכיב נשאר מותקן.
-Let's look at _why_ this is necessary, _when_ it happens, and _how_ you can control this behavior.
+בואו נסתכל על _למה_ זה הכרחי, _מתי_ זה קורה, ו_איך_ אתה יכול לשלוט בהתנהגות הזו.
<Note>
-Some Effects don't return a cleanup function at all. [More often than not,](/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development) you'll want to return one--but if you don't, React will behave as if you returned an empty cleanup function.
+חלק מהאפקטים לא מחזירים פונקציית ניקוי כללי. [לעתים קרובות יותר מאשר לא,](/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development) תרצה להחזיר אחד--אבל אם לא, תגיב תתנהג כאילו החזרת פונקציית ניקוי ריקה.
</Note>
-### Why synchronization may need to happen more than once {/*why-synchronization-may-need-to-happen-more-than-once*/}
+### מדוע ייתכן שהסנכרון צריך להתרחש יותר מפעם אחת {/*למה-למה-סנכרון-ייתכן-צריך-להתרחש-יותר-מפעם-אחת*/}
-Imagine this `ChatRoom` component receives a `roomId` prop that the user picks in a dropdown. Let's say that initially the user picks the `"general"` room as the `roomId`. Your app displays the `"general"` chat room:
+תא לעצמך שרכיב `ChatRoom` זה מקבל props `roomId` שהמשתמש בוחר בתפריט נפתח. נניח שבתחילה משתמש בוחר את החדר `"כללי"` בתור `roomId`. האפליקציה שלך מציגה את חדר הצ'אט `"כללי"`:
```js {3}
const serverUrl = 'https://localhost:1234';
@@ -95,7 +95,7 @@ function ChatRoom({ roomId /* "general" */ }) {
}
```
-After the UI is displayed, React will run your Effect to **start synchronizing.** It connects to the `"general"` room:
+לאחר הצגת ממשק משתמש, React יפעיל את האפקט שלך כדי **להתחיל לסנכרן.** הוא מתחבר לחדר `"כללי"`:
```js {3,4}
function ChatRoom({ roomId /* "general" */ }) {
@@ -109,9 +109,9 @@ function ChatRoom({ roomId /* "general" */ }) {
// ...
```
-So far, so good.
+עד כאן, כל כך טוב.
-Later, the user picks a different room in the dropdown (for example, `"travel"`). First, React will update the UI:
+מאוחר יותר, משתמש בוחר חדר אחר בתפריט הנפתח (לדוגמה, `"נסיעות"`). ראשית, הגיבו יעדכן את ממשק משתמש:
```js {1}
function ChatRoom({ roomId /* "travel" */ }) {
@@ -120,20 +120,20 @@ function ChatRoom({ roomId /* "travel" */ }) {
}
```
-Think about what should happen next. The user sees that `"travel"` is the selected chat room in the UI. However, the Effect that ran the last time is still connected to the `"general"` room. **The `roomId` prop has changed, so what your Effect did back then (connecting to the `"general"` room) no longer matches the UI.**
+תחשוב מה צריך לקרות אחר כך. משתמש רואה ש`"נסיעות"` הוא חדר הצ'אט הנבחר בממשק משתמש. עם זאת, האפקט שרץ בזמן הקודמת עדיין מחובר לחדר `"כללי"`. **props `roomId` השתנה, אז מה שהאפקט שלך עשה אז (התחברות לחדר `"כללי"`) כבר לא תואם למשק המשתמש.**
-At this point, you want React to do two things:
+בתוך זה, אתה רוצה ש-React תעשה שני דברים:
-1. Stop synchronizing with the old `roomId` (disconnect from the `"general"` room)
-2. Start synchronizing with the new `roomId` (connect to the `"travel"` room)
+1. הפסק לסנכרן עם `roomId` הישן (נתק מהחדר `"כללי"`)
+2. התחל לסנכרן עם `roomId` החדש (התחבר לחדר `"נסיעות"`)
-**Luckily, you've already taught React how to do both of these things!** Your Effect's body specifies how to start synchronizing, and your cleanup function specifies how to stop synchronizing. All that React needs to do now is to call them in the correct order and with the correct props and state. Let's see how exactly that happens.
+**למרבה המזל, כבר לימדת את React איך לעשות את שני הדברים האלה!** הגוף של האפקט שלך מציין איך להתחיל לסנכרן, ופונקציית הניקוי שלך מציינת איך להפסיק את הסנכרון. כל מה ש-React צריך לעשות עכשיו זה לקרוא להם נכון ועם הprops וstate הנכונים. בוא נראה בדיוק זה קורה.
-### How React re-synchronizes your Effect {/*how-react-re-synchronizes-your-effect*/}
+### איך מגיב מסנכרן מחדש את האפקט שלך {/*how-react-re-synchronizes-your-effect*/}
-Recall that your `ChatRoom` component has received a new value for its `roomId` prop. It used to be `"general"`, and now it is `"travel"`. React needs to re-synchronize your Effect to re-connect you to a different room.
+זכור שרכיב ה-ChatRoom שלך קיבל ערך חדש עבור ה-roomId שלו. פעם זה היה `"כללי"`, ועכשיו זה `"נסיעות"`. תגיב צריך לסנכרן מחדש את האפקט שלך כדי לחבר אותך מחדש לחדר אחר.
-To **stop synchronizing,** React will call the cleanup function that your Effect returned after connecting to the `"general"` room. Since `roomId` was `"general"`, the cleanup function disconnects from the `"general"` room:
+כדי **להפסיק לסנכרן,** תגובה תקרא לפונקציית הניקוי שהאפקט שלך החזיר לאחר התחברות לחדר `"כללי"`. מה ש-`roomId` היה `"כללי"`, פונקציית הניקוי מתנתקת מהחדר `"כללי"`:
```js {6}
function ChatRoom({ roomId /* "general" */ }) {
@@ -146,7 +146,7 @@ function ChatRoom({ roomId /* "general" */ }) {
// ...
```
-Then React will run the Effect that you've provided during this render. This time, `roomId` is `"travel"` so it will **start synchronizing** to the `"travel"` chat room (until its cleanup function is eventually called too):
+לאחר מכן, תגיב תריץ את האפקט שסיפקת על העיבוד הזה. הפעם, `roomId` `"travel"` כך שהוא **יתחיל להסתנכרן** לחדר הצ'אט `"travel"` (עד שפונקציית הניקוי שלו תיקרא בסוף דבר):
```js {3,4}
function ChatRoom({ roomId /* "travel" */ }) {
@@ -156,29 +156,29 @@ function ChatRoom({ roomId /* "travel" */ }) {
// ...
```
-Thanks to this, you're now connected to the same room that the user chose in the UI. Disaster averted!
+הודות לכך, אתה מחובר כעת לאותו חדר שהמשתמש בחר בממשק המשתמש. נמנע אסון!
-Every time after your component re-renders with a different `roomId`, your Effect will re-synchronize. For example, let's say the user changes `roomId` from `"travel"` to `"music"`. React will again **stop synchronizing** your Effect by calling its cleanup function (disconnecting you from the `"travel"` room). Then it will **start synchronizing** again by running its body with the new `roomId` prop (connecting you to the `"music"` room).
+בכל פעם לאחר שהרכיב שלך יוצג מחדש עם `roomId` אחר, האפקט שלך יסונכרן מחדש. לדוגמה, נניח שהמשתמש משנה את `roomId` מ`"travel"` ל`"music"`. תגיב שוב **תפסיק לסנכרן** את האפקט שלך על ידי קריאת פונקציית הניקוי שלו (תנתק אותך מחדר ה`"נסיעות"`). אז הוא **יתחיל לסנכרן** שוב על ידי הפעלת הגוף שלו עם props `roomId` החדש (חבר אותך לחדר `"מוזיקה").
-Finally, when the user goes to a different screen, `ChatRoom` unmounts. Now there is no need to stay connected at all. React will **stop synchronizing** your Effect one last time and disconnect you from the `"music"` chat room.
+לבסוף, כאשר המשתמש עובר למסך אחר, `ChatRoom` מתבטל. עכשיו אין צורך להישאר מחובר בכלל. תגיב **תפסיק לסנכרן** את האפקט שלך בפעם האחרונה ותנתק אותך מחדר הצ'אט `"מוזיקה"`.
-### Thinking from the Effect's perspective {/*thinking-from-the-effects-perspective*/}
+### חשיבה מנקודת המבט של האפקט {/*חשיבה-מנקודת-המבט-של-ההשפעות*/}
-Let's recap everything that's happened from the `ChatRoom` component's perspective:
+בואו נסכם את כל מה שקרה מנקודת המבט של רכיב ה-ChatRoom:
-1. `ChatRoom` mounted with `roomId` set to `"general"`
-1. `ChatRoom` updated with `roomId` set to `"travel"`
-1. `ChatRoom` updated with `roomId` set to `"music"`
-1. `ChatRoom` unmounted
+1. `ChatRoom` מותקן כאשר `roomId` מוגדר ל`"כללי"`
+1. `ChatRoom` עודכן עם `roomId` מוגדר ל`"נסיעות"`
+1. `ChatRoom` עודכן עם `roomId` מוגדר ל`"מוזיקה"`
+1. 'ChatRoom' בוטה
-During each of these points in the component's lifecycle, your Effect did different things:
+במהלך כל אחת מהנקודות הללו במחזור החיים של הרכיב, האפקט שלך עשה דברים שונים:
-1. Your Effect connected to the `"general"` room
-1. Your Effect disconnected from the `"general"` room and connected to the `"travel"` room
-1. Your Effect disconnected from the `"travel"` room and connected to the `"music"` room
-1. Your Effect disconnected from the `"music"` room
+1. האפקט שלך מחובר לחדר `"כללי"`
+1. האפקט שלך התנתק מהחדר `"כללי"` והתחבר לחדר `"נסיעות"`
+1. האפקט שלך התנתק מחדר `"נסיעות"` והתחבר לחדר `"מוזיקה"`
+1. האפקט שלך מנותק מחדר `"מוזיקה"`
-Now let's think about what happened from the perspective of the Effect itself:
+עכשיו בואו נחשוב על מה שקרה מנקודת המבט של האפקט עצמו:
```js
useEffect(() => {
@@ -192,21 +192,21 @@ Now let's think about what happened from the perspective of the Effect itself:
}, [roomId]);
```
-This code's structure might inspire you to see what happened as a sequence of non-overlapping time periods:
+המבנה של הקוד הזה עשוי לתת לך השראה לראות מה קרה כרצף של פרקי זמן שאינם חופפים:
-1. Your Effect connected to the `"general"` room (until it disconnected)
-1. Your Effect connected to the `"travel"` room (until it disconnected)
-1. Your Effect connected to the `"music"` room (until it disconnected)
+1. האפקט שלך התחבר לחדר `"כללי"` (עד שהוא התנתק)
+1. האפקט שלך התחבר לחדר `"נסיעות"` (עד שהוא התנתק)
+1. האפקט שלך התחבר לחדר `"מוזיקה"` (עד שהוא התנתק)
-Previously, you were thinking from the component's perspective. When you looked from the component's perspective, it was tempting to think of Effects as "callbacks" or "lifecycle events" that fire at a specific time like "after a render" or "before unmount". This way of thinking gets complicated very fast, so it's best to avoid.
+בעבר, חשבת מנקודת המבט של הרכיב. כשהסתכלת מנקודת המבט של הרכיב, זה היה מפתה לחשוב על אפקטים כעל "התקשרות חוזרת" או "אירועי מחזור חיים" שנורים בזמן מסוים כמו "לאחר עיבוד" או "לפני ביטול ההרכבה". צורת החשיבה הזו מסתבכת מהר מאוד, ולכן עדיף להימנע.
-**Instead, always focus on a single start/stop cycle at a time. It shouldn't matter whether a component is mounting, updating, or unmounting. All you need to do is to describe how to start synchronization and how to stop it. If you do it well, your Effect will be resilient to being started and stopped as many times as it's needed.**
+** במקום זאת, התמקד תמיד במחזור התחלה/עצירה בודד בכל פעם. אין זה משנה אם רכיב מותקן, מתעדכן או מבטל. כל מה שאתה צריך לעשות הוא לתאר כיצד להתחיל סנכרון וכיצד לעצור אותו. אם תעשה את זה טוב, האפקט שלך יהיה עמיד בפני הפעלה ועצירה כמה פעמים שיידרש.**
-This might remind you how you don't think whether a component is mounting or updating when you write the rendering logic that creates JSX. You describe what should be on the screen, and React [figures out the rest.](/learn/reacting-to-input-with-state)
+זה עשוי להאמין לך איך אתה לא אם רכיב מועלה או מתעדכן שאתה כותב את לוגיקת הרינדור יוצר JSX. אתה מתאר מה צריך להיות על המסך, ומגיב [מבין את השאר.](/learn/reacting-to-input-with-state)
-### How React verifies that your Effect can re-synchronize {/*how-react-verifies-that-your-effect-can-re-synchronize*/}
+### How React מאמת שהאפקט שלך יכול להסתנכרן מחדש {/*how-react-verifies-that-your-react-can-re-synchronize*/}
-Here is a live example that you can play with. Press "Open chat" to mount the `ChatRoom` component:
+הנה דוגמה חיה אתה צריך לשחק איתה. לחץ על "פתח צ'אט" כדי לטעון את הרכיב `ChatRoom`:
<Sandpack>
@@ -272,23 +272,23 @@ button { margin-left: 10px; }
</Sandpack>
-Notice that when the component mounts for the first time, you see three logs:
+שים לב שכאשר הרכיב נטען בפעם הראשונה, אתה רואה שלושה יומנים:
-1. `✅ Connecting to "general" room at https://localhost:1234...` *(development-only)*
-1. `❌ Disconnected from "general" room at https://localhost:1234.` *(development-only)*
-1. `✅ Connecting to "general" room at https://localhost:1234...`
+1. `✅ מתחבר לחדר "כללי" בכתובת https://localhost:1234...` *(לפיתוח בלבד)*
+1. `❌ מנותק מהחדר "כללי" בכתובת https://localhost:1234.` *(לפיתוח בלבד)*
+1. `✅ מתחבר לחדר "כללי" בכתובת https://localhost:1234...`
-The first two logs are development-only. In development, React always remounts each component once.
+שני היומנים הם הראשונים לפיתוח בלבד. בפיתוח, תגיב תמיד מחזיר כל רכיב פעם אחת.
-**React verifies that your Effect can re-synchronize by forcing it to do that immediately in development.** This might remind you of opening a door and closing it an extra time to check if the door lock works. React starts and stops your Effect one extra time in development to check [you've implemented its cleanup well.](/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development)
+**הגיב מאמת שהאפקט שלך יכול להסתנכרן מחדש על ידי אילוץ לעשות זאת מיד בפיתוח.** זה עשוי להזכיר לך לפתוח דלת ולסגור אותה פעם נוספת כדי לבדוק אם מנעול הדלת עובד. תגובה מתחילה ומפסיקה את האפקט שלך פעם נוספת בפיתוח כדי לבדוק [ישמת את הניקוי שלו היטב.](/למד/סנכרן-עם-אפקטים#איך- לטפל באפקט-ירי-פעמיים-בפיתוח)
-The main reason your Effect will re-synchronize in practice is if some data it uses has changed. In the sandbox above, change the selected chat room. Notice how, when the `roomId` changes, your Effect re-synchronizes.
+מהי התנהלות העבודה שלך. בארגז החול למעלה, שנה את חדר הצ'אט שנבחר. שים לב איך שלך, כאשר ה-'roomId' מתהפך, האפקט מסתנכרן מחדש.
-However, there are also more unusual cases in which re-synchronization is necessary. For example, try editing the `serverUrl` in the sandbox above while the chat is open. Notice how the Effect re-synchronizes in response to your edits to the code. In the future, React may add more features that rely on re-synchronization.
+עם זאת, יש גם מקרים חריגים יותר יש צורך בסנכרון מחדש. לדוגמה, נסה לערוך את `serverUrl` בארגז החול למעלה בזמן שהצ'אט פתוח. שימו לב איך האפקט מסתנכרן מחדש בתגובה לעריכות שלכם בקוד. אם אפשר, React עשויה להוסיף תכונות נוספות של הסנכרון מחדש.
-### How React knows that it needs to re-synchronize the Effect {/*how-react-knows-that-it-needs-to-re-synchronize-the-effect*/}
+### How React יודע שהוא צריך לסנכרן מחדש את האפקט {/*how-react-יודע-שצריך-לחדש-לסנכרן-את-האפקט*/}
-You might be wondering how React knew that your Effect needed to re-synchronize after `roomId` changes. It's because *you told React* that its code depends on `roomId` by including it in the [list of dependencies:](/learn/synchronizing-with-effects#step-2-specify-the-effect-dependencies)
+אולי אתה תוהה איך React ידע שהאפקט שלך צריך להסתנכרן מחדש לאחר שינויים ב-'roomId'. זה בגלל ש*אמרת ל-React* שהקוד שלו תלוי ב-'roomId' על ידי הכללתו ב-[רשימת התלות:](/learn/synchronizing-with-effects#step-2-specific-the-effect-dependencies)
```js {1,3,8}
function ChatRoom({ roomId }) { // The roomId prop may change over time
@@ -302,19 +302,19 @@ function ChatRoom({ roomId }) { // The roomId prop may change over time
// ...
```
-Here's how this works:
+הנה איך זה עובד:
-1. You knew `roomId` is a prop, which means it can change over time.
-2. You knew that your Effect reads `roomId` (so its logic depends on a value that may change later).
-3. This is why you specified it as your Effect's dependency (so that it re-synchronizes when `roomId` changes).
+1. ידעת ש'roomId' הוא props, מה שאומר שהוא יכול להשתנות עם הזמן.
+2. ידעת שהאפקט שלך קורא `roomId` (כך שהלוגיקה שלו תלויה בערך שעשוי להשתנות מאוחר יותר).
+3. אתה מחפש את זה בתור התלות של האפקט (כך שהוא יסונכרן מחדש כאשר `roomId` מתרוצץ).
-Every time after your component re-renders, React will look at the array of dependencies that you have passed. If any of the values in the array is different from the value at the same spot that you passed during the previous render, React will re-synchronize your Effect.
+בכל פעם לאחר עיבוד מחדש של הרכיב שלך, תגיב יסתכל על מערך התלות שעברו. אם אחד מהערכים במערך שונה מהערך בנקודה שעברה בעיבוד הקודם, תגיב יסנכרן מחדש את האפקט שלך.
-For example, if you passed `["general"]` during the initial render, and later you passed `["travel"]` during the next render, React will compare `"general"` and `"travel"`. These are different values (compared with [`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is)), so React will re-synchronize your Effect. On the other hand, if your component re-renders but `roomId` has not changed, your Effect will remain connected to the same room.
+לדוגמה, אם עברת את `["כללי"]`בהמשך הרנדור הראשוני, ובהמשך עברת את `["נסיעות"]`על הרינדור הבא, הגיבו ישווה את `"כללי"` ו`"נסיעות"`. אלו הם ערכים שונים (בהשוואה ל-[`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is)), אז React יסנכרן מחדש את האפקט שלך. מצד שני, אם הרכיב שלך מעבד מחדש אבל `roomId` לא השתנה, האפקט שלך יישאר מחובר לאותו החדר.
-### Each Effect represents a separate synchronization process {/*each-effect-represents-a-separate-synchronization-process*/}
+### כל אפקט מייצג תהליך סנכרון נפרד {/*כל-אפקט-מייצג-תהליך-סינכרון-נפרד*/}
-Resist adding unrelated logic to your Effect only because this logic needs to run at the same time as an Effect you already wrote. For example, let's say you want to send an analytics event when the user visits the room. You already have an Effect that depends on `roomId`, so you might feel tempted to add the analytics call there:
+הימנע מהוספת היגיון לא קשור לאפקט שלך רק בגלל שהלוגיקה הזו צריכה לפעול לפקודת כתבת. לדוגמה, אני רוצה לשלוח אירוע ניתוח כאשר אתה מבקר בחדר. כבר יש לך אפקט שתלוי ב-'roomId', אז אולי תתפתה להוסיף לשם את קריאת הניתוח:
```js {3}
function ChatRoom({ roomId }) {
@@ -330,7 +330,7 @@ function ChatRoom({ roomId }) {
}
```
-But imagine you later add another dependency to this Effect that needs to re-establish the connection. If this Effect re-synchronizes, it will also call `logVisit(roomId)` for the same room, which you did not intend. Logging the visit **is a separate process** from connecting. Write them as two separate Effects:
+אבל תארו לעצמכם שלאחר הוא תוסיפו תלות נוספות לאפקט הזה שצריכה ליצור מחדש את הקשר. אם אפקט זה יסונכרן מחדש, הוא יקרא גם `logVisit(roomId)` עבור אותו חדר, שלא התכוונת. רישום הביקור **הוא תהליך נפרד** מהחיבור. כתוב אותם כשני אפקטים נפרדים:
```js {2-4}
function ChatRoom({ roomId }) {
@@ -346,13 +346,13 @@ function ChatRoom({ roomId }) {
}
```
-**Each Effect in your code should represent a separate and independent synchronization process.**
+**כל אפקט בקוד שלך צריך לייצג תהליך סנכרון נפרד ובלתי תלוי.**
-In the above example, deleting one Effect wouldn’t break the other Effect's logic. This is a good indication that they synchronize different things, and so it made sense to split them up. On the other hand, if you split up a cohesive piece of logic into separate Effects, the code may look "cleaner" but will be [more difficult to maintain.](/learn/you-might-not-need-an-effect#chains-of-computations) This is why you should think whether the processes are same or separate, not whether the code looks cleaner.
+בדוגמה שלמעלה, מחיקת אפקט אחד לא תשבור את ההיגיון של האפקט השני. זו אינדיקציה טובה בגלל שהם מסנכרנים דברים שונים, זה היה הגיוני לפצל אותם. מצד שני, אם תפצל פיסת היגיון מגובשת לאפקטים נפרדים, הקוד עשוי להיראות "נקי" יותר אבל [קשה יותר לתחזוקה.](/learn/you-might-not-need-an-effect#chains-of-computations) אתה צריך לחשוב אם התהליכים האלה או נפרדים, לא אם הקוד נראה נקי יותר.
-## Effects "react" to reactive values {/*effects-react-to-reactive-values*/}
+## אפקטים "מגיבים" לערכים תגובתיים {/*effects-react-to-reactive-values*/}
-Your Effect reads two variables (`serverUrl` and `roomId`), but you only specified `roomId` as a dependency:
+האפקט שלך קורא שני משתנים (`serverUrl` ו-`roomId`), אך ציינת רק `roomId` כתלות:
```js {5,10}
const serverUrl = 'https://localhost:1234';
@@ -369,13 +369,13 @@ function ChatRoom({ roomId }) {
}
```
-Why doesn't `serverUrl` need to be a dependency?
+למה `serverUrl` לא צריך להיות תלות?
-This is because the `serverUrl` never changes due to a re-render. It's always the same no matter how many times the component re-renders and why. Since `serverUrl` never changes, it wouldn't make sense to specify it as a dependency. After all, dependencies only do something when they change over time!
+למה היא הסיבה ש-'serverUrl' לעולם לא מדרג עקב עיבוד מחדש. זה תמיד אותו הדבר, לא משנה כמה פעמים הרכיב יוצג מחדש ולמה. זה ש-'serverUrl' לעולם לא משתנה, לא יהיה הגיוני לציין זאת כתלות. אחרי הכל, תלות עושה משהו רק כשהן משתנות עם הזמן!
-On the other hand, `roomId` may be different on a re-render. **Props, state, and other values declared inside the component are _reactive_ because they're calculated during rendering and participate in the React data flow.**
+מצד שני, `roomId` עשוי להיות שונה בעיבוד מחדש. **props, מצב וערכים אחרים המוצהרים בתוך הרכיב הם _reactive_ מה שהם מחושבים על העיבוד והמשתתפים בזרימת יום של React.**
-If `serverUrl` was a state variable, it would be reactive. Reactive values must be included in dependencies:
+אם `serverUrl` היה משתנה מצב, הוא היה מגיב. ערכים תגובתיים חייבים להיכלל בתלות:
```js {2,5,10}
function ChatRoom({ roomId }) { // Props change over time
@@ -392,9 +392,9 @@ function ChatRoom({ roomId }) { // Props change over time
}
```
-By including `serverUrl` as a dependency, you ensure that the Effect re-synchronizes after it changes.
+על ידי הכללת 'serverUrl' כתלות, אתה מבטיח שהאפקט יסונכרן מחדש לאחר שהוא משתנה.
-Try changing the selected chat room or edit the server URL in this sandbox:
+נסה לשנות את חדר הצ'אט שנבחר או לערוך את כתובת האתר של השרת בארגז החול הזה:
<Sandpack>
@@ -468,11 +468,11 @@ button { margin-left: 10px; }
</Sandpack>
-Whenever you change a reactive value like `roomId` or `serverUrl`, the Effect re-connects to the chat server.
+בכל פעם שאתה משנה ערך תגובתי כמו `roomId` או `serverUrl`, האפקט מתחבר מחדש לשרת הצ'אט.
-### What an Effect with empty dependencies means {/*what-an-effect-with-empty-dependencies-means*/}
+### המשמעות של אפקט עם תלות ריקות {/*מה-משמעות-אפקט-עם-תלות-ריקות*/}
-What happens if you move both `serverUrl` and `roomId` outside the component?
+מה קורה אם אתה מעביר גם `serverUrl` וגם `roomId` מחוץ לרכיב?
```js {1,2}
const serverUrl = 'https://localhost:1234';
@@ -490,9 +490,9 @@ function ChatRoom() {
}
```
-Now your Effect's code does not use *any* reactive values, so its dependencies can be empty (`[]`).
+כעת הקוד של האפקט שלך אינו משתמש ב*שום* ערכים תגובתיים, ולכן התלות שלו יכולה להיות ריקות (`[]`).
-Thinking from the component's perspective, the empty `[]` dependency array means this Effect connects to the chat room only when the component mounts, and disconnects only when the component unmounts. (Keep in mind that React would still [re-synchronize it an extra time](#how-react-verifies-that-your-effect-can-re-synchronize) in development to stress-test your logic.)
+בחשיבה מנקודת המבט של הרכיב, מערך התלות הריק `[]` אומר שהאפקט הזה מתחבר לחדר הצ'אט רק כאשר הרכיב עולה, ומתנתק רק כאשר הרכיב מתנתק. (זכור ש-React עדיין [יסנכרן אותו שוב פעם נוספת](#how-react-verifies-that-your-react-can-re-synchronize) בפיתוח כדי לבחון את ההיגיון שלך.)
<Sandpack>
@@ -548,13 +548,13 @@ button { margin-left: 10px; }
</Sandpack>
-However, if you [think from the Effect's perspective,](#thinking-from-the-effects-perspective) you don't need to think about mounting and unmounting at all. What's important is you've specified what your Effect does to start and stop synchronizing. Today, it has no reactive dependencies. But if you ever want the user to change `roomId` or `serverUrl` over time (and they would become reactive), your Effect's code won't change. You will only need to add them to the dependencies.
+עם זאת, אם אתה [חושב מנקודת המבט של האפקט,](#חשיבה-מ-the-effects-perspective) אינך צריך לחשוב על הרכבה וביטול כללי. מה שחשוב הוא שציינת מה האפקט שלך עושה כדי להתחיל להפסיק את הסנכרון. כיום, אין לו תלות תגוית. אבל אם אי פעם תרצה שהמשתמש ישנה את `roomId` או `serverUrl` לאורך זמן (והם יהפכו לתגובתי), הקוד של האפקט שלך לא ישתנה. תצטרך רק להוסיף אותם לתלות.
-### All variables declared in the component body are reactive {/*all-variables-declared-in-the-component-body-are-reactive*/}
+### כל המשתנים המוצהרים בגוף הרכיב הם תגובתיים {/*כל-המשתנים-מוצהרים-בגוף-הרכיב-הם-ריאקטיביים*/}
-Props and state aren't the only reactive values. Values that you calculate from them are also reactive. If the props or state change, your component will re-render, and the values calculated from them will also change. This is why all variables from the component body used by the Effect should be in the Effect dependency list.
+props וstate הם לא הערכים התגובתיים היחידים. ערכים שאתה מחשב מהם הם גם ריאקטיביים. אם הprops או הstate ישתנו, הרכיב שלך יוצג מחדש, וגם הערכים המחושבים מהם ישתנו. זו הסיבה שכל המשתנים מגוף הרכיב המשמש את האפקט צריכים להיות ברשימת התלות של אפקט.
-Let's say that the user can pick a chat server in the dropdown, but they can also configure a default server in settings. Suppose you've already put the settings state in a [context](/learn/scaling-up-with-reducer-and-context) so you read the `settings` from that context. Now you calculate the `serverUrl` based on the selected server from props and the default server:
+נניח שהמשתמש יכול לבחור שרת צ'אט בתפריט הנפתח, אבל הוא יכול גם להגדיר שרת ברירת מחדל בהגדרות. נניח שמת את מצב ההגדרות ב-[הקשר](/learn/scaling-up-with-reducer-and-context) אז אתה קורא את ההגדרות' מהקשר זה. עכשיו אתה מחשב את ה-serverUrl על סמך השרת שנבחר מprops ושרת ברירת המחדל:
```js {3,5,10}
function ChatRoom({ roomId, selectedServerUrl }) { // roomId is reactive
@@ -571,29 +571,29 @@ function ChatRoom({ roomId, selectedServerUrl }) { // roomId is reactive
}
```
-In this example, `serverUrl` is not a prop or a state variable. It's a regular variable that you calculate during rendering. But it's calculated during rendering, so it can change due to a re-render. This is why it's reactive.
+בדוגמה זו, `serverUrl` אינו מאפין או שינוי מצב. זה משתנה רגיל שאתה מחשב את העיבוד. אבל זה מחושב על העיבוד, כך שהוא יכול להשתנות עקב עיבוד מחדש. אני חושב שהוא מגיב.
-**All values inside the component (including props, state, and variables in your component's body) are reactive. Any reactive value can change on a re-render, so you need to include reactive values as Effect's dependencies.**
+**כל הערכים בתוך הרכיב (כולל props, מצב ומשתנים בגוף הרכיב שלך) הם תגובתיים. כל ערך תגובתי יכול להשתנות בעיבוד מחדש, לכן עליך לכלול ערכים תגובתיים כתלות של אפקט.**
-In other words, Effects "react" to all values from the component body.
+במילים אחרות, אפקטים "מגיבים" לכל הערכים מגוף הרכיב.
<DeepDive>
-#### Can global or mutable values be dependencies? {/*can-global-or-mutable-values-be-dependencies*/}
+#### האם ערכים גלובליים או ניתנים לשינוי יכולים להיות תלות? {/*יכולות-גלובליות-או-שינוי-ערכים-להיות-תלות*/}
-Mutable values (including global variables) aren't reactive.
+ערכים הניתנים לשינוי (כולל משתנים גלובליים) אינם מגיבים.
-**A mutable value like [`location.pathname`](https://developer.mozilla.org/en-US/docs/Web/API/Location/pathname) can't be a dependency.** It's mutable, so it can change at any time completely outside of the React rendering data flow. Changing it wouldn't trigger a re-render of your component. Therefore, even if you specified it in the dependencies, React *wouldn't know* to re-synchronize the Effect when it changes. This also breaks the rules of React because reading mutable data during rendering (which is when you calculate the dependencies) breaks [purity of rendering.](/learn/keeping-components-pure) Instead, you should read and subscribe to an external mutable value with [`useSyncExternalStore`.](/learn/you-might-not-need-an-effect#subscribing-to-an-external-store)
+**ערך שינוי כמו [`location.pathname`](https://developer.mozilla.org/en-US/docs/Web/API/Location/pathname) לא יכול להיות תלות.** הוא יכול להשתנות, כך שהוא יכול להשתנות בכל עת מחוץ לזרימה של React. שינוי זה לא פעיל עיבוד מחדש של הרכיב שלך. לכן, גם אם ציינת את זה בהתלות, תגיב *לא ידע* לסנכרן מחדש את האפקט כאשר הוא משתנה. זה גם שובר את הכללים של הגיבו על שקריאת נתונים הניתנים לשינוי העיבוד (שזה כאשר אתה מחשב את התלות) שובר את [טוהר העיבוד.](/learn/keeping-components-pure) במקום זאת, עליך לקרוא ולהירשם לערך חיצוני לשינוי עם [`useSyncExternalStore`.](/learn/you-might-not-need-an-effect#subscribing-to-an-external-store)
-**A mutable value like [`ref.current`](/reference/react/useRef#reference) or things you read from it also can't be a dependency.** The ref object returned by `useRef` itself can be a dependency, but its `current` property is intentionally mutable. It lets you [keep track of something without triggering a re-render.](/learn/referencing-values-with-refs) But since changing it doesn't trigger a re-render, it's not a reactive value, and React won't know to re-run your Effect when it changes.
+**ערך ניתן לשינוי כמו [`ref.current`](/reference/react/useRef#reference) או שאתה קורא ממנו גם לא יכול להיות תלות.** דברים רפר שמוחזר על ידי `useRef` עצמו יכול להיות תלות, אבל המאפיין `current` הוא יכול לשינוי בכוונה. זה יכול לך להפעיל רינדור מחדש.](/learn/referencing-values-with-refs)
-As you'll learn below on this page, a linter will check for these issues automatically.
+כפי שתלמד להלן בדף זה, סרגל יבדוק בעיות אלו באופן אוטומטי.
</DeepDive>
-### React verifies that you specified every reactive value as a dependency {/*react-verifies-that-you-specified-every-reactive-value-as-a-dependency*/}
+### React מאמת שציינת כל ערך תגובתי כתלות {/*react-verifies-that-you-speed-every-reactive-value-as-a-dependency*/}
-If your linter is [configured for React,](/learn/editor-setup#linting) it will check that every reactive value used by your Effect's code is declared as its dependency. For example, this is a lint error because both `roomId` and `serverUrl` are reactive:
+אם ה-linter שלך הוא [מוגדר עבור React,](/learn/editor-setup#linting) הוא יבדוק שכל ערך תגובתי המשמש את הקוד של האפקט שלך מוכרז כתלות שלו. לדוגמה, זו שגיאת מוך זה גם `roomId` וגם `serverUrl` מגיבים:
<Sandpack>
@@ -667,9 +667,9 @@ button { margin-left: 10px; }
</Sandpack>
-This may look like a React error, but really React is pointing out a bug in your code. Both `roomId` and `serverUrl` may change over time, but you're forgetting to re-synchronize your Effect when they change. You will remain connected to the initial `roomId` and `serverUrl` even after the user picks different values in the UI.
+זה אולי נראה כמו שגיאת React, אבל באמת React מצביע על באג בקוד שלך. גם `roomId` וגם `serverUrl` משתלבות להשתנות עם הזמן, אבל אתה שוכח לסנכרן מחדש את האפקט שלך כשהם משתנים. אתה תישאר מחובר ל-'roomId' ו-'serverUrl' הראשוניים גם לאחר שהמשתמש יבחר ערכים שונים בממשק המשתמש.
-To fix the bug, follow the linter's suggestion to specify `roomId` and `serverUrl` as dependencies of your Effect:
+כדי לתקן את הבאג, עקוב אחר ההצעה של ה-linter כדי לציין `roomId` ו- `serverUrl` כתלות של האפקט שלך:
```js {9}
function ChatRoom({ roomId }) { // roomId is reactive
@@ -685,19 +685,19 @@ function ChatRoom({ roomId }) { // roomId is reactive
}
```
-Try this fix in the sandbox above. Verify that the linter error is gone, and the chat re-connects when needed.
+נסה את התיקון הזה בארגז החול למעלה. ודא ששגיאת ה-linter נעלמה, והצ'אט מתחבר מחדש בעת הצורך.
<Note>
-In some cases, React *knows* that a value never changes even though it's declared inside the component. For example, the [`set` function](/reference/react/useState#setstate) returned from `useState` and the ref object returned by [`useRef`](/reference/react/useRef) are *stable*--they are guaranteed to not change on a re-render. Stable values aren't reactive, so you may omit them from the list. Including them is allowed: they won't change, so it doesn't matter.
+אפשרות, תגובה *יודע* שערך לעולם לא משתנה למרות שהוא מוצהר בתוך הרכיב. לדוגמה, הפונקציה [`set`](/reference/react/useState#setstate) המוחזרת מ`useState` ואובייקט ref המוחזר על ידי [`useRef`](/reference/react/useRef) הם *יציבים*--מובטח שהם לא ישנו בעיבוד מחדש. ערכים יציבים אינם מגיבים, אז אתה יכול להשמיט אותם מהרשימה. לרבות אותם מותר: לא ישתנו, אז זה לא משנה.
</Note>
-### What to do when you don't want to re-synchronize {/*what-to-do-when-you-dont-want-to-re-synchronize*/}
+### מה לעשות כשאתה לא רוצה לסנכרן מחדש {/*מה-לעשות-כשאתה-אינך-רוצה-לסנכרן-מחדש*/}
-In the previous example, you've fixed the lint error by listing `roomId` and `serverUrl` as dependencies.
+בדוגמה הקודמת, תיקנת את שגיאת המוך על ידי רישום 'roomId' ו-'serverUrl' כתלות.
-**However, you could instead "prove" to the linter that these values aren't reactive values,** i.e. that they *can't* change as a result of a re-render. For example, if `serverUrl` and `roomId` don't depend on rendering and always have the same values, you can move them outside the component. Now they don't need to be dependencies:
+**עם זאת, אתה יכול במקום זאת "להוכיח" ל-Linter שערכים אלה הם ערכים תגוב,** כלומר שהם *לא יכולים* להשתנות כמו עיבוד מחדש. לדוגמה, אם `serverUrl` ו`roomId` אינם תלויים בעיבוד ותמיד יש להם ערכים, אתה יכול להעביר אותם מחוץ לרכיב. עכשיו הם לא צריכים להיות תלות:
```js {1,2,11}
const serverUrl = 'https://localhost:1234'; // serverUrl is not reactive
@@ -715,7 +715,7 @@ function ChatRoom() {
}
```
-You can also move them *inside the Effect.* They aren't calculated during rendering, so they're not reactive:
+אתה יכול גם להזיז אותם *בתוך האפקט.* הם לא מחושבים במהלך העיבוד, כך שהם לא מגיבים:
```js {3,4,10}
function ChatRoom() {
@@ -732,21 +732,21 @@ function ChatRoom() {
}
```
-**Effects are reactive blocks of code.** They re-synchronize when the values you read inside of them change. Unlike event handlers, which only run once per interaction, Effects run whenever synchronization is necessary.
+**אפקטים הם בלHooks תגובתיים של קוד.** הם מסתנכרנים מחדש כאשר הערכים שאתה קורא בתוכם משתנים. שלא כמו מטפלי אירועים, שפועלים רק פעם אחת בכל אינטראקציה, אפקטים פועלים בכל פעם שיש צורך בסנכרון.
-**You can't "choose" your dependencies.** Your dependencies must include every [reactive value](#all-variables-declared-in-the-component-body-are-reactive) you read in the Effect. The linter enforces this. Sometimes this may lead to problems like infinite loops and to your Effect re-synchronizing too often. Don't fix these problems by suppressing the linter! Here's what to try instead:
+**אתה לא יכול "לבחור" את התלות שלך.** התלות שלך חייבת לכלול את כל [ערך תגובתי](#all-variables-declared-in-the-component-body-are-reactive) אתה קורא באפקט. הליטר אוכף את זה. לפעמים זה יכול להוביל לבעיות כמו אינסופיות ולסנכרון מחדש של האפקט שלך בטווח מדי. אל תתקן את הבעיות הללו על ידי דיכוי ה-linter! הנה מה לנסות במקום:
-* **Check that your Effect represents an independent synchronization process.** If your Effect doesn't synchronize anything, [it might be unnecessary.](/learn/you-might-not-need-an-effect) If it synchronizes several independent things, [split it up.](#each-effect-represents-a-separate-synchronization-process)
+* **בדוק שהאפקט שלך מייצג לעבוד סנכרון עצמאי.** אם האפקט שלך לא מסנכרן שום דבר, [ייתכן שהוא מיותר.](/learn/you-might-not-need-an-effect) אם הוא מסנכרן מספר דברים עצמאיים, [פיצול אותו.](#each-effect-represents-synchronization-a-separate-)
-* **If you want to read the latest value of props or state without "reacting" to it and re-synchronizing the Effect,** you can split your Effect into a reactive part (which you'll keep in the Effect) and a non-reactive part (which you'll extract into something called an _Effect Event_). [Read about separating Events from Effects.](/learn/separating-events-from-effects)
+* **אם אתה רוצה לקרוא את הערך העדכני של props או מצב מצב "להגיב" אליו ולסנכרן מחדש את האפקט,** אתה יכול לפצל את האפקט שלך לחלק תגובתי (שאותו תשמור באפקט) וחלק לא תגובתי (שאותו תחלץ למשהו שנקרא _Effect Event_). [קרא על הפרדת אירועים מהאפקטים.](/learn/separating-events-from-effects)
-* **Avoid relying on objects and functions as dependencies.** If you create objects and functions during rendering and then read them from an Effect, they will be different on every render. This will cause your Effect to re-synchronize every time. [Read more about removing unnecessary dependencies from Effects.](/learn/removing-effect-dependencies)
+* **הימנע מהסתמכות על אובייקטים ופונקציות כתלות.** אם אתה יוצר אובייקטים ופונקציות העיבוד הוא קורא אותם מאפקט, הם יהיו שונים בכל עיבוד. זה יגרום לאפקט שלך להסתנכרן מחדש בכל פעם. [קרא עוד על הסרת תלות מיותרת מ- Effects.](/learn/removing-effect-dependencies)
<Pitfall>
-The linter is your friend, but its powers are limited. The linter only knows when the dependencies are *wrong*. It doesn't know *the best* way to solve each case. If the linter suggests a dependency, but adding it causes a loop, it doesn't mean the linter should be ignored. You need to change the code inside (or outside) the Effect so that that value isn't reactive and doesn't *need* to be a dependency.
+ה-Linter הוא חבר שלך, אבל כוחותיו מוגבלים. ה-לינטר יודע רק מתי התלות *שגויה*. הוא לא יודע הדרך *הכי טובה* לפתור את כל המקרה. אם ה-linter מציע תלות, אבל הוספה שלו גורמת ללולאה, זה לא אומר להתעלם מה-linter. אתה צריך לשנות את הקוד בתוך (או מחוץ) האפקט כך שהערך הזה לא יהיה תגובתי ולא *צריך* להיות תלות.
-If you have an existing codebase, you might have some Effects that suppress the linter like this:
+אם יש לך בסיס קוד קיים, אולי יהיו לך כמה אפקטים שמדכאים את ה-linter כך:
```js {3-4}
useEffect(() => {
@@ -756,34 +756,34 @@ useEffect(() => {
}, []);
```
-On the [next](/learn/separating-events-from-effects) [pages](/learn/removing-effect-dependencies), you'll learn how to fix this code without breaking the rules. It's always worth fixing!
+ב-[הבא](/learn/separating-events-from-effects) [pages](/learn/removing-effect-dependencies), תלמד כיצד לתקן את הקוד הזה לבד לשבור את הכללים. תמיד כדאי לתקן!
</Pitfall>
<Recap>
-- Components can mount, update, and unmount.
-- Each Effect has a separate lifecycle from the surrounding component.
-- Each Effect describes a separate synchronization process that can *start* and *stop*.
-- When you write and read Effects, think from each individual Effect's perspective (how to start and stop synchronization) rather than from the component's perspective (how it mounts, updates, or unmounts).
-- Values declared inside the component body are "reactive".
-- Reactive values should re-synchronize the Effect because they can change over time.
-- The linter verifies that all reactive values used inside the Effect are specified as dependencies.
-- All errors flagged by the linter are legitimate. There's always a way to fix the code to not break the rules.
+- רכיבים יכולים לעלות, לעדכן ולבטל את הטעינה.
+- לכל אפקט יש מחזור חיים נפרד מהרכיב שמסביב.
+- כל אפקט מתאר תהליך סנכרון נפרד שיכול *להתחיל* ו*להפסיק*.
+- כשאתה כותב וקורא אפקטים, חשבו מנקודת המבט של כל אפקט בנפרד (איך להתחיל ולהפסיק את הסנכרון) ולא מנקודת המבט של הרכיב (איך הוא נטען, מתעדכן או מבטל).
+- ערכים המוצהרים בתוך גוף הרכיב הם "ריאקטיביים".
+- ערכים ריאקטיביים צריכים לסנכרן מחדש את האפקט מכיוון שהם יכולים להשתנות עם הזמן.
+- ה-Linter מוודא שכל הערכים התגובתיים המשמשים בתוך האפקט מצוינים כתלות.
+- כל השגיאות המסומנות על ידי ה-linter הן לגיטימיות. תמיד יש דרך לתקן את הקוד כדי לא לשבור את הכללים.
</Recap>
<Challenges>
-#### Fix reconnecting on every keystroke {/*fix-reconnecting-on-every-keystroke*/}
+#### תיקון חיבור מחדש בכל הקשה {/*תיקון-חיבור-מחדש-בכל-הקשה*/}
-In this example, the `ChatRoom` component connects to the chat room when the component mounts, disconnects when it unmounts, and reconnects when you select a different chat room. This behavior is correct, so you need to keep it working.
+בדוגמה זו, רכיב `ChatRoom` מתחבר לחדר הצ'אט כאשר הרכיב עולה, מתנתק כאשר הוא מתנתק ומתחבר מחדש כאשר אתה בוחר חדר צ'אט אחר. התנהגות זו נכונה, אז אתה צריך להמשיך לעבוד.
-However, there is a problem. Whenever you type into the message box input at the bottom, `ChatRoom` *also* reconnects to the chat. (You can notice this by clearing the console and typing into the input.) Fix the issue so that this doesn't happen.
+עם זאת, יש בעיה. בכל פעם שאתה מקליד בתיבת ההודעה בתחתית, `ChatRoom` *גם* מתחבר מחדש לצ'אט. (תוכל להבחין עם על ידי ניקוי המסוף והקלדה בקלט.) תקן את הבעיה כך שזה לא יקרה.
<Hint>
-You might need to add a dependency array for this Effect. What dependencies should be there?
+ייתכן שיהיה עליך להוסיף מערך תלות עבור אפקט זה. אילו תלות צריכות להיות שם?
</Hint>
@@ -860,7 +860,7 @@ button { margin-left: 10px; }
<Solution>
-This Effect didn't have a dependency array at all, so it re-synchronized after every re-render. First, add a dependency array. Then, make sure that every reactive value used by the Effect is specified in the array. For example, `roomId` is reactive (because it's a prop), so it should be included in the array. This ensures that when the user selects a different room, the chat reconnects. On the other hand, `serverUrl` is defined outside the component. This is why it doesn't need to be in the array.
+לאפקט הזה לא היה מערך תלות בכלל, אז הוא הסתנכרן מחדש אחרי כל רינדור מחדש. ראשית, הוסף מערך תלות. לאחר מכן, ודא שכל ערך תגובתי המשמש את האפקט מצוין במערך. לדוגמה, `roomId` הוא תגובתי (בגלל שהוא props), אז יש לכלול אותו במערך. זה מבטיח שכאשר משתמש בוחר חדר אחר, הצ'אט מתחבר מחדש. מצד שני, `serverUrl` מוגדר מחוץ לרכיב. למה אני לא צריך להיות במערך.
<Sandpack>
@@ -935,15 +935,15 @@ button { margin-left: 10px; }
</Solution>
-#### Switch synchronization on and off {/*switch-synchronization-on-and-off*/}
+#### הפעל וכיבוי הסנכרון {/*הפעל-וכיבוי-סנכרון*/}
-In this example, an Effect subscribes to the window [`pointermove`](https://developer.mozilla.org/en-US/docs/Web/API/Element/pointermove_event) event to move a pink dot on the screen. Try hovering over the preview area (or touching the screen if you're on a mobile device), and see how the pink dot follows your movement.
+בדוגמה זו, אפקט נרשם לאירוע החלון [`pointermove`](https://developer.mozilla.org/en-US/docs/Web/API/Element/pointermove_event) כדי להזיז נקודה ורודה על המסך. נסה לרחף מעל אזור התצוגה המקדימה (או לגעת במסך אם אתה במכשיר נייד), וראה כיצד הנקודה הוורודה עוקבת אחר התנועה.
-There is also a checkbox. Ticking the checkbox toggles the `canMove` state variable, but this state variable is not used anywhere in the code. Your task is to change the code so that when `canMove` is `false` (the checkbox is ticked off), the dot should stop moving. After you toggle the checkbox back on (and set `canMove` to `true`), the box should follow the movement again. In other words, whether the dot can move or not should stay synchronized to whether the checkbox is checked.
+יש גם תיבת סימון. סימון תיבת הסימון מפעיל את מצב הstate `canMove`, אך מדרג מצב זה אינו בשימוש בשום מקום בקוד. המשימה היא שלך לשנות את הקוד כך שכאשר `canMove` הוא `false` (תיבת הסימון מסומנת), הנקודה צריכה להפסיק לזוז. לאחר שתפעיל מחדש את תיבת הסימון (ותגדיר את 'canMove' ל'true'), התיבה אמורה לעקוב שוב אחר התנועה. במילים אחרות, האם הנקודה יכולה לזוז או לא צריכה להישאר מסונכרנת אם תיבת הסימון מסומנת.
<Hint>
-You can't declare an Effect conditionally. However, the code inside the Effect can use conditions!
+אתה לא יכול להכריז על אפקט באופן מותנה. עם זאת, הקוד בתוך האפקט יכול להשתמש בתנאים!
</Hint>
@@ -1001,7 +1001,7 @@ body {
<Solution>
-One solution is to wrap the `setPosition` call into an `if (canMove) { ... }` condition:
+פתרון אחד הוא לטוף את הקריאה `setPosition` מצב `if (canMove) { ... }`:
<Sandpack>
@@ -1057,7 +1057,7 @@ body {
</Sandpack>
-Alternatively, you could wrap the *event subscription* logic into an `if (canMove) { ... }` condition:
+לחלופין, תוכל לתת את ההיגיון של *מנוי לאירוע* בתנאי `if (canMove) { ... }`:
<Sandpack>
@@ -1113,19 +1113,19 @@ body {
</Sandpack>
-In both of these cases, `canMove` is a reactive variable that you read inside the Effect. This is why it must be specified in the list of Effect dependencies. This ensures that the Effect re-synchronizes after every change to its value.
+בשני המקרים, `canMove` הוא מחליף תגובתי שאתה קורא בתוך האפקט. יש לציין אותו ברשימת התלות של אפקט. זה מבטיח שהאפקט יסנכרן מחדש לאחר כל שינוי בערך שלו.
</Solution>
-#### Investigate a stale value bug {/*investigate-a-stale-value-bug*/}
+#### חקור באג עם ערך מיושן {/*investigate-a-stale-value-bug*/}
-In this example, the pink dot should move when the checkbox is on, and should stop moving when the checkbox is off. The logic for this has already been implemented: the `handleMove` event handler checks the `canMove` state variable.
+בדוגמה זו, הנקודה הוורודה צריכה לזוז כאשר תיבת הסימון מופעלת, ועליה להפסיק לזוז כאשר תיבת הסימון כבויה. ההיגיון לכך כבר יושם: המטפל באירוע `handleMove` בודק את סדר הstate `canMove`.
-However, for some reason, the `canMove` state variable inside `handleMove` appears to be "stale": it's always `true`, even after you tick off the checkbox. How is this possible? Find the mistake in the code and fix it.
+עם זאת, מסיבה כלשהי, מדרג את הstate `canMove` בתוך `handleMove` נראה "מיושן": הוא תמיד `נכון`, גם לאחר סימון תיבת הסימון. איך זה אפשרי? מצא את הטעות בקוד ותקן אותה.
<Hint>
-If you see a linter rule being suppressed, remove the suppression! That's where the mistakes usually are.
+אם אתה רואה חוק מדוכא, הסר את הדיכוי! שם נמצאות הטעויות בדרך כלל.
</Hint>
@@ -1187,13 +1187,13 @@ body {
<Solution>
-The problem with the original code was suppressing the dependency linter. If you remove the suppression, you'll see that this Effect depends on the `handleMove` function. This makes sense: `handleMove` is declared inside the component body, which makes it a reactive value. Every reactive value must be specified as a dependency, or it can potentially get stale over time!
+הבעיה עם הקוד המקורי הייתה דיכוי ה-dependency linter. אם תסיר את הדיכוי, תראה שהאפקט הזה תלוי בפונקציה 'handleMove'. זה הגיוני: `handleMove` מוצהר בתוך גוף הרכיב, מה שהופך אותו לערך תגובתי. כל ערך תגובתי חייב להיות מוגדר כתלות, אחרת הוא להתייאש עם הזמן!
-The author of the original code has "lied" to React by saying that the Effect does not depend (`[]`) on any reactive values. This is why React did not re-synchronize the Effect after `canMove` has changed (and `handleMove` with it). Because React did not re-synchronize the Effect, the `handleMove` attached as a listener is the `handleMove` function created during the initial render. During the initial render, `canMove` was `true`, which is why `handleMove` from the initial render will forever see that value.
+מחבר הקוד המקורי "שיקר" ל-React באומרו שהאפקט אינו תלוי (`[]`) בערכים תגובתיים כלשהם. זה מה ש-React לא סינכרן מחדש את האפקט לאחר ש-'canMove' השתנה (ו-'handleMove' איתו). איך ש-React לא סינכרן מחדש את האפקט, ה-'handleMove' המצורף כמאזין הוא הפונקציה 'handleMove' בשימוש העיבוד הראשוני. על העיבוד הראשוני, `canMove` היה `נכון`, וזוהי ש`handleMove` מהרינדור הראשוני יראה לנצח את הערך הזה.
-**If you never suppress the linter, you will never see problems with stale values.** There are a few different ways to solve this bug, but you should always start by removing the linter suppression. Then change the code to fix the lint error.
+**אם לעולם לא תדחיק את ה-linter, לעולם לא תראה בעיות עם ערכים מיושנים.** יש כמה דרכים שונות לפתור את הבאג הזה, אבל תמיד כדאי להתחיל בהסרת ה-linter. לאחר שנה את הקוד כדי לתקן את שגיאת המוך.
-You can change the Effect dependencies to `[handleMove]`, but since it's going to be a newly defined function for every render, you might as well remove dependencies array altogether. Then the Effect *will* re-synchronize after every re-render:
+אתה יכול לשנות את התלות של אפקט ל-`[handleMove]`, אבל אתה יכול לשנות את ההגדרה של כל רינדור. ואז האפקט *יסנכרן* מחדש אחרי כל רינדור מחדש:
<Sandpack>
@@ -1250,9 +1250,9 @@ body {
</Sandpack>
-This solution works, but it's not ideal. If you put `console.log('Resubscribing')` inside the Effect, you'll notice that it resubscribes after every re-render. Resubscribing is fast, but it would still be nice to avoid doing it so often.
+הפתרון הזה עובד, אבל הוא לא אידיאלי. אם תכניס את `console.log('Resubscribing')` בתוך האפקט, תבחין שהוא נרשם מחדש לאחר כל עיבוד מחדש. ההרשמה מחדש מהירה, אבל היא תהיה נחמדה.
-A better fix would be to move the `handleMove` function *inside* the Effect. Then `handleMove` won't be a reactive value, and so your Effect won't depend on a function. Instead, it will need to depend on `canMove` which your code now reads from inside the Effect. This matches the behavior you wanted, since your Effect will now stay synchronized with the value of `canMove`:
+תיקון טוב יותר יהיה להעביר את הפונקציה 'handleMove' *בתוך* האפקט. אז `handleMove` לא יהיה ערך תגובתי, זה האפקט שלך לא יהיה תלוי בפונקציה. במקום זאת, זה יצטרך להיות תלוי ב-'canMove' שהקוד שלך קורא עכשיו מתוך האפקט. זה תואם הכרחי שרצית, מה שהאפקט שלך יישאר מסונן עכשיו עם הערך של `canMove`:
<Sandpack>
@@ -1309,21 +1309,21 @@ body {
</Sandpack>
-Try adding `console.log('Resubscribing')` inside the Effect body and notice that now it only resubscribes when you toggle the checkbox (`canMove` changes) or edit the code. This makes it better than the previous approach that always resubscribed.
+נסה להוסיף `console.log('Resubscribing')` בתוך גוף האפקט ושימו לב שכעת הוא נרשם מחדש רק כאשר אתה מחליף את תיבת הסימון (`canMove` שינויים) או עורך את הקוד. זה עושה את זה טוב יותר מהגישה הקודמת שתמיד נרשמה מחדש.
-You'll learn a more general approach to this type of problem in [Separating Events from Effects.](/learn/separating-events-from-effects)
+תלמדו גישה כללית יותר לסוג זה של בעיות ב-[הפרדת אירועים מאפקטים.](/learn/separating-events-from-effects)
</Solution>
-#### Fix a connection switch {/*fix-a-connection-switch*/}
+#### תקן מתג חיבור {/*fix-a-connection-switch*/}
-In this example, the chat service in `chat.js` exposes two different APIs: `createEncryptedConnection` and `createUnencryptedConnection`. The root `App` component lets the user choose whether to use encryption or not, and then passes down the corresponding API method to the child `ChatRoom` component as the `createConnection` prop.
+בדוגמה זו, שירות הצ'אט ב- `chat.js` חושף שני ממשקי API שונים: `createEncryptedConnection` ו-`createUencryptedConnection`. רכיב ה-Root `App` יכול למשתמש לבחור אם להשתמש בהצפנה או לא, הוא מעביר את שיטת ה-API המקבילה לרכיב `ChatRoom` הבן בתור הפרופס של `createConnection`.
-Notice that initially, the console logs say the connection is not encrypted. Try toggling the checkbox on: nothing will happen. However, if you change the selected room after that, then the chat will reconnect *and* enable encryption (as you'll see from the console messages). This is a bug. Fix the bug so that toggling the checkbox *also* causes the chat to reconnect.
+שימו לב שבתחילה, יומני המסוף אומרים שהחיבור אינו מוצפן. נסה להפעיל את תיבת הסימון: שום דבר לא יקרה. עם זאת, אם תשנה את החדר הנבחר לאחר מכן, הצ'אט יתחבר מחדש *ו* יאפשר הצפנה (כפי שתראה מהודעות המסוף). זהו באג. תקן את הבאג כך שהחלפת תיבת הסימון *גם* תגרום לצ'אט להתחבר מחדש.
<Hint>
-Suppressing the linter is always suspicious. Could this be a bug?
+דיכוי ה-linter הוא תמיד פעיל. האם זה יכול להיות באג?
</Hint>
@@ -1423,7 +1423,7 @@ label { display: block; margin-bottom: 10px; }
<Solution>
-If you remove the linter suppression, you will see a lint error. The problem is that `createConnection` is a prop, so it's a reactive value. It can change over time! (And indeed, it should--when the user ticks the checkbox, the parent component passes a different value of the `createConnection` prop.) This is why it should be a dependency. Include it in the list to fix the bug:
+אם תסיר את דיכוי המוך, תראה שגיאת מוך. הבעיה היא ש-'createConnection' הוא props, אז זה ערך תגובתי. זה יכול להשתנות עם הזמן! (ואכן, זה צריך--כשה משתמש מסמן את תיבת הסימון, רכיב האב יעביר ערך אחר של ה-'createConnection' מאפיין.) זה מה שזה צריך להיות תלות. כלול אותו ברשימה כדי לתקן את הבא:
<Sandpack>
@@ -1518,7 +1518,7 @@ label { display: block; margin-bottom: 10px; }
</Sandpack>
-It is correct that `createConnection` is a dependency. However, this code is a bit fragile because someone could edit the `App` component to pass an inline function as the value of this prop. In that case, its value would be different every time the `App` component re-renders, so the Effect might re-synchronize too often. To avoid this, you can pass `isEncrypted` down instead:
+נכון ש-'createConnection' הוא תלות. עם זאת, קוד זה מעט שביר מה שמישהו לערוך את רכיב האפליקציה כדי להעביר פונקציה מוטבעת בתור props זה. במקרה, הערך יהיה שונה פעם אחת שרכיב האפליקציה כזה בכל מעבד מחדש, כך שהאפקט הוא להסתנכרן מחדש. כדי להשפיע, אתה מעביר את 'מוצפן' במקום זאת:
<Sandpack>
@@ -1613,21 +1613,21 @@ label { display: block; margin-bottom: 10px; }
</Sandpack>
-In this version, the `App` component passes a boolean prop instead of a function. Inside the Effect, you decide which function to use. Since both `createEncryptedConnection` and `createUnencryptedConnection` are declared outside the component, they aren't reactive, and don't need to be dependencies. You'll learn more about this in [Removing Effect Dependencies.](/learn/removing-effect-dependencies)
+בגרסה זו, הרכיב 'אפליקציה' מעביר props בוליאני במקום פונקציה. בתוך האפקט, אתה מחליט באיזו פונקציה להשתמש. גם `createEncryptedConnection` וגם `createUencryptedConnection` מוכרזים מחוץ לרכיב, הם אינם מגיבים, ואינם צריכים להיות תלות. תוכל ללמוד עוד על כך ב-[הסרת תלויות אפקטים.](/learn/removing-effect-dependencies)
</Solution>
-#### Populate a chain of select boxes {/*populate-a-chain-of-select-boxes*/}
+#### אכלס שרשרת של תיבות נבחרות {/*אכלוס-שרשרת-של-נבחר-תיבות*/}
-In this example, there are two select boxes. One select box lets the user pick a planet. Another select box lets the user pick a place *on that planet.* The second box doesn't work yet. Your task is to make it show the places on the chosen planet.
+בדוגמה זו, יש שתי תיבות בחירה. תיבת בחירה אחת מאפשרת למשתמש לבחור כוכב לכת. תיבת בחירה נוספת מאפשרת למשתמש לבחור מקום *בכוכב זה.* התיבה השנייה עדיין לא עובדת. המשימה שלך היא לגרום לזה להראות את המקומות על הפלנטה הנבחרה.
-Look at how the first select box works. It populates the `planetList` state with the result from the `"/planets"` API call. The currently selected planet's ID is kept in the `planetId` state variable. You need to find where to add some additional code so that the `placeList` state variable is populated with the result of the `"/planets/" + planetId + "/places"` API call.
+תראה איך פועלת תיבת הבחירה הראשונה. הוא מאכל את מצב `planetList` בתוצאה מקריאת ה-API `"/planets"`. המזהה של כוכב הלכת הנבחר כרגע נשמר בשינוי הstate `planetId`. עליך למצוא היכן להוסיף קוד נוסף כדי לשנות את הstate `placeList` יאוכלס בתוצאה של הקריאה `"/planets/" + planetId + "/places"` ל-API.
-If you implement this right, selecting a planet should populate the place list. Changing a planet should change the place list.
+אם אתה מיישם זכות זו, בחירת כוכב לכת אמורה לאכלס את רשימת המקומות. שינוי כוכב לכת אמור לשנות את רשימת המקומות.
<Hint>
-If you have two independent synchronization processes, you need to write two separate Effects.
+אם יש לך שני תהליכי סנכרון עצמאיים, עליך לכתוב שני אפקטים נפרדים.
</Hint>
@@ -1773,12 +1773,12 @@ label { display: block; margin-bottom: 10px; }
<Solution>
-There are two independent synchronization processes:
+ישנם שני תהליכי סנכרון עצמאיים:
-- The first select box is synchronized to the remote list of planets.
-- The second select box is synchronized to the remote list of places for the current `planetId`.
+- תיבת הבחירה הראשונה מסונכרנת לרשימת כוכבי הלכת המרוחקת.
+- תיבת הבחירה השנייה מסנכרנת לרשימת המקומות המרוחקת עבור `planetId` הנוכחי.
-This is why it makes sense to describe them as two separate Effects. Here's an example of how you could do this:
+זו הסיבה שזה הגיוני לתאר אותם כשני אפקטים נפרדים. הנה דוגמה כיצד תוכל לעשות זאת:
<Sandpack>
@@ -1939,9 +1939,9 @@ label { display: block; margin-bottom: 10px; }
</Sandpack>
-This code is a bit repetitive. However, that's not a good reason to combine it into a single Effect! If you did this, you'd have to combine both Effect's dependencies into one list, and then changing the planet would refetch the list of all planets. Effects are not a tool for code reuse.
+הקוד הזה קצת חוזר על עצמו. עם זאת, זו לא סיבה טובה לשלב אותו לאפקט אחד! אם תעשה זאת, תצטרך לשלב את שתי התלות של אפקט לרשימה אחת, ואז שינוי כוכב הלכת יביא מחדש את רשימת כל כוכבי הלכת. אפקטים אינם כלי לשימוש חוזר בקוד.
-Instead, to reduce repetition, you can extract some logic into a custom Hook like `useSelectOptions` below:
+במקום יכול זאת, כדי להפחית את החזרות, אתה לחלץ קצת היגיון לתוך Hook מותאם אישית כמו 'useSelectOptions' למטה:
<Sandpack>
@@ -2102,8 +2102,9 @@ label { display: block; margin-bottom: 10px; }
</Sandpack>
-Check the `useSelectOptions.js` tab in the sandbox to see how it works. Ideally, most Effects in your application should eventually be replaced by custom Hooks, whether written by you or by the community. Custom Hooks hide the synchronization logic, so the calling component doesn't know about the Effect. As you keep working on your app, you'll develop a palette of Hooks to choose from, and eventually you won't need to write Effects in your components very often.
+בדוק את הכרטיסייה 'useSelectOptions.js' בארגז החול כדי לראות איך זה עובד. בדרך כלל אידיאלי, רוב האפקטים באפליקציה שלך צריכים להיות מוחלפים לאחר דבר ב-Hooks מותאמים אישית, בין אם נכתבו על ידך או על ידי הקהילה. ה-Custom Hooks מסתירים את ההיגיון הסנכרון, כך שהרכיב המתקשר לא יודע על האפקט. ככלל שתמשיך לעבוד על האפליקציה שלך, תפתח פלטת הHooks לבחירה, ובסוף דבר לא תצטרך לכתוב אפקטים ברכיבים שלך שנמצאים קרוב מאוד.
</Solution>
</Challenges>
+
diff --git a/src/content/learn/managing-state.md b/src/content/learn/managing-state.md
index 93bcc10fd..8446746a4 100644
--- a/src/content/learn/managing-state.md
+++ b/src/content/learn/managing-state.md
@@ -1,30 +1,30 @@
---
-title: Managing State
+title: "ניהול הstate"
---
<Intro>
-As your application grows, it helps to be more intentional about how your state is organized and how the data flows between your components. Redundant or duplicate state is a common source of bugs. In this chapter, you'll learn how to structure your state well, how to keep your state update logic maintainable, and how to share state between distant components.
+ככל שהאפליקציה שלך גדלה, זה עוזר להיות יותר מכוון לגבי האופן שבו הstate שלך מאורגנת ואיך הנתונים זורמים בין הרכיבים שלך. מצב מיותר או כפול הוא מקור נפוץ לבאגים. בפרק זה, תלמד כיצד לבנות את הstate שלך היטב, כיצד לשמור על לוגיקה של עדכון הstate שלך ניתנת לתחזוקה וכיצד לשתף מצב בין רכיבים מרוחקים.
</Intro>
<YouWillLearn isChapter={true}>
-* [How to think about UI changes as state changes](/learn/reacting-to-input-with-state)
-* [How to structure state well](/learn/choosing-the-state-structure)
-* [How to "lift state up" to share it between components](/learn/sharing-state-between-components)
-* [How to control whether the state gets preserved or reset](/learn/preserving-and-resetting-state)
-* [How to consolidate complex state logic in a function](/learn/extracting-state-logic-into-a-reducer)
-* [How to pass information without "prop drilling"](/learn/passing-data-deeply-with-context)
-* [How to scale state management as your app grows](/learn/scaling-up-with-reducer-and-context)
+* [איך לחשוב על שינויים בממשק משתמש כשינויים בstate](/learn/reacting-to-input-with-state)
+* [איך לבנות מצב טוב](/למד/בחירת-ה-מצב-מבנה)
+* [עזרה "להרים את הstate למעלה" כדי לשתף אותו בין רכיבים](/learn/sharing-state-between-components)
+* [כיצד לשלוט אם הstate ישמר או יאופס](/learn/preserving-and-resetting-state)
+* [כיצד לאחד היגיון מצב מורכב בפונקציה](/learn/extracting-state-logic-to-a-reducer)
+* [כיצד להעביר מידע ללא "קידוח props"](/learn/passing-data-deeply-with-context)
+* [כיצד להרחיב את ניהול הstate ככל שהאפליקציה שלך גדלה](/learn/scaling-up-with-reducer-and-context)
</YouWillLearn>
-## Reacting to input with state {/*reacting-to-input-with-state*/}
+## מגיבה לקלט עם מצב {/*מגיב-לקלט-עם-מצב*/}
-With React, you won't modify the UI from code directly. For example, you won't write commands like "disable the button", "enable the button", "show the success message", etc. Instead, you will describe the UI you want to see for the different visual states of your component ("initial state", "typing state", "success state"), and then trigger the state changes in response to user input. This is similar to how designers think about UI.
+עם React, לא תשנה את ממשק משתמש מהקוד בעצם. לדוגמה, לא תכתוב פקודות כמו "השבת את הלחצן", "הפעל את הלחצן", "הצג את הודעת ההצלחה" וכו'. במקום זאת, תתאר את ממשק המשתמש שאתה רוצה עבור הstates החזותיים לראות את הרכיב שלך ("מצב התחלתי", "מצב הקלדה", "מצב הצלחה"), תפעיל את שינוי הstate בתגובה לקלט המשתמש. זה דומה לאופן שבו מעצבים על ממשק משתמש.
-Here is a quiz form built using React. Note how it uses the `status` state variable to determine whether to enable or disable the submit button, and whether to show the success message instead.
+להלן טופס חידון שנבנה באמצעות React. שים לב איך הוא משתמש בשינוי הstate 'סטטוס' כדי לקבוע אם להפעיל או להשבית את לחצן השליחה, ואם להגיש את הדעת ההצלחה במקום זאת.
<Sandpack>
@@ -108,15 +108,15 @@ function submitForm(answer) {
<LearnMore path="/learn/reacting-to-input-with-state">
-Read **[Reacting to Input with State](/learn/reacting-to-input-with-state)** to learn how to approach interactions with a state-driven mindset.
+קרא את **[להגיב לקלט עם מצב](/learn/reacting-to-input-with-state)** כדי ללמוד כיצד לגשת לאינטראקציות עם חשיבה מונעת לפי מצב.
</LearnMore>
-## Choosing the state structure {/*choosing-the-state-structure*/}
+## בחירת מבנה הstate {/*בחירת-מבנה-הstate*/}
-Structuring state well can make a difference between a component that is pleasant to modify and debug, and one that is a constant source of bugs. The most important principle is that state shouldn't contain redundant or duplicated information. If there's unnecessary state, it's easy to forget to update it, and introduce bugs!
+מבנה מצב טוב יכול לעשות הבדל בין רכיב שנעים לשינוי וניפוי באגים, לבין כזה שמהווה מקור קבוע לבאגים. העיקרון החשוב ביותר הוא שstate לא צריכה להכיל מידע מיותר או משוכפל. אם יש מצב מיותר, קל לשכוח לעדכן אותו ולהציג באגים!
-For example, this form has a **redundant** `fullName` state variable:
+לדוגמה, לטופס זה יש משתנה מצב **מיותר** 'מלא שם':
<Sandpack>
@@ -169,7 +169,7 @@ label { display: block; margin-bottom: 5px; }
</Sandpack>
-You can remove it and simplify the code by calculating `fullName` while the component is rendering:
+אתה יכול להסיר אותו ולפשט את הקוד על ידי חישוב 'שם מלא' בזמן שהרכיב מעבד:
<Sandpack>
@@ -221,19 +221,19 @@ label { display: block; margin-bottom: 5px; }
</Sandpack>
-This might seem like a small change, but many bugs in React apps are fixed this way.
+זה אולי נראה כמו שינוי קטן, אבל באגים רבים באפליקציות הגיבו מתוקנים בדרך זו.
<LearnMore path="/learn/choosing-the-state-structure">
-Read **[Choosing the State Structure](/learn/choosing-the-state-structure)** to learn how to design the state shape to avoid bugs.
+קרא את **[Choosing the State Structure](/learn/choosing-the-state-structure)** כדי ללמוד לעצב את צורת הstate כדי למנוע באגים.
</LearnMore>
-## Sharing state between components {/*sharing-state-between-components*/}
+## מצב שיתוף בין רכיבים {/*sharing-state-between-components*/}
-Sometimes, you want the state of two components to always change together. To do it, remove state from both of them, move it to their closest common parent, and then pass it down to them via props. This is known as "lifting state up", and it's one of the most common things you will do writing React code.
+לפעמים אתה רוצה שstateם של שני רכיבים ישתנה תמיד ביחד. כדי לעשות זאת, הם יעבירו אותו להורה המשותף הקרוב ביותר. זה ידוע בשם "רמת מצב למעלה", וזה אחד הדברים הנפוצים ביותר שתעשה בכתיבת קוד React.
-In this example, only one panel should be active at a time. To achieve this, instead of keeping the active state inside each individual panel, the parent component holds the state and specifies the props for its children.
+בדוגמה זו, רק חלונית אחת צריכה להיות פעילה בכל פעם. כדי להשיג זאת, במקום לשמור על הstate הפעיל בתוך כל פאנל בודד, רכיב האב מחזיק את הstate ומפרט את הprops עבור ילדיו.
<Sandpack>
@@ -296,15 +296,15 @@ h3, p { margin: 5px 0px; }
<LearnMore path="/learn/sharing-state-between-components">
-Read **[Sharing State Between Components](/learn/sharing-state-between-components)** to learn how to lift state up and keep components in sync.
+קרא את **[Sharing State Between Components](/learn/sharing-state-between-components)** כדי ללמוד כיצד להעלות מצב ולשמור על רכיבים מסונכרנים.
</LearnMore>
-## Preserving and resetting state {/*preserving-and-resetting-state*/}
+## שמירה ואיפוס מצב {/*שמירה-ו-איפוס-מצב*/}
-When you re-render a component, React needs to decide which parts of the tree to keep (and update), and which parts to discard or re-create from scratch. In most cases, React's automatic behavior works well enough. By default, React preserves the parts of the tree that "match up" with the previously rendered component tree.
+כאשר אתה מעבד מחדש רכיב, React צריך להחליט אילו חלקים בעץ (ולעדכן), ואילו חלקים לזרוק או ליצור מחדש מאפס. רוב המקרים, ההתנהגות האוטומטית של React עובדת מספיק טוב. כברירת מחדל, תגובה משמר את חלקי העץ מתאים" לעץ הרכיבים שעובד קודם לכן.
-However, sometimes this is not what you want. In this chat app, typing a message and then switching the recipient does not reset the input. This can make the user accidentally send a message to the wrong person:
+עם זאת, לפעמים זה לא מה שאתה רוצה. באפליקציית הצ'אט הזו, הקלדת הודעה ואז החלפת הנמען לא מאפסת את הקלט. זה יכול לגרום למשתמש לשלוח בטעות הודעה לאדם הלא נכון:
<Sandpack>
@@ -399,7 +399,7 @@ textarea {
</Sandpack>
-React lets you override the default behavior, and *force* a component to reset its state by passing it a different `key`, like `<Chat key={email} />`. This tells React that if the recipient is different, it should be considered a *different* `Chat` component that needs to be re-created from scratch with the new data (and UI like inputs). Now switching between the recipients resets the input field--even though you render the same component.
+תגובה מאפשרת לך לעקוף את התנהגות ברירת המחדל, ו*להכריח* רכיב לאפס את מצבו על ידי העברה לו `מפתח` אחר, כמו `<Chat key={email} />`. זה ל-React שאם הנמען שונה, זה צריך להיחשב כרכיב 'צ'אט' *שונה* שצריך ליצור מחדש מאפס עם החדשים (וכניסות כמו ממשק משתמש). עדיין בין הנמענים מאפס את שדה הקלט - למרות שאתה מעבד אותו רכיב.
<Sandpack>
@@ -496,13 +496,13 @@ textarea {
<LearnMore path="/learn/preserving-and-resetting-state">
-Read **[Preserving and Resetting State](/learn/preserving-and-resetting-state)** to learn the lifetime of state and how to control it.
+קרא את **[שימור ואיפוס מצב](/learn/preserving-and-resetting-state)** כדי ללמוד את משך החיים של הstate וכיצד לשלוט בו.
</LearnMore>
-## Extracting state logic into a reducer {/*extracting-state-logic-into-a-reducer*/}
+## חילוץ היגיון מצב לתוך reducer {/*חילוץ-מצב-לוגיקה-לreducer*/}
-Components with many state updates spread across many event handlers can get overwhelming. For these cases, you can consolidate all the state update logic outside your component in a single function, called "reducer". Your event handlers become concise because they only specify the user "actions". At the bottom of the file, the reducer function specifies how the state should update in response to each action!
+רכיבים עם עדכוני מצב רבים המפוזרים על פני מטפלי אירועים רבים יכולים להיות מהמם. במקרים אלה, אתה יכול לאחד את כל הלוגיקה של עדכון הstate מחוץ לרכיב שלך בפונקציה אחת, הנקראת "reducer". מטפלי האירועים שלך הופכים תמציתיים מכיוון שהם מציינים רק את "פעולות" המשתמש. בתחתית הקובץ, פונקציית הreducer מציינת כיצד הstate צריך להתעדכן בתגובה לכל פעולה!
<Sandpack>
@@ -693,15 +693,15 @@ ul, li { margin: 0; padding: 0; }
<LearnMore path="/learn/extracting-state-logic-into-a-reducer">
-Read **[Extracting State Logic into a Reducer](/learn/extracting-state-logic-into-a-reducer)** to learn how to consolidate logic in the reducer function.
+קרא את **[חילוץ היגיון בstate reducer](/learn/extracting-state-logic-into-a-reducer)** כדי ללמוד כיצד לאחד את ההיגיון בפונקציית הreducerה.
</LearnMore>
-## Passing data deeply with context {/*passing-data-deeply-with-context*/}
+## העברת נתונים עמוקה עם הקשר {/*העברת-נתונים-עמוק-עם-הקשר*/}
-Usually, you will pass information from a parent component to a child component via props. But passing props can become inconvenient if you need to pass some prop through many components, or if many components need the same information. Context lets the parent component make some information available to any component in the tree below it—no matter how deep it is—without passing it explicitly through props.
+בדרך כלל, תעביר מידע מרכיב אב לרכיב ילד באמצעות props. אבל העברת props יכולה להיות לא נוחה אם אתה צריך להעביר props כלשהו דרך רכיבים רבים, או אם רכיבים רבים זקוקים לאותו מידע. ההקשר מאפשר לרכיב האב להפוך מידע כלשהו לזמין לכל רכיב בעץ שמתחתיו - לא משנה כמה הוא עמוק - מבלי להעביר אותו במפורש דרך props.
-Here, the `Heading` component determines its heading level by "asking" the closest `Section` for its level. Each `Section` tracks its own level by asking the parent `Section` and adding one to it. Every `Section` provides information to all components below it without passing props--it does that through context.
+כאן, רכיב `Heading` קובע את רמת הכותרת שלו על ידי "שאילת" ה`Section` הקרוב ביותר לרמתו. כל 'מדור' עוקב אחר רמה משלו על ידי שאילת 'מדור' האב והוספת אחד אליו. כל 'מדור' מספק מידע לכל הרכיבים שמתחתיו להעברת props - הוא עושה זאת באמצעות הקשר.
<Sandpack>
@@ -795,15 +795,15 @@ export const LevelContext = createContext(0);
<LearnMore path="/learn/passing-data-deeply-with-context">
-Read **[Passing Data Deeply with Context](/learn/passing-data-deeply-with-context)** to learn about using context as an alternative to passing props.
+קרא את **[העברת נתונים עמHooks עם ההקשר](/learn/passing-data-deeply-with-context)** כדי ללמוד על הפעלה בהקשר כחלופה לprops המועברים.
</LearnMore>
-## Scaling up with reducer and context {/*scaling-up-with-reducer-and-context*/}
+## הגדלה עם reducer והקשר {/*הגדלה-עם-reducer-והקשר*/}
-Reducers let you consolidate a component’s state update logic. Context lets you pass information deep down to other components. You can combine reducers and context together to manage state of a complex screen.
+reducer מאפשרים לך לאחד את לוגיקת עדכון הstate של רכיב. ההקשר מאפשר לך להעביר מידע עמוק למטה לרכיבים אחרים. אתה יכול לשלב reducer והקשר יחד כדי לנהל מצב של מסך מורכב.
-With this approach, a parent component with complex state manages it with a reducer. Other components anywhere deep in the tree can read its state via context. They can also dispatch actions to update that state.
+בגישה זו, רכיב אב עם מצב מורכב מנהל אותו עם reducer. רכיבים אחרים בכל מקום עמוק בעץ יכולים לקרוא את מצבו באמצעות הקשר. הם יכולים גם לשלוח פעולות לעדכון מצב זה.
<Sandpack>
@@ -1006,12 +1006,13 @@ ul, li { margin: 0; padding: 0; }
<LearnMore path="/learn/scaling-up-with-reducer-and-context">
-Read **[Scaling Up with Reducer and Context](/learn/scaling-up-with-reducer-and-context)** to learn how state management scales in a growing app.
+קרא את **[הגדלה עם reducer והקשר](/learn/scaling-up-with-reducer-and-context)** כדי ללמוד ניהול מצב מתרחב באפליקציה צומחת.
</LearnMore>
-## What's next? {/*whats-next*/}
+## מה הלאה? {/*מה-הבא*/}
-Head over to [Reacting to Input with State](/learn/reacting-to-input-with-state) to start reading this chapter page by page!
+עבור אל [מגיב לקלט עם מצב](/learn/reacting-to-input-with-state) כדי להתחיל לקרוא פרק זה עמוד אחר עמוד!
+
+או, אם אתה כבר מכיר את הנושאים האלה, למה שלא תקרא על [Escape Hatches](/learn/escape-hatches)?
-Or, if you're already familiar with these topics, why not read about [Escape Hatches](/learn/escape-hatches)?
diff --git a/src/content/learn/queueing-a-series-of-state-updates.md b/src/content/learn/queueing-a-series-of-state-updates.md
index 41de6529a..c2e067f45 100644
--- a/src/content/learn/queueing-a-series-of-state-updates.md
+++ b/src/content/learn/queueing-a-series-of-state-updates.md
@@ -1,23 +1,23 @@
---
-title: Queueing a Series of State Updates
+title: "תור של עדכוני state"
---
<Intro>
-Setting a state variable will queue another render. But sometimes you might want to perform multiple operations on the value before queueing the next render. To do this, it helps to understand how React batches state updates.
+הגדרת משתנה מצב תעמיד עיבוד נוסף לפי. אבל לפעמים אולי תרצה לבצע מספר פעולות על הערך לפני עמידה בתור לעיבוד הבא. כדי לעשות זאת, זה עוזר להבין איך להגיב מקבץ עדכוני מצב.
</Intro>
<YouWillLearn>
-* What "batching" is and how React uses it to process multiple state updates
-* How to apply several updates to the same state variable in a row
+* מה זה "אצווה" וכיצד React משתמשת בו כדי לעבוד עדכוני מצב מרובים
+* כיצד להחיל מספר עדכונים על אותו משתנה מצב ברצף
</YouWillLearn>
-## React batches state updates {/*react-batches-state-updates*/}
+## עדכוני מצב React batches {/*react-batches-state-updates*/}
-You might expect that clicking the "+3" button will increment the counter three times because it calls `setNumber(number + 1)` three times:
+אתה עשוי לצפות שלחיצה על כפתור "+3" תגדיל את המונה שלוש פעמים שבו הוא קורא ל'setumber(number + 1)' שלוש פעמים:
<Sandpack>
@@ -47,7 +47,7 @@ h1 { display: inline-block; margin: 10px; width: 30px; text-align: center; }
</Sandpack>
-However, as you might recall from the previous section, [each render's state values are fixed](/learn/state-as-a-snapshot#rendering-takes-a-snapshot-in-time), so the value of `number` inside the first render's event handler is always `0`, no matter how many times you call `setNumber(1)`:
+עם זאת, כפי שהם אולי זוכרים מהסעיף הקודם, [ערכי הstate של כל רינדור קבועים](/learn/state-as-a-snapshot#rendering-takes-a-snapshot-in-time), כך שהערך של `number` בתוך הרופאים של הרינדור הוא תמיד `0`, לא משנה כמה פעמים תקרא ``setNumber: הראשון(1):
```js
setNumber(0 + 1);
@@ -55,21 +55,21 @@ setNumber(0 + 1);
setNumber(0 + 1);
```
-But there is one other factor at play here. **React waits until *all* code in the event handlers has run before processing your state updates.** This is why the re-render only happens *after* all these `setNumber()` calls.
+אבל יש כאן גורם נוסף שמשחק. **הגיב ממתין עד ש*כל* הקוד רופאי מומחים יפעל לפני עיבוד עדכוני הstate שלך.** זו הסיבה שהעיבוד מחדש יתרחש רק *אחרי* כל הריאות של `setNumber()` הללו.
-This might remind you of a waiter taking an order at the restaurant. A waiter doesn't run to the kitchen at the mention of your first dish! Instead, they let you finish your order, let you make changes to it, and even take orders from other people at the table.
+זה עשוי להזכיר לך מלצר שמקבל הזמנה במסעדה. מלצר לא רץ למטבח עם אזכור המנה הראשונה שלך! במקום זאת, הם מאפשרים לך לסיים את ההזמנה שלך, מאפשרים לך לבצע בה שינויים, ואפילו לקבל הזמנות מאנשים אחרים ליד השולחן.
<Illustration src="/images/docs/illustrations/i_react-batching.png" alt="An elegant cursor at a restaurant places and order multiple times with React, playing the part of the waiter. After she calls setState() multiple times, the waiter writes down the last one she requested as her final order." />
-This lets you update multiple state variables--even from multiple components--without triggering too many [re-renders.](/learn/render-and-commit#re-renders-when-state-updates) But this also means that the UI won't be updated until _after_ your event handler, and any code in it, completes. This behavior, also known as **batching,** makes your React app run much faster. It also avoids dealing with confusing "half-finished" renders where only some of the variables have been updated.
+זה אפשרי לך לעדכן מספר משתני מצב - אפילו מספר רכיבים - פשוט להפעיל יותר מדי [עיבודים חוזרים.](/learn/render-and-commit#re-renders-when-state-updates) אבל זה גם אומר שממשק משתמש לא יתעדכן עד ש_אחרי_ המטפל באירוע שלך, וכל קוד בו, יס. התנהגות זו, המכונה גם **אצווה,** גורמת לאפליקציית. זה גם נמנע מהחציות עם עיבודים "גמורים" מבלבלים רק חלק מהמשתנים עודכנו.
-**React does not batch across *multiple* intentional events like clicks**--each click is handled separately. Rest assured that React only does batching when it's generally safe to do. This ensures that, for example, if the first button click disables a form, the second click would not submit it again.
+**React אינו מתארך באירועים מכוונים *מרובים* כמו קליקים**--כל קליק מטופל בנפרד. היה סמוך ובטוח ש-React עושה אצווה רק כאשר זה בטוח בדרך כלל. זה מבטיח, למשל, אם הלחיצה הראשונה על הלחצן מבטלת טופס, הלחיצה השנייה לא תשלח אותו שוב.
-## Updating the same state multiple times before the next render {/*updating-the-same-state-multiple-times-before-the-next-render*/}
+## עדכון אותו מצב מספר פעמים לפני העיבוד הבא {/*עדכון-אותו-מצב-מספר-פעמים-לפני-העיבוד-הבא*/}
-It is an uncommon use case, but if you would like to update the same state variable multiple times before the next render, instead of passing the *next state value* like `setNumber(number + 1)`, you can pass a *function* that calculates the next state based on the previous one in the queue, like `setNumber(n => n + 1)`. It is a way to tell React to "do something with the state value" instead of just replacing it.
+זהו מקרה שימוש לא נפוץ, אבל אם תרצה לעדכן את הstate מספר פעמים לפני העיבוד הבא, במקום להעביר את הstate הבא* כמו `setNumber(מספר + 1)`, אתה יכול להעביר *פונקציה* שמח שבת את הstate הבא על הstate הקודם, כמו `setNumber(n => n + 1). זה דרך לומר ל-React "ששות משהו עם ערך הstate" במקום פשוט להחליף אותו.
-Try incrementing the counter now:
+נסה להגדיל את המונה כעת:
<Sandpack>
@@ -99,10 +99,10 @@ h1 { display: inline-block; margin: 10px; width: 30px; text-align: center; }
</Sandpack>
-Here, `n => n + 1` is called an **updater function.** When you pass it to a state setter:
+כאן, `n => n + 1` נקראת **פונקציית עדכון.** כאשר אתה מעביר אותה לקובע מצב:
-1. React queues this function to be processed after all the other code in the event handler has run.
-2. During the next render, React goes through the queue and gives you the final updated state.
+1. תורי תגובה פונקציה זו לעיבוד לאחר הפעלת כל הקוד האחר במטפל.
+2. המשך העיבוד, תגובה עוברת על התורנות לך את הstate המעודכן הסופי.
```js
setNumber(n => n + 1);
@@ -110,26 +110,26 @@ setNumber(n => n + 1);
setNumber(n => n + 1);
```
-Here's how React works through these lines of code while executing the event handler:
+כך פועלת React דרך שורות הקוד הללו בזמן ביצוע המטפל באירועים:
-1. `setNumber(n => n + 1)`: `n => n + 1` is a function. React adds it to a queue.
-1. `setNumber(n => n + 1)`: `n => n + 1` is a function. React adds it to a queue.
-1. `setNumber(n => n + 1)`: `n => n + 1` is a function. React adds it to a queue.
+1. `setNumber(n => n + 1)`: `n => n + 1` היא פונקציה. תגיב מוסיף אותו לתור.
+1. `setNumber(n => n + 1)`: `n => n + 1` היא פונקציה. תגיב מוסיף אותו לתור.
+1. `setNumber(n => n + 1)`: `n => n + 1` היא פונקציה. תגיב מוסיף אותו לתור.
-When you call `useState` during the next render, React goes through the queue. The previous `number` state was `0`, so that's what React passes to the first updater function as the `n` argument. Then React takes the return value of your previous updater function and passes it to the next updater as `n`, and so on:
+כאשר אתה קורא 'useState' על העיבוד הבא, תגובה עוברת בתור. מצב ה'מספר' הקודם היה '0', אז זה מה ש-React מעבירה לפונקציית העדכון הראשון בהארגומנט 'n'. ואז להגיב לוקח את הערך ההחזרה של פונקציית העדכון הקודמת שלך ומעביר אותו לעדכון הבא בתור 'n', וכן הלאה:
-| queued update | `n` | returns |
+| עדכון בתור | `n` | מחזיר |
|--------------|---------|-----|
| `n => n + 1` | `0` | `0 + 1 = 1` |
| `n => n + 1` | `1` | `1 + 1 = 2` |
| `n => n + 1` | `2` | `2 + 1 = 3` |
-React stores `3` as the final result and returns it from `useState`.
+הגיבו מאחסן '3' לפי התוצאה הסופית ומחזיר אותו מ-'useState'.
-This is why clicking "+3" in the above example correctly increments the value by 3.
-### What happens if you update state after replacing it {/*what-happens-if-you-update-state-after-replacing-it*/}
+זו הסיבה שלחיצה על "+3" בדוגמה שלמעלה מעלה את הערך בצורה נכונה ב-3.
+### מה קורה אם אתה מעדכן את הstate לאחר החלפתו {/*what-happens-if-you-update-state-after-replacing-it*/}
-What about this event handler? What do you think `number` will be in the next render?
+מה עם מטפל האירוע הזה? מה לדעתך יהיה 'מספר' בעיבוד הבא?
```js
<button onClick={() => {
@@ -165,29 +165,29 @@ h1 { display: inline-block; margin: 10px; width: 30px; text-align: center; }
</Sandpack>
-Here's what this event handler tells React to do:
+מה שמטפל העסק הזה אומר ל-React לעשות:
-1. `setNumber(number + 5)`: `number` is `0`, so `setNumber(0 + 5)`. React adds *"replace with `5`"* to its queue.
-2. `setNumber(n => n + 1)`: `n => n + 1` is an updater function. React adds *that function* to its queue.
+1. `setNumber(number + 5)`: `number` הוא `0`, אז `setNumber(0 + 5)`. תגיב מוסיף את *"החלף ב-`5`"* לתור שלו.
+2. `setNumber(n => n + 1)`: `n => n + 1` היא פונקציית עדכון. תגיב מוסיף את *הפונקציה הזו* לתור שלו.
-During the next render, React goes through the state queue:
+על העיבוד הבא, תגובה עוברת דרך תור הstate:
-| queued update | `n` | returns |
+| עדכון בתור | `n` | מחזיר |
|--------------|---------|-----|
-| "replace with `5`" | `0` (unused) | `5` |
+| "החלף ב-`5`" | `0` (לא בשימוש) | `5` |
| `n => n + 1` | `5` | `5 + 1 = 6` |
-React stores `6` as the final result and returns it from `useState`.
+הגיבו מאחסן '6' בתור התוצאה הסופית ומחזיר אותו מ-'useState'.
<Note>
-You may have noticed that `setState(5)` actually works like `setState(n => 5)`, but `n` is unused!
+יכול להיות ששמתם לב ש-'setState(5)' עובד למעשה כמו 'setState(n => 5)', אבל 'n' אינו בשימוש!
</Note>
-### What happens if you replace state after updating it {/*what-happens-if-you-replace-state-after-updating-it*/}
+### מה יקרה אם תחליף מצב לאחר עדכון שלו {/*what-happens-if-you-replace-state-after-updating-it*/}
-Let's try one more example. What do you think `number` will be in the next render?
+בואו ננסה דוגמה נוספת. מה לדעתך יהיה 'מספר' בעיבוד הבא?
```js
<button onClick={() => {
@@ -225,32 +225,32 @@ h1 { display: inline-block; margin: 10px; width: 30px; text-align: center; }
</Sandpack>
-Here's how React works through these lines of code while executing this event handler:
+כך פועלת React דרך שורות הקוד הללו בזמן ביצוע המטפל באירועים:
-1. `setNumber(number + 5)`: `number` is `0`, so `setNumber(0 + 5)`. React adds *"replace with `5`"* to its queue.
-2. `setNumber(n => n + 1)`: `n => n + 1` is an updater function. React adds *that function* to its queue.
-3. `setNumber(42)`: React adds *"replace with `42`"* to its queue.
+1. `setNumber(number + 5)`: `number` הוא `0`, אז `setNumber(0 + 5)`. תגיב מוסיף את *"החלף ב-`5`"* לתור שלו.
+2. `setNumber(n => n + 1)`: `n => n + 1` היא פונקציית עדכון. תגיב מוסיף את *הפונקציה הזו* לתור שלו.
+3. `setNumber(42)`: הגיבו מוסיף את *"החלף ב`42`"* לתור שלו.
-During the next render, React goes through the state queue:
+על העיבוד הבא, תגובה עוברת דרך תור הstate:
-| queued update | `n` | returns |
+| עדכון בתור | `n` | מחזיר |
|--------------|---------|-----|
-| "replace with `5`" | `0` (unused) | `5` |
+| "החלף ב-`5`" | `0` (לא בשימוש) | `5` |
| `n => n + 1` | `5` | `5 + 1 = 6` |
-| "replace with `42`" | `6` (unused) | `42` |
+| "החלף ב-`42`" | `6` (לא בשימוש) | `42` |
-Then React stores `42` as the final result and returns it from `useState`.
+לאחר מכן, תגיב מאחסן את '42' בתור התוצאה הסופית ומחזיר אותו מ-'useState'.
-To summarize, here's how you can think of what you're passing to the `setNumber` state setter:
+לסיכום, הנה איך אתה יכול לחשוב על מה שאתה מעביר למגדיר הstate `setNumber`:
-* **An updater function** (e.g. `n => n + 1`) gets added to the queue.
-* **Any other value** (e.g. number `5`) adds "replace with `5`" to the queue, ignoring what's already queued.
+* **פונקציית עדכון** (למשל `n => n + 1`) מתווספת לתור.
+* **כל ערך אחר** (למשל מספר `5`) מוסיף "החלף ב-`5`" לתור, תוך התעלמות ממה שכבר נמצא בתור.
-After the event handler completes, React will trigger a re-render. During the re-render, React will process the queue. Updater functions run during rendering, so **updater functions must be [pure](/learn/keeping-components-pure)** and only *return* the result. Don't try to set state from inside of them or run other side effects. In Strict Mode, React will run each updater function twice (but discard the second result) to help you find mistakes.
+לאחר השלמת המטפל באירועים, React תפעיל עיבוד מחדש. על העיבוד, תגיב תעבד את התור. פונקציות העדכון חייבות לפעול, ולכן **פונקציות העדכון יהיו [טהורות](/learn/keeping-components-pure)** ורק *להחזיר* את התוצאה. אל תנסה להגדיר מצב מתוכם או להפעיל לוואי. בstate קפדני, תגיב תריץ כל פונקציית עדכון פעמיים (אך תמחק את התוצאה השנייה) כדי לעזור לך למצוא טעויות.
-### Naming conventions {/*naming-conventions*/}
+### מוסכמות מתן שמות {/*מוסכמות-שמות*/}
-It's common to name the updater function argument by the first letters of the corresponding state variable:
+מקובל לתת שם לארגומנט פונקציית העדכון באותיות הראשונות של משתנה הstate המתאים:
```js
setEnabled(e => !e);
@@ -258,13 +258,13 @@ setLastName(ln => ln.reverse());
setFriendCount(fc => fc * 2);
```
-If you prefer more verbose code, another common convention is to repeat the full state variable name, like `setEnabled(enabled => !enabled)`, or to use a prefix like `setEnabled(prevEnabled => !prevEnabled)`.
+אם אתה מעדיף קוד מילולי יותר, מוסכמה נפוצה נוספת היא לחזור על שם משתנה הstate המלא, כמו `setEnabled(enabled => !enabled)`, או להשתמש בקידומת כמו `setEnabled(prevEnabled => !prevEnabled)`.
<Recap>
-* Setting state does not change the variable in the existing render, but it requests a new render.
-* React processes state updates after event handlers have finished running. This is called batching.
-* To update some state multiple times in one event, you can use `setNumber(n => n + 1)` updater function.
+* מצב ההגדרה אינו משנה את המשתנה בעיבוד הקיים, אך הוא מבקש עיבוד חדש.
+* React מעבד עדכוני מצב לאחר מטפלי אירועים סיימו לפעול. זה נקרא אצווה.
+* כדי לעדכן מצב מספר פעמים באירוע אחד, אתה יכול להשתמש בפונקציית העדכון של `setNumber(n => n + 1)`.
</Recap>
@@ -272,13 +272,13 @@ If you prefer more verbose code, another common convention is to repeat the full
<Challenges>
-#### Fix a request counter {/*fix-a-request-counter*/}
+#### תקן מונה בקשות {/*fix-a-request-counter*/}
-You're working on an art marketplace app that lets the user submit multiple orders for an art item at the same time. Each time the user presses the "Buy" button, the "Pending" counter should increase by one. After three seconds, the "Pending" counter should decrease, and the "Completed" counter should increase.
+אתה עובד על אפליקציית Art Marketplace המאפשרת למשתמש לשלוח מספר הזמנות לפריט אמנות בו זמנית. בכל פעם שהמשתמש לוחץ על כפתור ה"קנה", מונה ה"ממתין" אמור לגדול באחד. לאחר שלוש שניות, המונה "בהמתנה" אמור לרדת, והמונה "הסתיים" אמור לעלות.
-However, the "Pending" counter does not behave as intended. When you press "Buy", it decreases to `-1` (which should not be possible!). And if you click fast twice, both counters seem to behave unpredictably.
+עם זאת, מונה "בהמתנה" אינו מתנהג כמתוכנן. כאשר אתה לוחץ על "קנה", הוא יורד ל-1-(מה שלא אמור להיות אפשרי!). ואם אתה לוחץ מהר פעמיים, נראה ששני המונים מתנהגים בצורה בלתי צפויה.
-Why does this happen? Fix both counters.
+למה זה קורה? תקן את שני המונים.
<Sandpack>
@@ -322,7 +322,7 @@ function delay(ms) {
<Solution>
-Inside the `handleClick` event handler, the values of `pending` and `completed` correspond to what they were at the time of the click event. For the first render, `pending` was `0`, so `setPending(pending - 1)` becomes `setPending(-1)`, which is wrong. Since you want to *increment* or *decrement* the counters, rather than set them to a concrete value determined during the click, you can instead pass the updater functions:
+בתוך המטפל באירוע `handleClick`, הערכים של `pending` ו`completed` תואמים למה שהם היו בזמן אירוע הקליק. עבור העיבוד הראשון, `pending` היה `0`, אז `setPending(pending - 1)` יוצר להיות `setPending(-1)`, וזה שגוי. מה שאתה רוצה *להגדיל* או *להקטין* את המונים, במקום להגדיר אותם לערך קונקרטי שנקבע הקליק, אתה יכול במקום להעביר את הפונקציות העדכון:
<Sandpack>
@@ -364,23 +364,23 @@ function delay(ms) {
</Sandpack>
-This ensures that when you increment or decrement a counter, you do it in relation to its *latest* state rather than what the state was at the time of the click.
+זה מבטיח שכאשר אתה מגדיל או מקטין מונה, אתה עושה זאת ביחס לstate *האחרון* שלו ולא לstate שהיה בזמן הקליק.
</Solution>
-#### Implement the state queue yourself {/*implement-the-state-queue-yourself*/}
+#### יישם את תור הstate בעצמך {/*יישם-את-ה-state-queue-yourself*/}
-In this challenge, you will reimplement a tiny part of React from scratch! It's not as hard as it sounds.
+באתגר הזה, יש ליישם מחדש חלק זעיר של React מאפס! זה לא קשה כמו שזה נשמע.
-Scroll through the sandbox preview. Notice that it shows **four test cases.** They correspond to the examples you've seen earlier on this page. Your task is to implement the `getFinalState` function so that it returns the correct result for each of those cases. If you implement it correctly, all four tests should pass.
+גלול דרך התצוגה המקדימה של ארגז החול. שימו לב שהוא מציג **ארבעה מקרי בדיקה.** הם תואמים לדוגמאות שראיתם קודם לכן בדף זה. המשימה שלך היא ליישם את הפונקציה 'getFinalState' כך שהיא תחזיר את התוצאה הנכונה עבור כל אחד מהמקרים הללו. אם אתה שם את זה נכון, כל ארבעת המבחנים אמורים לעבור.
-You will receive two arguments: `baseState` is the initial state (like `0`), and the `queue` is an array which contains a mix of numbers (like `5`) and updater functions (like `n => n + 1`) in the order they were added.
+תקבלו שני ארגומנטים: `baseState` הוא הstate ההתחלתי (כמו `0`), וה`תור` הוא מערך המכיל שילוב של מספרים (כמו `5`) עדכון ופונקציות (כמו `n => n + 1`) לפי סדר הוספתם.
-Your task is to return the final state, just like the tables on this page show!
+המשימה שלך היא להחזיר את הstate הסופי, בדיוק כמו שהטבלאות בדף זה מציגות!
<Hint>
-If you're feeling stuck, start with this code structure:
+אם אתה מרגיש תקוע, התחל עם מבנה הקוד הזה:
```js
export function getFinalState(baseState, queue) {
@@ -398,7 +398,7 @@ export function getFinalState(baseState, queue) {
}
```
-Fill out the missing lines!
+מלא את השורות החסרות!
</Hint>
@@ -495,7 +495,7 @@ function TestCase({
<Solution>
-This is the exact algorithm described on this page that React uses to calculate the final state:
+זהו האלגוריתם המדויק המתואר בדף זה שבו משתמשת הגיבו כדי לחשב את הstate הסופי:
<Sandpack>
@@ -596,8 +596,8 @@ function TestCase({
</Sandpack>
-Now you know how this part of React works!
+עכשיו אתה יודע איך החלק הזה של React Work!
</Solution>
-</Challenges>
\ No newline at end of file
+</Challenges>
diff --git a/src/content/learn/react-developer-tools.md b/src/content/learn/react-developer-tools.md
index e9d56be41..1f67f95b1 100644
--- a/src/content/learn/react-developer-tools.md
+++ b/src/content/learn/react-developer-tools.md
@@ -1,10 +1,10 @@
---
-title: React Developer Tools
+title: "כלי הפיתוח של React"
---
<Intro>
-ניתן להשתמש ב-React Developer Tools על מנת לבחון [קומפוננטות](/learn/your-first-component), לערוך [props](/learn/passing-props-to-a-component) ו-[state](/learn/state-a-components-memory), ובנוסף לאבחן בעיות שקשורות לביצועים.
+השתמש ב-React Developer Tools על מנת לבחון [קומפוננטות](/learn/your-first-component), לערוך [props](/learn/passing-props-to-a-component) ו-[state](/learn/state-a-components-memory), ובנוות ניתן לבצע בעיות שקשורות.
</Intro>
<YouWillLearn>
@@ -13,20 +13,20 @@ title: React Developer Tools
</YouWillLearn>
-## תוסף דפדפן {/*browser-extension*/}
+## תוסף דפדפן {/*תוסף-דפדפן*/}
הדרך הקלה ביותר לדבג אתרים שכתובים בעזרת ריאקט היא להתקין את תוסף כלי המפתחים של ריאקט. הוא זמין בכמה דפדפנים:
-* [התקן בדפדפן **Chrome**](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en)
+* [התקן בדפדפן **Chrome**](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=iw)
* [התקן בדפדפן **Firefox**](https://addons.mozilla.org/en-US/firefox/addon/react-devtools/)
* [התקן בדפדפן **Edge**](https://microsoftedge.microsoft.com/addons/detail/react-developer-tools/gpphkfbcpidddadnkolkpfckpihlkkil)
לאחר ההתקנה, אם תיכנס לאתר **שכתוב בריאקט**, תראה את הפאנלים _Components_ ו-_Profiler_.
-
+
### Safari ודפדפנים אחרים {/*safari-and-other-browsers*/}
-על מנת להשתמש בתוסף בדפדפנים אחרים כמו Safari, התקן את חבילת ה-npm הזו: [`react-devtools`](https://www.npmjs.com/package/react-devtools)
+כדי להשתמש בתוכם בדפדפנים אחרים כמו Safari, התקינו את חבילת ה-npm הזו: [`react-devtools`](https://www.npmjs.com/package/react-devtools)
```bash
# Yarn
yarn global add react-devtools
@@ -35,26 +35,26 @@ yarn global add react-devtools
npm install -g react-devtools
```
-עכשיו פתח את כלי המפתחים מהטרמינל:
+עכשיו פתחו את כלי המפתחים מהטרמינל:
```bash
react-devtools
```
-לאחר מכן התחבר לאתר שלך בעזרת הוספת תגית ה-`<script>` הבאה בתוך ה-`head` באתר שלך:
+לאחר התחברו לאתר שלכם על ידי הוספת תגית ה-`<script>` הבאה בתוך ה-`head`:
```html {3}
<html>
<head>
<script src="http://localhost:8097"></script>
```
-טען מחדש את האתר על מנת לראות את הכלים באיזור כלי המפתחים:
+טענו מחדש את האתר כדי לראות את הכלים באזור כלי המפתחים:
-
+
-## Mobile (React Native) {/*mobile-react-native*/}
-ניתן להשתמש בכלי המפתחים של ריאקט על מנת לבחון אפליקציות שנבנו בעזרת [React Native](https://reactnative.dev/).
+## מובייל (React Native) {/*mobile-react-native*/}
+אפשר להשתמש בכל המפתחים של React כדי לבחון אפליקציות גם שנבנו עם [React Native](https://reactnative.dev/).
-הדרך הקלה ביותר להשתמש בכלי המפתחים היא להתקין אותם גלובאלית:
+הדרך הקלה ביותר להשתמש בכלי המפתחים היא להתקין אותם גלובלית:
```bash
# Yarn
yarn global add react-devtools
@@ -63,12 +63,13 @@ yarn global add react-devtools
npm install -g react-devtools
```
-פתח את הכלים מהטרמינל:
+פתחו את הכלים מהטרמינל:
```bash
react-devtools
```
-הכלים אמורים להתחבר לכל אפליקציית react native שרצה לוקאלית.
+הכלים אמורים להתחבר לכל אפליקציית React Native שרצה מקומית.
-> נסה לטעון מחדש את האפליקצייה אם הכלים לא מתחברים אליה תוך מספר שניות.
+> אם הכלים לא מתחברים תוך כמה שניות, נסו לטעון מחדש את האפליקציה.
+
+[למידע נוסף על ניפוי שגיאות ב-React Native.](https://reactnative.dev/docs/debugging)
-[למד עוד על דיבוג React Native.](https://reactnative.dev/docs/debugging)
diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index da559dc0f..10ad66410 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -1,37 +1,37 @@
---
-title: Reacting to Input with State
+title: "תגובה לקלט עם state"
---
<Intro>
-React provides a declarative way to manipulate the UI. Instead of manipulating individual pieces of the UI directly, you describe the different states that your component can be in, and switch between them in response to the user input. This is similar to how designers think about the UI.
+React מספקת דרך הצהרתית לתפעל את ממשק המשתמש. במקום לתפעל חלקים בודדים של ממשק את המשתמש ממש, מתאר את הstate, אתה יכול להיות הרכיב שלך ומחליף בתגובה לקלט המשתמש. זה דומה לאופן שבו מעצבים על ממשק המשתמש.
</Intro>
<YouWillLearn>
-* How declarative UI programming differs from imperative UI programming
-* How to enumerate the different visual states your component can be in
-* How to trigger the changes between the different visual states from code
+* איך תכנות UI הצהרתי שונה מתכנות UI הכרחי
+* איך למנות את הstates הוויזואליים השונים שבהם הרכיב שלך יכול להיות
+* איך להפעיל את השינויים בין הstates החזותיים השונים מקוד
</YouWillLearn>
-## How declarative UI compares to imperative {/*how-declarative-ui-compares-to-imperative*/}
+## איך ממשק משתמש הצהרתי משתווה לציווי {/*how-declarative-ui-compares-to-imerative*/}
-When you design UI interactions, you probably think about how the UI *changes* in response to user actions. Consider a form that lets the user submit an answer:
+כשאתה מעצב אינטראקציות של ממשק משתמש, אתה כנראה חושב על איך ממשק המשתמש *משתנה* בתגובה לפעולות המשתמש. שקול טופס המאפשר למשתמש לשלוח תשובה:
-* When you type something into the form, the "Submit" button **becomes enabled.**
-* When you press "Submit", both the form and the button **become disabled,** and a spinner **appears.**
-* If the network request succeeds, the form **gets hidden,** and the "Thank you" message **appears.**
-* If the network request fails, an error message **appears,** and the form **becomes enabled** again.
+* כשאתה מקליד משהו בטופס, הלחצן "שלח" **הופך לזמין.**
+* כאשר אתה לוחץ על "שלח", גם הטופס וגם הכפתור ** הופכים מושבתים,** ומופיע ספינר **.**
+* אם בקשת הרשת מצליחה, הטופס **מוסתר,** והודעת "תודה" **תופיע.**
+* אם בקשת הרשת נכשלת, הודעת שגיאה **תופיע** והטופס **מופעל** שוב.
-In **imperative programming,** the above corresponds directly to how you implement interaction. You have to write the exact instructions to manipulate the UI depending on what just happened. Here's another way to think about this: imagine riding next to someone in a car and telling them turn by turn where to go.
+ב**תכנות חובה,** האמור לעיל מתאים ישירות לאופן שבו אתה מיישם אינטראקציה. אתה צריך לכתוב את ההוראות המדויקות כדי לתפעל את ממשק המשתמש בהתאם למה שקרה זה עתה. הנה עוד דרך לחשוב על זה: דמיינו לעצמכם נוסעים ליד מישהו במכונית ואומרים לו סבבה לאן ללכת.
<Illustration src="/images/docs/illustrations/i_imperative-ui-programming.png" alt="In a car driven by an anxious-looking person representing JavaScript, a passenger orders the driver to execute a sequence of complicated turn by turn navigations." />
-They don't know where you want to go, they just follow your commands. (And if you get the directions wrong, you end up in the wrong place!) It's called *imperative* because you have to "command" each element, from the spinner to the button, telling the computer *how* to update the UI.
+הם לא יודעים לאן אתה רוצה, הם פשוט פועלים לפי הפקודות שלך. (ואם אתה טועה בהוראות, אתה מגיע למקום הנכון!) זה נקרא *חוויתי* כי אתה צריך "לפקודה" על כל אלמנט, מהספינר ועד הכפתור, להגיד למחשב *איך* לעדכן את ה-UI.
-In this example of imperative UI programming, the form is built *without* React. It only uses the browser [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model):
+בדוגמה זו של תכנות UI חיוני, הטופס בנוי *ללא* תגובה. הוא משתמש רק בדפדפן [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model):
<Sandpack>
@@ -131,37 +131,37 @@ body { font-family: sans-serif; margin: 20px; padding: 0; }
</Sandpack>
-Manipulating the UI imperatively works well enough for isolated examples, but it gets exponentially more difficult to manage in more complex systems. Imagine updating a page full of different forms like this one. Adding a new UI element or a new interaction would require carefully checking all existing code to make sure you haven't introduced a bug (for example, forgetting to show or hide something).
+מניפולציה של ממשק המשתמש פועלת באופן הכרחי מספיק טוב עבור דוגמאות בודדות, אך היא הופכת קשה יותר לניהול במערכות מורכבות יותר. דמיינו לעצמכם עדכון של דף מלא בצורות שונות כמו זה. הוספת רכיב ממשק משתמש חדש או אינטראקציה חדשה תדרוש בדיקה קפדנית של כל הקוד הקיים כדי לוודא שלא הצגת באג (לדוגמה, שכחת להציג או להסתיר משהו).
-React was built to solve this problem.
+תגיב נבנה כדי לפתור בעיה זו.
-In React, you don't directly manipulate the UI--meaning you don't enable, disable, show, or hide components directly. Instead, you **declare what you want to show,** and React figures out how to update the UI. Think of getting into a taxi and telling the driver where you want to go instead of telling them exactly where to turn. It's the driver's job to get you there, and they might even know some shortcuts you haven't considered!
+ב-React, אינך מבצע מניפולציה ישירה של ממשק משתמש - כלומר אינך מפעיל, משבית, מציג מסתיר רכיבים יחיד. במקום זאת, אתה **מצהיר מה אתה רוצה להציג,** ו-React מגלה כיצד לעדכן את ממשק המשתמש. תחשוב להיכנס למונית ולהנהג לאן אתה רוצה להגיד לו בדיוק לא לפנות. זה התפקיד של הנהג להביא אותך לשם, אולי הם אפילו מכירים קיצורי דרך שלא שקלת!
<Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="In a car driven by React, a passenger asks to be taken to a specific place on the map. React figures out how to do that." />
-## Thinking about UI declaratively {/*thinking-about-ui-declaratively*/}
+## חושבים על ממשק משתמש הצהרתי {/*thinking-about-ui-declaratively*/}
-You've seen how to implement a form imperatively above. To better understand how to think in React, you'll walk through reimplementing this UI in React below:
+ראית איך ליישם טופס באופן אישי החי למעלה. כדי להבין טוב יותר איך לחשוב ב-React, תעבור על היישום מחדש של ממשק המשתמש הזה ב-React להלן:
-1. **Identify** your component's different visual states
-2. **Determine** what triggers those state changes
-3. **Represent** the state in memory using `useState`
-4. **Remove** any non-essential state variables
-5. **Connect** the event handlers to set the state
+1. **זהה** את הstates החזותיים השונים של הרכיב שלך
+2. **קבע** מה גורם לשינויי מצב אלה
+3. ** להציג** את הstate בזיכרון באמצעות 'useState'
+4. **הסר** כל משתני מצב שאינם חיוניים
+5. **חבר** את מטפלי האירועים כדי להגדיר את הstate
-### Step 1: Identify your component's different visual states {/*step-1-identify-your-components-different-visual-states*/}
+### שלב 1: זה את הstates החזותיים של הרכיב שלך {/*step-1-identify-your-components-different-visual-states*/}
-In computer science, you may hear about a ["state machine"](https://en.wikipedia.org/wiki/Finite-state_machine) being in one of several “states”. If you work with a designer, you may have seen mockups for different "visual states". React stands at the intersection of design and computer science, so both of these ideas are sources of inspiration.
+במדעי המחשב, אתה יכול לשמוע על ["מכונת state"](https://en.wikipedia.org/wiki/Finite-state_machine) ישת באחת מכמה "מצבים". אם אתה עובד עם מעצב, אפשר שראית מוקאפים עבור "מצבים חזותיים" שונים. תגובה עומדת בצומת של עיצוב ומדעי המחשב, כך ששני הרעיונות הללו הם מקורות השראה.
-First, you need to visualize all the different "states" of the UI the user might see:
+ראשית, עליך לדמיין את כל ה"מצבים" השונים של ממשק המשתמש שהמשתמש עשוי לראות:
-* **Empty**: Form has a disabled "Submit" button.
-* **Typing**: Form has an enabled "Submit" button.
-* **Submitting**: Form is completely disabled. Spinner is shown.
-* **Success**: "Thank you" message is shown instead of a form.
-* **Error**: Same as Typing state, but with an extra error message.
+* **ריק**: בטופס יש כפתור "שלח" מושבת.
+* **הקלדה**: לטופס יש כפתור "שלח" מופעל.
+* **שליחה**: הטופס מושבת לחלוטין. ספינר מוצג.
+* **הצלחה**: הודעת "תודה" מוצגת במקום טופס.
+* **שגיאה**: זהה לstate ההקלדה, אבל עם הודעת שגיאה נוספת.
-Just like a designer, you'll want to "mock up" or create "mocks" for the different states before you add logic. For example, here is a mock for just the visual part of the form. This mock is controlled by a prop called `status` with a default value of `'empty'`:
+בדיוק כמו מעצב, תרצה "לעגוג" או ליצור "לעג" עבור הstates לפני שתוסיף את היגיון. לדוגמה, הנה לעג רק לחלק את הוויזואלי של הטופס. הדמה הזו נשלטת על ידי props שנקרא `סטטוס` עם ערך ברירת המחדל של `'ריק'`:
<Sandpack>
@@ -192,7 +192,7 @@ export default function Form({
</Sandpack>
-You could call that prop anything you like, the naming is not important. Try editing `status = 'empty'` to `status = 'success'` to see the success message appear. Mocking lets you quickly iterate on the UI before you wire up any logic. Here is a more fleshed out prototype of the same component, still "controlled" by the `status` prop:
+אתה יכול לקרוא לprops הזה כל דבר שתרצה, השם לא חשוב. נסה לערוך את `status = 'ריק'` ל-`status = 'הצלחה'` כדי לראות את הודעת ההצלחה מופיעה. אתה יכול ללכת מהר על ממשק המשתמש לפני מחבר היגיון. הנה אב טיפוס יותר מושכל של אותו רכיב, שעדיין "נשלט" על ידי props ה'סטטוס':
<Sandpack>
@@ -240,9 +240,9 @@ export default function Form({
<DeepDive>
-#### Displaying many visual states at once {/*displaying-many-visual-states-at-once*/}
+#### הצגת מצבים חזותיים רבים בו-זמנית {/*הצגת-רבים-וויזואליים-מצבים-בבת-אחת*/}
-If a component has a lot of visual states, it can be convenient to show them all on one page:
+אם לרכיב יש הרבה מצבים חזותיים, זה יכול להיות נוח להציג את כולם בעמוד אחד:
<Sandpack>
@@ -307,61 +307,61 @@ body { margin: 0; }
</Sandpack>
-Pages like this are often called "living styleguides" or "storybooks".
+דפים כמו זה נקראים לעתים קרובות "מדריכי סגנון חיים" או "ספרי סיפורים".
</DeepDive>
-### Step 2: Determine what triggers those state changes {/*step-2-determine-what-triggers-those-state-changes*/}
+### שלב 2: קבע מה גורם לשינויי הstate האלה {/*שלב-2-קבע-מה-מפעיל-השינויים-הstates-האלה*/}
-You can trigger state updates in response to two kinds of inputs:
+אתה יכול להפעיל עדכוני מצב בתגובה לשני סוגים של קלט:
-* **Human inputs,** like clicking a button, typing in a field, navigating a link.
-* **Computer inputs,** like a network response arriving, a timeout completing, an image loading.
+* **תשומות אנושיות,** כמו לחיצה על כפתור, הקלדה בשדה, ניווט בקישור.
+* **כניסות מחשב,** כמו תגובת רשת שמגיעה, השלמת פסק זמן, טעינת תמונה.
<IllustrationBlock>
<Illustration caption="Human inputs" alt="A finger." src="/images/docs/illustrations/i_inputs1.png" />
<Illustration caption="Computer inputs" alt="Ones and zeroes." src="/images/docs/illustrations/i_inputs2.png" />
</IllustrationBlock>
-In both cases, **you must set [state variables](/learn/state-a-components-memory#anatomy-of-usestate) to update the UI.** For the form you're developing, you will need to change state in response to a few different inputs:
+בשני המקרים, **עליך להגדיר [משתני מצב](/learn/state-a-components-memory#anatomy-of-usestate) כדי לעדכן את המשתמש ממש.** עבור הטופס שאתה מפתח, תצטרך לשנות את הstate בתגובה לכמה כניסות שונות:
-* **Changing the text input** (human) should switch it from the *Empty* state to the *Typing* state or back, depending on whether the text box is empty or not.
-* **Clicking the Submit button** (human) should switch it to the *Submitting* state.
-* **Successful network response** (computer) should switch it to the *Success* state.
-* **Failed network response** (computer) should switch it to the *Error* state with the matching error message.
+* **שינוי קלט הטקסט** (אנושי) אמור להעביר אותו מstate *ריק* לstate *הקלדה* או חזרה, תלוי אם תיבת הטקסט ריקה או לא.
+* **לחיצה על כפתור שלח** (אנושית) אמורה להעביר אותו לstate *מגיש*.
+* **תגובת רשת מוצלחת** (מחשב) אמורה להעביר אותה לstate *הצלחה*.
+* **תגובת רשת נכשלה** (מחשב) אמורה להעביר אותה לstate *שגיאה* עם הודעת השגיאה התואמת.
<Note>
-Notice that human inputs often require [event handlers](/learn/responding-to-events)!
+שימו לב שקלט אנושי דורש טיפול [מטפלי אירועים](/learn/reponding-to-events)!
</Note>
-To help visualize this flow, try drawing each state on paper as a labeled circle, and each change between two states as an arrow. You can sketch out many flows this way and sort out bugs long before implementation.
+כדי לעזור לדמיין את הזרימה הזו, נסה לצייר כל מצב על נייר כעיגול מסומן, וכל שינוי בין שני מצבים כחץ. אתה יכול לשרטט זרימות רבות בדרך זו ולסדר באגים הרבה לפני היישום.
<DiagramGroup>
<Diagram name="responding_to_input_flow" height={350} width={688} alt="Flow chart moving left to right with 5 nodes. The first node labeled 'empty' has one edge labeled 'start typing' connected to a node labeled 'typing'. That node has one edge labeled 'press submit' connected to a node labeled 'submitting', which has two edges. The left edge is labeled 'network error' connecting to a node labeled 'error'. The right edge is labeled 'network success' connecting to a node labeled 'success'.">
-Form states
+מצבי טופס
</Diagram>
</DiagramGroup>
-### Step 3: Represent the state in memory with `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/}
+### שלב 3: להציג את הstate בזיכרון באמצעות `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/}
-Next you'll need to represent the visual states of your component in memory with [`useState`.](/reference/react/useState) Simplicity is key: each piece of state is a "moving piece", and **you want as few "moving pieces" as possible.** More complexity leads to more bugs!
+בשלב הבא תעבוד להצגת הstates הוויזואליים של הרכיב שלך בזיכרון עם [`useState`.](/reference/react/useState) הפשטות היא הפתח: כל חלק של מצב הוא "חלק נע", ו**אתה רוצה כמה שפחות "חלקים זזים" ככל האפשר.** יותר מורכבות מובילה ליותר באגים!
-Start with the state that *absolutely must* be there. For example, you'll need to store the `answer` for the input, and the `error` (if it exists) to store the last error:
+תתחיל מstate ש*בהחלט חייבת* להיות שם. לדוגמה, תצטרך לאחסן את ה'תשובה' עבור הקלט, ואת ה'שגיאה' (אם היא קיימת) כדי לאחסן את השגיאה האחרונה:
```js
const [answer, setAnswer] = useState('');
const [error, setError] = useState(null);
```
-Then, you'll need a state variable representing which one of the visual states that you want to display. There's usually more than a single way to represent that in memory, so you'll need to experiment with it.
+לאחר מכן, תזדקק למשתנה מצב המייצג את אחד מstates החזותיים שברצונך להציג. בדרך כלל יש יותר מדרך אחת לייצג את זה בזיכרון, אז תצטרך להתנסות עם זה.
-If you struggle to think of the best way immediately, start by adding enough state that you're *definitely* sure that all the possible visual states are covered:
+אם אתה מתקשה לחשוב על הדרך הטובה ביותר מיד, התחל בהוספת מספיק מצבים שאתה *בהחלט* בטוח שכל הstates החזותיים האפשריים מכוסים:
```js
const [isEmpty, setIsEmpty] = useState(true);
@@ -371,19 +371,19 @@ const [isSuccess, setIsSuccess] = useState(false);
const [isError, setIsError] = useState(false);
```
-Your first idea likely won't be the best, but that's ok--refactoring state is a part of the process!
+סביר להניח שהרעיון הראשון שלך לא יהיה הטוב ביותר, אבל זה בסדר - מצב החזרה הוא חלק מהתהליך!
-### Step 4: Remove any non-essential state variables {/*step-4-remove-any-non-essential-state-variables*/}
+### שלב 4: הסר משתני מצב חיוניים {/*step-4-remove-any-non-essential-state-variables*/}
-You want to avoid duplication in the state content so you're only tracking what is essential. Spending a little time on refactoring your state structure will make your components easier to understand, reduce duplication, and avoid unintended meanings. Your goal is to **prevent the cases where the state in memory doesn't represent any valid UI that you'd want a user to see.** (For example, you never want to show an error message and disable the input at the same time, or the user won't be able to correct the error!)
+אתה רוצה למנוע כפילות בתוכן הstate אז אתה עוקב רק אחר מה שחשוב. השקעת זמן קצר בשינוי מבנה הstate שלך יקל על ההבנה של הרכיבים שלך, יפחית כפילות ויימנע ממשמעויות לא מכוונות. המטרה שלך היא **למנוע את המקרים שבהם הstate בזיכרון אינו מייצג שום ממשק משתמש חוקי שהיית רוצה שמשתמש יראה.** (לדוגמה, לעולם לא תרצה להציג הודעת שגיאה ולהשבית את הקלט בו-זמנית, או שהמשתמש לא יוכל לתקן את השגיאה!)
-Here are some questions you can ask about your state variables:
+הנה כמה שאלות שאתה יכול לשאול לגבי משתני הstate שלך:
-* **Does this state cause a paradox?** For example, `isTyping` and `isSubmitting` can't both be `true`. A paradox usually means that the state is not constrained enough. There are four possible combinations of two booleans, but only three correspond to valid states. To remove the "impossible" state, you can combine these into a `status` that must be one of three values: `'typing'`, `'submitting'`, or `'success'`.
-* **Is the same information available in another state variable already?** Another paradox: `isEmpty` and `isTyping` can't be `true` at the same time. By making them separate state variables, you risk them going out of sync and causing bugs. Fortunately, you can remove `isEmpty` and instead check `answer.length === 0`.
-* **Can you get the same information from the inverse of another state variable?** `isError` is not needed because you can check `error !== null` instead.
+* **האם מצב זה גורם לפרדוקס?** לדוגמה, `isTyping` ו-`issubmitting` לא יכולים להיות שניהם `נכונים`. פרדוקס פירושו בדרך כלל שstate אינה מוגבלת מספיק. יש ארבעה שילובים אפשריים של שני בוליאנים, אך רק שלושה תואמים מצבים תקפים. כדי להוציא את הstate ה"בלתי אפשרי", אתה יכול לשלב אותם ל'סטטוס' שחייב להיות משלו ערכים אחדים: ''הקלדה'`, ''שליחת'` או ''הצלחה'`.
+* **האם אותו מידע זמין כבר בשינוי מצב אחר?** פרדוקס נוסף: `isEmpty` ו-`isTyping` לא יכולים להיות `true` בו-זמנית. על ידי הפיכתם למשתני מצב נפרדים, אתה מסתכן שהם יצאו מסנכרון ויגרמו לבאגים. למרבה המזל, אתה יכול להוציא את `isEmpty` ובמקום זאת לסמן את `answer.length === 0`.
+* **האם אתה יכול לקבל אותו מידע מהיפוך של שינוי מצב אחר?** אין צורך ב-'isError' כי אתה יכול לבדוק את 'error !== null' במקום זאת.
-After this clean-up, you're left with 3 (down from 7!) *essential* state variables:
+לאחר הניקוי הזה, נשארו לך 3 (ירידה מ-7!) *חיוניים* משתני מצב:
```js
const [answer, setAnswer] = useState('');
@@ -391,19 +391,19 @@ const [error, setError] = useState(null);
const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 'success'
```
-You know they are essential, because you can't remove any of them without breaking the functionality.
+אתה יודע שהם חיוניים, כי אתה לא יכול להסיר אף אחד מהם מבלי לשבור את הפונקציונליות.
<DeepDive>
-#### Eliminating “impossible” states with a reducer {/*eliminating-impossible-states-with-a-reducer*/}
+#### ביטול מצבים "בלתי אפשריים" עם reducer {/*ביטול-בלתי-אפשרי-מצבים-עם-reducer*/}
-These three variables are a good enough representation of this form's state. However, there are still some intermediate states that don't fully make sense. For example, a non-null `error` doesn't make sense when `status` is `'success'`. To model the state more precisely, you can [extract it into a reducer.](/learn/extracting-state-logic-into-a-reducer) Reducers let you unify multiple state variables into a single object and consolidate all the related logic!
+שלושת המשתנים הללו הם ייצוג מספיק טוב של מצב הצורה הזו. עם זאת, יש לי ממש כמה מצבי. לדוגמה, `שגיאה` אינה אפס אינה הגיונית כאשר `סטטוס` הוא ``הצלחה``. כדי לדגמן את הstate בצורה מדויקת יותר, אתה [לחלץ אותו לתוך reducer.](/learn/extracting-state-logic-into-a-reducer) reducer לך לאחד מצב שני מרובים לאובייקט אחד ולאחד את כל ההיגיון הקשור!
</DeepDive>
-### Step 5: Connect the event handlers to set state {/*step-5-connect-the-event-handlers-to-set-state*/}
+### שלב 5: חברו את מטפלי האירועים לעדכון מצב {/*step-5-connect-the-event-handlers-to-set-state*/}
-Lastly, create event handlers that update the state. Below is the final form, with all event handlers wired up:
+לבסוף, צור מטפלי אירועים שמעדכנים את הstate. להלן הטופס הסופי, עם כל מטפלי האירועים מחוברים:
<Sandpack>
@@ -485,17 +485,17 @@ function submitForm(answer) {
</Sandpack>
-Although this code is longer than the original imperative example, it is much less fragile. Expressing all interactions as state changes lets you later introduce new visual states without breaking existing ones. It also lets you change what should be displayed in each state without changing the logic of the interaction itself.
+למרות שהקוד הזה ארוך יותר מהדוגמה המקורית של הציווי, הוא הרבה פחות שביר. ביטוי כל האינטראקציות כשינויי מצב מאפשר לך להציג מאוחר יותר מצבים חזותיים חדשים מבלי לשבור את הstates הקיימים. זה גם מאפשר לך לשנות את מה שצריך להיות מוצג בכל מצב מבלי לשנות את ההיגיון של האינטראקציה עצמה.
<Recap>
-* Declarative programming means describing the UI for each visual state rather than micromanaging the UI (imperative).
-* When developing a component:
- 1. Identify all its visual states.
- 2. Determine the human and computer triggers for state changes.
- 3. Model the state with `useState`.
- 4. Remove non-essential state to avoid bugs and paradoxes.
- 5. Connect the event handlers to set state.
+* תכנות הצהרתי פירושו תיאור ממשק המשתמש עבור כל מצב ויזואלי במקום ניהול מיקרו של ממשק המשתמש (הכרח).
+* בעת פיתוח רכיב:
+ 1. זהה את כל הstates החזותיים שלו.
+ 2. קבע את הטריגרים האנושיים והמחשבים לשינויי מצב.
+ 3. דגם את הstate באמצעות 'useState'.
+ 4. הסר מצב לא חיוני כדי למנוע באגים ופרדוקסים.
+ 5. חבר את מטפלי האירועים לstate מוגדר.
</Recap>
@@ -503,11 +503,11 @@ Although this code is longer than the original imperative example, it is much le
<Challenges>
-#### Add and remove a CSS class {/*add-and-remove-a-css-class*/}
+#### הוסף והסר מחלקת CSS {/*add-and-remove-a-css-class*/}
-Make it so that clicking on the picture *removes* the `background--active` CSS class from the outer `<div>`, but *adds* the `picture--active` class to the `<img>`. Clicking the background again should restore the original CSS classes.
+הפוך את זה כך שלחיצה על התמונה *תסיר* את מחלקת ה-CSS `background--active` מהמחלקה החיצונית ``<div>``, אך *מוסיפה* את המחלקה `picture--active` למחלקה ``<img>``. לחיצה נוספת על הרקע אמורה לשחזר את מחלקות ה-CSS המקוריות.
-Visually, you should expect that clicking on the picture removes the purple background and highlights the picture border. Clicking outside the picture highlights the background, but removes the picture border highlight.
+מבחינה ויזואלית, אתה צריך לצפות שלחיצה על התמונה תסיר את הרקע הסגול ותדגיש את גבול התמונה. לחיצה מחוץ לתמונה מדגישה את הרקע, אך מסירה את סימון גבול התמונה.
<Sandpack>
@@ -557,14 +557,14 @@ body { margin: 0; padding: 0; height: 250px; }
<Solution>
-This component has two visual states: when the image is active, and when the image is inactive:
+לרכיב זה שני מצבים חזותיים: כאשר התמונה פעילה וכאשר התמונה אינה פעילה:
-* When the image is active, the CSS classes are `background` and `picture picture--active`.
-* When the image is inactive, the CSS classes are `background background--active` and `picture`.
+* כשהתמונה פעילה, מחלקות ה-CSS הן `רקע` ו`תמונה תמונה--פעילה`.
+* כאשר התמונה אינה פעילה, מחלקות ה-CSS הן `רקע--פעיל` ו`תמונה`.
-A single boolean state variable is enough to remember whether the image is active. The original task was to remove or add CSS classes. However, in React you need to *describe* what you want to see rather than *manipulate* the UI elements. So you need to calculate both CSS classes based on the current state. You also need to [stop the propagation](/learn/responding-to-events#stopping-propagation) so that clicking the image doesn't register as a click on the background.
+מספיק ניהול מצב בוליאני אחד כדי לזכור אם התמונה פעילה. המשימה המקורית הייתה להוציא או להוסיף מחלקות CSS. עם זאת, ב-React אתה צריך *לתאר* את מה שאתה רוצה לראות במקום *להשפיע* על רכיבי ממשק משתמש. אתה צריך לחשב את שתי מחלקות ה-CSS על סמך הstate הנוכחי. אתה גם צריך [להפסיק את ההפצה](/learn/responding-to-events#stopping-propagation) כדי שהלחיצה על התמונה לא תירשם כלחיצה על הרקע.
-Verify that this version works by clicking the image and then outside of it:
+ודא שגרסה זו פועלת על ידי לחיצה על התמונה ולאחר מכן מחוצה לה:
<Sandpack>
@@ -631,7 +631,7 @@ body { margin: 0; padding: 0; height: 250px; }
</Sandpack>
-Alternatively, you could return two separate chunks of JSX:
+לחלופין, אתה יכול להחזיר שני נתחים נפרדים של JSX:
<Sandpack>
@@ -698,13 +698,13 @@ body { margin: 0; padding: 0; height: 250px; }
</Sandpack>
-Keep in mind that if two different JSX chunks describe the same tree, their nesting (first `<div>` → first `<img>`) has to line up. Otherwise, toggling `isActive` would recreate the whole tree below and [reset its state.](/learn/preserving-and-resetting-state) This is why, if a similar JSX tree gets returned in both cases, it is better to write them as a single piece of JSX.
+זכור שאם שני נתחי JSX שונים מתארים את אותו עץ, הקינון שלהם (ראשון ``<div>`` → הראשון ``<img>``) צריך להתאים. אחרת, החלפת 'isActive' תיצור מחדש את כל העץ למטה ו[יאפס את מצבו.](/learn/preserving-and-resetting-state) אפשר יהיה לחשוב על יוחזר עץ JSX דומה בשני המקרים, עדיף לכתוב אותם כחלק אחד של JSX.
</Solution>
-#### Profile editor {/*profile-editor*/}
+#### עורך פרופילים {/*עורך-פרופיל*/}
-Here is a small form implemented with plain JavaScript and DOM. Play with it to understand its behavior:
+הנה טופס קטן מיושם עם JavaScript ו-DOM רגילים. שחקו איתו כדי להבין את ההתנהגות שלו:
<Sandpack>
@@ -801,11 +801,11 @@ label { display: block; margin-bottom: 20px; }
</Sandpack>
-This form switches between two modes: in the editing mode, you see the inputs, and in the viewing mode, you only see the result. The button label changes between "Edit" and "Save" depending on the mode you're in. When you change the inputs, the welcome message at the bottom updates in real time.
+טופס זה עובר בין שני מצבים: בstate העריכה רואים את הקלטים ובstate הצפייה רואים רק את התוצאה. תווית הכפתור משתנה בין "ערוך" ל"שמור" בהתאם לstate שבו אתה נמצא. כשאתה משנה את הקלט, הודעת הפתיחה בתחתית מתעדכנת בזמן אמת.
-Your task is to reimplement it in React in the sandbox below. For your convenience, the markup was already converted to JSX, but you'll need to make it show and hide the inputs like the original does.
+המשימה היא שלך ליישם אותו מחדש ב-React בארגז החול למטה. לנוחיותך, הסימון כבר הומר ל-JSX, אבל תעזור לו להופיע ולהסתיר את הקלט כמו שהמקור עושה.
-Make sure that it updates the text at the bottom, too!
+ודא שהוא מעדכן גם את הטקסט בתחתית!
<Sandpack>
@@ -840,9 +840,9 @@ label { display: block; margin-bottom: 20px; }
<Solution>
-You will need two state variables to hold the input values: `firstName` and `lastName`. You're also going to need an `isEditing` state variable that holds whether to display the inputs or not. You should _not_ need a `fullName` variable because the full name can always be calculated from the `firstName` and the `lastName`.
+תזדקק לשני משתני מצב כדי לאחסן את ערכי הקלט: `firstName` ו-`lastName`. אתה גם תצטרך לשנות מצב 'isEditing' שמחזיק אם להציג את הקלט או לא. אתה צריך _לא_ להזדק לשינוי `שם מלא` כי ניתן לחשב את השם המלא תמיד מתוך `שם פרטי` ו`שם משפחה`.
-Finally, you should use [conditional rendering](/learn/conditional-rendering) to show or hide the inputs depending on `isEditing`.
+לבסוף, עליך להשתמש ב[עיבוד מותנה](/learn/conditional-rendering) כדי להציג או להסתיר את הקלט בהתאם ל-'isEditing'.
<Sandpack>
@@ -900,13 +900,13 @@ label { display: block; margin-bottom: 20px; }
</Sandpack>
-Compare this solution to the original imperative code. How are they different?
+השווה פתרון זה לקוד הציווי המקורי. במה הם שונים?
</Solution>
-#### Refactor the imperative solution without React {/*refactor-the-imperative-solution-without-react*/}
+#### שחזר את הפתרון החיוני ללא React {/*refactor-the-imerative-solution-without-react*/}
-Here is the original sandbox from the previous challenge, written imperatively without React:
+הנה ארגז החול המקורי מהאתגר הקודם, שנכתב בהכרח ללא תגובה:
<Sandpack>
@@ -1003,9 +1003,9 @@ label { display: block; margin-bottom: 20px; }
</Sandpack>
-Imagine React didn't exist. Can you refactor this code in a way that makes the logic less fragile and more similar to the React version? What would it look like if the state was explicit, like in React?
+תארו לעצמכם ש-React לא היה קיים. האם אתה יכול לשחזר את הקוד הזה יכול לעשות את ההיגיון לפחות שביר ודומה לגרסת להגיב? איך זה היה נראה אם הstate הייתה מפורשת, כמו ב-React?
-If you're struggling to think where to start, the stub below already has most of the structure in place. If you start here, fill in the missing logic in the `updateDOM` function. (Refer to the original code where needed.)
+אם אתה מתקשה לחשוב מאיפה להתחיל, הבדל למטה כבר מכיל את רוב המבנה במקום. אם תתחיל כאן, מלא את ההיגיון החסר בפונקציית `updateDOM`. (עיין בקוד המקורי בתנאי צורך.)
<Sandpack>
@@ -1112,7 +1112,7 @@ label { display: block; margin-bottom: 20px; }
<Solution>
-The missing logic included toggling the display of inputs and content, and updating the labels:
+ההיגיון החסר כלל החלפת תצוגת הקלט והתוכן, ועדכון התוויות:
<Sandpack>
@@ -1229,8 +1229,9 @@ label { display: block; margin-bottom: 20px; }
</Sandpack>
-The `updateDOM` function you wrote shows what React does under the hood when you set the state. (However, React also avoids touching the DOM for properties that have not changed since the last time they were set.)
+הפונקציה 'updateDOM' כתבת מראה מה תגובה עושה מתחת למכסה המנוע כאשר אתה מגדיר את הstate. (עם זאת, הגיבו גם נמנעת מלגעת ב-DOM עבור מאפיינים שלא השתנו בתקופה האחרונה שהם הוגדרו.)
</Solution>
</Challenges>
+
diff --git a/src/content/learn/removing-effect-dependencies.md b/src/content/learn/removing-effect-dependencies.md
index 9a871c6c3..ec8ee4c35 100644
--- a/src/content/learn/removing-effect-dependencies.md
+++ b/src/content/learn/removing-effect-dependencies.md
@@ -1,26 +1,26 @@
---
-title: 'Removing Effect Dependencies'
+title: "הסרת תלויות של אפקט"
---
<Intro>
-When you write an Effect, the linter will verify that you've included every reactive value (like props and state) that the Effect reads in the list of your Effect's dependencies. This ensures that your Effect remains synchronized with the latest props and state of your component. Unnecessary dependencies may cause your Effect to run too often, or even create an infinite loop. Follow this guide to review and remove unnecessary dependencies from your Effects.
+כאשר אתה כותב אפקט, ה-linter יוודא שכללת כל ערך תגובתי (כמו props וstate) שהאפקט קורא ברשימת התלות של האפקט שלך. זה מבטיח שהאפקט שלך יישאר מסונכרן עם הprops וstate העדכניים ביותר של הרכיב שלך. תלות מיותרות עלולה לגרום לאפקט שלך לפעול בזמן, או אפילו ליצור לולאה אינסופית. עקוב אחר המדריך הזה כדי לאפשר לך להתחבר מהאפקטים שלך.
</Intro>
<YouWillLearn>
-- How to fix infinite Effect dependency loops
-- What to do when you want to remove a dependency
-- How to read a value from your Effect without "reacting" to it
-- How and why to avoid object and function dependencies
-- Why suppressing the dependency linter is dangerous, and what to do instead
+- כיצד לתקן לולאות תלות אינסופיות של אפקט
+- מה לעשות כשרוצים להסיר תלות
+- כיצד לקרוא ערך מהאפקט שלך מבלי "להגיב" אליו
+- כיצד ומדוע להימנע מתלות באובייקט ובתפקוד
+- מדוע דיכוי של קו התלות הוא מסוכן, ומה לעשות במקום זאת
</YouWillLearn>
-## Dependencies should match the code {/*dependencies-should-match-the-code*/}
+## תלויות צריכות להתאים לקוד {/*dependencies-should-match-the-code*/}
-When you write an Effect, you first specify how to [start and stop](/learn/lifecycle-of-reactive-effects#the-lifecycle-of-an-effect) whatever you want your Effect to be doing:
+אתה כותב אפקט, אתה מציין תחילה כיצד [להתחיל ולהפסיק](/learn/lifecycle-of-reactive-effects#the-lifecycle-of-an-effect) כל מה שאתה רוצה שהאפקט שלך יעשה:
```js {5-7}
const serverUrl = 'https://localhost:1234';
@@ -34,7 +34,7 @@ function ChatRoom({ roomId }) {
}
```
-Then, if you leave the Effect dependencies empty (`[]`), the linter will suggest the correct dependencies:
+לאחר, אם תשאיר את התלות של אפקט ריקות (`[]`), ה-linter יציע את התלות הנכונות:
<Sandpack>
@@ -96,7 +96,7 @@ button { margin-left: 10px; }
</Sandpack>
-Fill them in according to what the linter says:
+מלא לפי מה שכתוב ב-linter:
```js {6}
function ChatRoom({ roomId }) {
@@ -109,7 +109,7 @@ function ChatRoom({ roomId }) {
}
```
-[Effects "react" to reactive values.](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values) Since `roomId` is a reactive value (it can change due to a re-render), the linter verifies that you've specified it as a dependency. If `roomId` receives a different value, React will re-synchronize your Effect. This ensures that the chat stays connected to the selected room and "reacts" to the dropdown:
+[אפקטים "מגיבים" לערכים תגובתיים.](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values) כאשר ש-'roomId' הוא ערך תגובתי (הוא יכול להשתנות עקב עיבוד מחדש), ה-linter מאמת שציינת אותו כתלות. אם 'roomId' יקבל ערך שונה, תגיב יסנכרן מחדש את האפקט שלך. זה מבטיח שהצ'אט יישאר מחובר לחדר שנבחר ו"מגיב" לתפריט הנפתח:
<Sandpack>
@@ -171,9 +171,9 @@ button { margin-left: 10px; }
</Sandpack>
-### To remove a dependency, prove that it's not a dependency {/*to-remove-a-dependency-prove-that-its-not-a-dependency*/}
+### כדי להסיר תלות, הוכח זה לא תלות {/*to-remove-a-dependency-prove-that-its-not-a-dependence*/}
-Notice that you can't "choose" the dependencies of your Effect. Every <CodeStep step={2}>reactive value</CodeStep> used by your Effect's code must be declared in your dependency list. The dependency list is determined by the surrounding code:
+שימו לב שאינכם יכולים "לבחור" את התלות של האפקט. כל <CodeStep step={2}>ערך תגובתי</CodeStep> המשמש את הקוד של האפקט שלך חייב להיות מוצהר ברשימת התלות שלך. רשימת התלות לפי הקוד שמסביב:
```js [[2, 3, "roomId"], [2, 5, "roomId"], [2, 8, "roomId"]]
const serverUrl = 'https://localhost:1234';
@@ -188,7 +188,7 @@ function ChatRoom({ roomId }) { // This is a reactive value
}
```
-[Reactive values](/learn/lifecycle-of-reactive-effects#all-variables-declared-in-the-component-body-are-reactive) include props and all variables and functions declared directly inside of your component. Since `roomId` is a reactive value, you can't remove it from the dependency list. The linter wouldn't allow it:
+[ערכים תגובתיים](/learn/lifecycle-of-reactive-effects#all-variables-declared-in-the-component-body-are-reactive) מספקים props וכל המשתנים והפונקציות המוצהרות באופן עצמאי בתוך הרכיב שלך. זה ש-'roomId' הוא ערך תגובתי, אינך יכול להוציא אותו מרשימת התת. ה-Linter לא יאפשר זאת:
```js {8}
const serverUrl = 'https://localhost:1234';
@@ -203,9 +203,9 @@ function ChatRoom({ roomId }) {
}
```
-And the linter would be right! Since `roomId` may change over time, this would introduce a bug in your code.
+והלינטר יהיה נכון! מה ש-'roomId' עשוי להשתנות עם הזמן, זה יציג באג בקוד שלך.
-**To remove a dependency, "prove" to the linter that it *doesn't need* to be a dependency.** For example, you can move `roomId` out of your component to prove that it's not reactive and won't change on re-renders:
+**כדי שלך להשלים תלות, "הוכח" ל-linter שהיא *לא צריכה* להיות תלות.** למשל, אתה יכול להעביר את 'roomId' מהרכיב כדי להוכיח שהוא לא תגובתי ולא ישתנה בעיבוד מחדש:
```js {2,9}
const serverUrl = 'https://localhost:1234';
@@ -221,7 +221,7 @@ function ChatRoom() {
}
```
-Now that `roomId` is not a reactive value (and can't change on a re-render), it doesn't need to be a dependency:
+עכשיו, כאשר `roomId` אינו ערך תגובתי (ולא יכול להשתנות בעיבוד), זה לא צריך להיות תלות:
<Sandpack>
@@ -263,23 +263,23 @@ button { margin-left: 10px; }
</Sandpack>
-This is why you could now specify an [empty (`[]`) dependency list.](/learn/lifecycle-of-reactive-effects#what-an-effect-with-empty-dependencies-means) Your Effect *really doesn't* depend on any reactive value anymore, so it *really doesn't* need to re-run when any of the component's props or state change.
+זה מה שאתה יכול לציין רשימת תלות [ריקה (`[]`).](/learn/lifecycle-of-reactive-effects#what-an-effect-with-empty-dependencies-means) האפקט שלך *באמת לא* תלוי בשום ערך תגובתי יותר, אז הוא *בלא* צריך להפעיל מחדש את הstate כאשר כל אחד מprops.
-### To change the dependencies, change the code {/*to-change-the-dependencies-change-the-code*/}
+### כדי לשנות את התלות, שנה את הקוד {/*to-change-the-dependencies-change-the-code*/}
-You might have noticed a pattern in your workflow:
+אולי שמת לב לדפוס בזרימת העבודה שלך:
-1. First, you **change the code** of your Effect or how your reactive values are declared.
-2. Then, you follow the linter and adjust the dependencies to **match the code you have changed.**
-3. If you're not happy with the list of dependencies, you **go back to the first step** (and change the code again).
+1. ראשית, אתה **שנה את הקוד** של האפקט שלך או איך הערכים התגובתיים שלך מוצהרים.
+2. לאחר מכן, אתה עוקב אחר ה-linter ומתאים את התלות כדי **להתאים לקוד ששינית.**
+3. אם אינך מרוצה מרשימת התלות, אתה **חוזר לשלב הראשון** (ושנה שוב את הקוד).
-The last part is important. **If you want to change the dependencies, change the surrounding code first.** You can think of the dependency list as [a list of all the reactive values used by your Effect's code.](/learn/lifecycle-of-reactive-effects#react-verifies-that-you-specified-every-reactive-value-as-a-dependency) You don't *choose* what to put on that list. The list *describes* your code. To change the dependency list, change the code.
+החלק האחרון חשוב. **אם ברצונך לשנות את התלות, שנה תחילה את הקוד שמסביב.** אתה יכול לחשוב על רשימת התלות כעל [רשימה של כל הערכים התגובתיים המשמשים את הקוד של האפקט שלך.](/learn/lifecycle-of-reactive-effects#react-verifies-that-you-specificated-every-reactive-a-reactive-a-value) הרשימה *מתארת* את הקוד שלך. כדי לשנות את רשימת התלות, שנה את הקוד.
-This might feel like solving an equation. You might start with a goal (for example, to remove a dependency), and you need to "find" the code matching that goal. Not everyone finds solving equations fun, and the same thing could be said about writing Effects! Luckily, there is a list of common recipes that you can try below.
+זה עשוי להרגיש כמו לפתור משוואה. ייתכן שתתחיל עם יעד (לדוגמה, כדי להסיר תלות), ואתה צריך "למצוא" את הקוד התואם למטרה זו. לא לכולם פתרון משוואות כיף, וניתן לומר אותו דבר על כתיבת אפקטים! למרבה המזל, יש רשימה של מתכונים נפוצים שתוכלו לנסות למטה.
<Pitfall>
-If you have an existing codebase, you might have some Effects that suppress the linter like this:
+אם יש לך בסיס קוד קיים, אולי יהיו לך כמה אפקטים שמדכאים את ה-linter כך:
```js {3-4}
useEffect(() => {
@@ -289,17 +289,17 @@ useEffect(() => {
}, []);
```
-**When dependencies don't match the code, there is a very high risk of introducing bugs.** By suppressing the linter, you "lie" to React about the values your Effect depends on.
+**כאשר התלות אינן תואמות לקוד, יש סיכון גבוה מאוד להחדרת באגים.** על ידי דיכוי ה-linter, אתה "משקר" כדי להגיב לגבי הערכים שהאפקט שלך תלוי בהם.
-Instead, use the techniques below.
+במקום זאת, השתמש בטכניקות שלהלן.
</Pitfall>
<DeepDive>
-#### Why is suppressing the dependency linter so dangerous? {/*why-is-suppressing-the-dependency-linter-so-dangerous*/}
+#### מדוע דיכוי קו התלות כל כך מסוכן? {/*למה-מדכא-דיכוי-התלות-לבנת-כל-כך-מסוכן*/}
-Suppressing the linter leads to very unintuitive bugs that are hard to find and fix. Here's one example:
+דיכוי ה-linter מוביל לבאגים מאוד לא אינטואיטיביים שקשה למצוא ולתקן. הנה דוגמה אחת:
<Sandpack>
@@ -348,31 +348,31 @@ button { margin: 10px; }
</Sandpack>
-Let's say that you wanted to run the Effect "only on mount". You've read that [empty (`[]`) dependencies](/learn/lifecycle-of-reactive-effects#what-an-effect-with-empty-dependencies-means) do that, so you've decided to ignore the linter, and forcefully specified `[]` as the dependencies.
+נניח שרצית להפעיל את האפקט "רק על הר". קראת ש-[ריקות (`[]`) תלויות](/learn/lifecycle-of-reactive-effects#what-an-effect-with-empty-dependencies-means) עושות את זה, אז החלטתי להתעלם מה-linter, וציינת בכוח `[]` לפי התלות.
-This counter was supposed to increment every second by the amount configurable with the two buttons. However, since you "lied" to React that this Effect doesn't depend on anything, React forever keeps using the `onTick` function from the initial render. [During that render,](/learn/state-as-a-snapshot#rendering-takes-a-snapshot-in-time) `count` was `0` and `increment` was `1`. This is why `onTick` from that render always calls `setCount(0 + 1)` every second, and you always see `1`. Bugs like this are harder to fix when they're spread across multiple components.
+המונה הזה היה אמור לעלות כל שנייה בכמות לאפשר להגדיר עם שני הכפתורים. עם זאת, השתמש ב"שיקרת" ל-React שהאפקט הזה לא תלוי בשום דבר, תגיב לנצח ממשיך בפעולה 'onTick' מהרינדור הראשוני. [במהלך העיבוד הזה,](/learn/state-as-a-snapshot#rendering-takes-a-snapshot-in-time) `ספירה` הייתה `0` ו`increment` הייתה `1`. זה מה ש'onTick' זה תמיד קורא ל'setCount(0 + 1)' כל שנייה, ואתה תמיד רואה '1'. קשה יותר לתקן באגים כאלה כשהם מרוזרים על מספר רכיבים.
-There's always a better solution than ignoring the linter! To fix this code, you need to add `onTick` to the dependency list. (To ensure the interval is only setup once, [make `onTick` an Effect Event.](/learn/separating-events-from-effects#reading-latest-props-and-state-with-effect-events))
+תמיד יש פתרון טוב יותר מאשר התעלמות מהלינטר! כדי לתקן את הקוד הזה, עליך להוסיף 'onTick' לרשימת התלות. (כדי בכלל שהמרווח מוגדר פעם אחת בלבד, [הפוך את 'onTick' לאירוע אפקט.](/learn/separating-events-from-effects#reading-latest-props-and-state-with-effect-events))
-**We recommend treating the dependency lint error as a compilation error. If you don't suppress it, you will never see bugs like this.** The rest of this page documents the alternatives for this and other cases.
+**אנו ממליצים להתייחס לשגיאת מוך התלות כשגיאת קומפילציה. אם לא תדחיק את זה, לעולם לא תראה באגים כאלה.** שאר העמוד הזה מתעד את החלופות למקרים זה ואחרים.
</DeepDive>
-## Removing unnecessary dependencies {/*removing-unnecessary-dependencies*/}
+## הסרת תלות מיותרת {/*הסרת-תלות-מיותרת*/}
-Every time you adjust the Effect's dependencies to reflect the code, look at the dependency list. Does it make sense for the Effect to re-run when any of these dependencies change? Sometimes, the answer is "no":
+בכל פעם שאתה מכוון את התלות של האפקט כדי לשקף את הקוד, עיין ברשימת התלות. האם הגיוני שהאפקט יפעל מחדש כאשר אחת מהתלות הללו משתנה? לפעמים התשובה היא "לא":
-* You might want to re-execute *different parts* of your Effect under different conditions.
-* You might want to only read the *latest value* of some dependency instead of "reacting" to its changes.
-* A dependency may change too often *unintentionally* because it's an object or a function.
+* אולי תרצה לבצע מחדש *חלקים שונים* מהאפקט שלך בתנאים שונים.
+* אולי תרצה לקרוא רק את *הערך האחרון* של תלות כלשהי במקום "להגיב" לשינויים שלה.
+* תלות עשויה להשתנות לעתים קרובות מדי *לא בכוונה* מכיוון שהיא אובייקט או פונקציה.
-To find the right solution, you'll need to answer a few questions about your Effect. Let's walk through them.
+כדי למצוא את הפתרון הנכון, תצטרך לענות על כמה שאלות לגבי האפקט שלך. בואו נעבור דרכם.
-### Should this code move to an event handler? {/*should-this-code-move-to-an-event-handler*/}
+### האם הקוד הזה צריך לעבור למטפל באירועים? {/*הקוד-הזה-צריך-לעבור-ל-an-event-handler*/}
-The first thing you should think about is whether this code should be an Effect at all.
+הדבר הראשון שאתה צריך לחשוב עליו הוא האם הקוד הזה צריך להיות אפקט בכלל.
-Imagine a form. On submit, you set the `submitted` state variable to `true`. You need to send a POST request and show a notification. You've put this logic inside an Effect that "reacts" to `submitted` being `true`:
+דמיינו צורה. בזמן השליחה, אתה מגדיר את הstate 'נשלח' ל-'true'. עליך לשלוח בקשת POST ולהציג הודעה. שמת את ההיגיון הזה בתוך אפקט ש"מגיב" בגלל ש'נשלח' הוא 'נכון':
```js {6-8}
function Form() {
@@ -394,7 +394,7 @@ function Form() {
}
```
-Later, you want to style the notification message according to the current theme, so you read the current theme. Since `theme` is declared in the component body, it is a reactive value, so you add it as a dependency:
+מאוחר יותר, תרצה לעצב את הדעת ההתראה לנושא הנוכחי, כך שתקרא את הנושא הנוכחי. מה ש'theme' מוצהר בגוף הרכיב, זה ערך תגובתי, אז אתה מוסיף אותו כתלות:
```js {3,9,11}
function Form() {
@@ -417,9 +417,9 @@ function Form() {
}
```
-By doing this, you've introduced a bug. Imagine you submit the form first and then switch between Dark and Light themes. The `theme` will change, the Effect will re-run, and so it will display the same notification again!
+על ידי כך, הצגת באג. תארו לעצמכם שאתם שולחים את הטופס תחילה ואז עוברים בין ערכות נושא כהות לבהירות. 'הנושא' ישתנה, האפקט יפעל מחדש, וכך הוא יציג שוב את אותה הודעה!
-**The problem here is that this shouldn't be an Effect in the first place.** You want to send this POST request and show the notification in response to *submitting the form,* which is a particular interaction. To run some code in response to particular interaction, put that logic directly into the corresponding event handler:
+**הבעיה כאן היא שזה לא אמור להיות אפקט מלכתחילה.** אתה רוצה לפרסם את בקשת ה-POST הזו ולהציג את ההודעה בת תגובה ל*שליחת הטופס,* שהיא אינטראקציה מסוימת. כדי להריץ נקודה בתגובה לאינטראקציה, הכנס את ההיגיון הזה למטפל המתאים:
```js {6-7}
function Form() {
@@ -435,13 +435,13 @@ function Form() {
}
```
-Now that the code is in an event handler, it's not reactive--so it will only run when the user submits the form. Read more about [choosing between event handlers and Effects](/learn/separating-events-from-effects#reactive-values-and-reactive-logic) and [how to delete unnecessary Effects.](/learn/you-might-not-need-an-effect)
+עכשיו, הוא נמצא באירוע, הוא אינו תגובתי - כך שהוא יפעל רק כאשר המשתמש ישלח את הטופס. קרא עוד על [בחירה בין רופאי אירועים לאפקטים](/learn/separating-events-from-effects#reactive-values-and-reactive-logic) ו[איך למחוק אפקטים מיותרים.](/learn/you-might-not-need-an-effect)
-### Is your Effect doing several unrelated things? {/*is-your-effect-doing-several-unrelated-things*/}
+### האם האפקט שלך עושה כמה דברים לא קשורים? {/*האם-האפקט-שלך-עושה-כמה-לא-קשורים-דברים*/}
-The next question you should ask yourself is whether your Effect is doing several unrelated things.
+השאלה הבאה שאתה צריך לשאול את עצמך היא האם האפקט שלך עושה כמה דברים לא קשורים.
-Imagine you're creating a shipping form where the user needs to choose their city and area. You fetch the list of `cities` from the server according to the selected `country` to show them in a dropdown:
+תאר לעצמך שאתה יוצר טופס משלוח שבו המשתמש צריך לבחור את העיר והאזור שלו. אתה מביא את רשימת ה'ערים' מהשרת לפי ה'state' שנבחרה כדי להציג אותן בתפריט נפתח:
```js
function ShippingForm({ country }) {
@@ -465,9 +465,9 @@ function ShippingForm({ country }) {
// ...
```
-This is a good example of [fetching data in an Effect.](/learn/you-might-not-need-an-effect#fetching-data) You are synchronizing the `cities` state with the network according to the `country` prop. You can't do this in an event handler because you need to fetch as soon as `ShippingForm` is displayed and whenever the `country` changes (no matter which interaction causes it).
+זו דוגמה טובה של [משיפת נתונים באפקט.](/learn/you-might-not-need-an-effect#fetching-data) אתה מסנכרן את מצב ה'ערים' עם הרשת לפי ה-country prop. אתה לא יכול לעשות זאת בטיפול באירועים כי אתה צריך לשלוף ברגע ש'ShippingForm' מוצג בכל פעם ש'הstate' משתנה (לא משנה איזו אינטראקציה גורמת לזה).
-Now let's say you're adding a second select box for city areas, which should fetch the `areas` for the currently selected `city`. You might start by adding a second `fetch` call for the list of areas inside the same Effect:
+כעת נניח שאתה מוסיף תיבת בחירה שנייה עבור אזורי ערים, שאמורה להביא את ה'אזורים' עבור ה'עיר' שנבחרה כעת. אתה יכול להתחיל בהוספת קריאת 'אחזור' שנייה עבור רשימת האזורים בתוך אותו אפקט:
```js {15-24,28}
function ShippingForm({ country }) {
@@ -502,14 +502,14 @@ function ShippingForm({ country }) {
// ...
```
-However, since the Effect now uses the `city` state variable, you've had to add `city` to the list of dependencies. That, in turn, introduced a problem: when the user selects a different city, the Effect will re-run and call `fetchCities(country)`. As a result, you will be unnecessarily refetching the list of cities many times.
+עם זאת, מה שהאפקט משתמש עכשיו בstate 'עיר' היית צריך להוסיף 'עיר' לרשימת התלות. זה, בתורו, הציג בעיה: כאשר המשתמש בוחר עיר אחרת, האפקט יפעל מחדש ויקרא 'fetchCities(country)'. כתוצאה מכך, תחזרו ללא רשימת הערים פעמים רבות.
-**The problem with this code is that you're synchronizing two different unrelated things:**
+**הבעיה עם הקוד הזה היא שאתה מסנכרן שני דברים שונים שאינם קשורים:**
-1. You want to synchronize the `cities` state to the network based on the `country` prop.
-1. You want to synchronize the `areas` state to the network based on the `city` state.
+1. אתה רוצה לסנכרן את מצב 'ערים' לרשת בהתבסס על מאפיין 'state'.
+1. אתה רוצה לסנכרן את מצב `אזורים` לרשת בהתבסס על מצב `עיר`.
-Split the logic into two Effects, each of which reacts to the prop that it needs to synchronize with:
+פצל את ההיגיון לשני אפקטים, שכל אחד מהם מגיב לprops שהוא צריך להסתנכרן איתו:
```js {19-33}
function ShippingForm({ country }) {
@@ -549,13 +549,13 @@ function ShippingForm({ country }) {
// ...
```
-Now the first Effect only re-runs if the `country` changes, while the second Effect re-runs when the `city` changes. You've separated them by purpose: two different things are synchronized by two separate Effects. Two separate Effects have two separate dependency lists, so they won't trigger each other unintentionally.
+כעת האפקט הראשון פועל מחדש רק אם ה'state' משתנה, בעוד שהאפקט השני פועל מחדש כאשר ה'עיר' משתנה. הפרדתם ביניהם לפי מטרה: שני דברים שונים מסונכרנים על ידי שני אפקטים נפרדים. לשני אפקטים נפרדים יש שתי רשימות תלות נפרדות, כך שהם לא יפעילו זה את זה בלי כוונה.
-The final code is longer than the original, but splitting these Effects is still correct. [Each Effect should represent an independent synchronization process.](/learn/lifecycle-of-reactive-effects#each-effect-represents-a-separate-synchronization-process) In this example, deleting one Effect doesn't break the other Effect's logic. This means they *synchronize different things,* and it's good to split them up. If you're concerned about duplication, you can improve this code by [extracting repetitive logic into a custom Hook.](/learn/reusing-logic-with-custom-hooks#when-to-use-custom-hooks)
+הקוד הסופי ארוך יותר מהמקור, אך פיסול האפקטים הללו עדיין נכון. [כל אפקט צריך לעשות סנכרון עצמאי.](/learn/lifecycle-of-reactive-effects#each-effect-represents-a-separate-synchronization-process) בדוגמה זו, מחיקת אפקט אחת אינה שוברת את ההיגיון של האפקט השני. זה אומר שהם *מסנכרנים דברים שונים,* וטוב לפצל אותם. אם אתה מודאג לגבי כפילות, אתה יכול לשפר את הקוד הזה על ידי [חילוץ לוגיקה חוזרת לתוך Hook מותאם אישית.](/learn/reusing-logic-with-custom-hooks#when-to-use-custom-hooks)
-### Are you reading some state to calculate the next state? {/*are-you-reading-some-state-to-calculate-the-next-state*/}
+### האם אתה קורא מצב כלשהו כדי לחשב את הstate הבא? {/*אתה-קורא-איזה-מצב-לחשב-את-הstate-הבא*/}
-This Effect updates the `messages` state variable with a newly created array every time a new message arrives:
+אפקט זה מעדכן את משתנה הstate 'הודעות' עם מערך חדש שנוצר בכל פעם שמגיעה הודעה חדשה:
```js {2,6-8}
function ChatRoom({ roomId }) {
@@ -569,7 +569,7 @@ function ChatRoom({ roomId }) {
// ...
```
-It uses the `messages` variable to [create a new array](/learn/updating-arrays-in-state) starting with all the existing messages and adds the new message at the end. However, since `messages` is a reactive value read by an Effect, it must be a dependency:
+הוא משתמש בשינוי 'הודעות' כדי [ליצור מערך חדש](/learn/updating-arrays-in-state) החל מכל ההודעות הגיש ומוסיף את ההודעה החדשה בסוף. עם זאת, מה ש'הודעות' הוא ערך תגובתי הנקרא על ידי אפקט, זה חייב להיות תלות:
```js {7,10}
function ChatRoom({ roomId }) {
@@ -585,11 +585,11 @@ function ChatRoom({ roomId }) {
// ...
```
-And making `messages` a dependency introduces a problem.
+והפיכת 'הודעות' לתלות מציגה בעיה.
-Every time you receive a message, `setMessages()` causes the component to re-render with a new `messages` array that includes the received message. However, since this Effect now depends on `messages`, this will *also* re-synchronize the Effect. So every new message will make the chat re-connect. The user would not like that!
+בכל פעם שאתה מקבל הודעה, `setMessages()` גורם להודעה לעיבוד מחדש עם מערך `הודעות` חדש המחובר את התקבלה. עם זאת, מה שהאפקט הזה תלוי עכשיו ב'הודעות', זה *גם* יסנכרן מחדש את האפקט. אז כל הודעה חדשה תגרום לצ'אט להתחבר מחדש. המשתמש לא היה אוהב את זה!
-To fix the issue, don't read `messages` inside the Effect. Instead, pass an [updater function](/reference/react/useState#updating-state-based-on-the-previous-state) to `setMessages`:
+כדי לתקן את הבעיה, אל תקראו 'הודעות' בתוך האפקט. במקום זאת, העבר [פונקציית עדכון](/reference/react/useState#updating-state-based-on-the-previous-state) אל `setMessages`:
```js {7,10}
function ChatRoom({ roomId }) {
@@ -605,17 +605,17 @@ function ChatRoom({ roomId }) {
// ...
```
-**Notice how your Effect does not read the `messages` variable at all now.** You only need to pass an updater function like `msgs => [...msgs, receivedMessage]`. React [puts your updater function in a queue](/learn/queueing-a-series-of-state-updates) and will provide the `msgs` argument to it during the next render. This is why the Effect itself doesn't need to depend on `messages` anymore. As a result of this fix, receiving a chat message will no longer make the chat re-connect.
+**שימו לב איך האפקט שלך לא קורא את השינוי 'הודעות' בכלל.** אתה רק צריך להעביר עכשיו פונקציית עדכון כמו 'msgs => [...msgs, receivedMessage]'. הגיבו [מכניסים את פונקציית העדכון שלך בתור](/learn/queueing-a-series-of-state-updates) ותספק לו את הארגומנט 'msgs' על העיבוד הבא. זה מה שהאפקט עצמו לא צריך להיות תלוי יותר ב'הודעות'. כמו תיקון זה, קבלת הודעת צ'אט לא תגרום עוד לצ'אט להתחבר מחדש.
-### Do you want to read a value without "reacting" to its changes? {/*do-you-want-to-read-a-value-without-reacting-to-its-changes*/}
+### האם אתה רוצה לקרוא ערך מבלי "להגיב" לשינויים שלו? {/*האם-אתה-רוצה-לקרוא-ערך-בלי-להגיב-לשינויים-שלו*/}
<Wip>
-This section describes an **experimental API that has not yet been released** in a stable version of React.
+סעיף זה מתאר **API ניסיוני שעדיין לא שוחרר** בגרסה יציבה של React.
</Wip>
-Suppose that you want to play a sound when the user receives a new message unless `isMuted` is `true`:
+נניח שאתה רוצה להשמיע צליל כשהמשתמש מקבל הודעה חדשה אלא אם כן `isMuted` הוא `true`:
```js {3,10-12}
function ChatRoom({ roomId }) {
@@ -634,7 +634,7 @@ function ChatRoom({ roomId }) {
// ...
```
-Since your Effect now uses `isMuted` in its code, you have to add it to the dependencies:
+מה שהאפקט שלך עכשיו ב-'isMuted' בקוד שלו, עליך להוסיף אותו לתלות:
```js {10,15}
function ChatRoom({ roomId }) {
@@ -655,9 +655,9 @@ function ChatRoom({ roomId }) {
// ...
```
-The problem is that every time `isMuted` changes (for example, when the user presses the "Muted" toggle), the Effect will re-synchronize, and reconnect to the chat. This is not the desired user experience! (In this example, even disabling the linter would not work--if you do that, `isMuted` would get "stuck" with its old value.)
+הבעיה היא שבכל פעם ש`isMuted` ranking (לדוגמה, כאשר משתמש לוחץ על הלחצן "Muted"), האפקט יסונכרן מחדש, ויתחבר מחדש לצ'אט. זו לא חוית משתמש הרצויה! (בדוגמה זו, אפילו השבתת ה-linter לא תעבוד - אם תעשה זאת, `isMuted` ייתקע עם הערך הישן שלו.)
-To solve this problem, you need to extract the logic that shouldn't be reactive out of the Effect. You don't want this Effect to "react" to the changes in `isMuted`. [Move this non-reactive piece of logic into an Effect Event:](/learn/separating-events-from-effects#declaring-an-effect-event)
+כדי לפתור בעיה זו, עליך לחלץ את ההיגיון שלא אמור להיות תגובתי מתוך האפקט. אתה לא רוצה שהאפקט הזה "יגיב" לשינויים ב-'isMuted'. [העבר את פיסת ההיגיון הלא תגובתית הזו לאירוע אפקט:](/learn/separating-events-from-effects#declaring-an-effect-event)
```js {1,7-12,18,21}
import { useState, useEffect, useEffectEvent } from 'react';
@@ -684,11 +684,11 @@ function ChatRoom({ roomId }) {
// ...
```
-Effect Events let you split an Effect into reactive parts (which should "react" to reactive values like `roomId` and their changes) and non-reactive parts (which only read their latest values, like `onMessage` reads `isMuted`). **Now that you read `isMuted` inside an Effect Event, it doesn't need to be a dependency of your Effect.** As a result, the chat won't re-connect when you toggle the "Muted" setting on and off, solving the original issue!
+אפקט אירועים מאפשרים לך לפצל אפקט לחלקים תגובתיים (שאמורים "להגיב" לערכים תגובתיים כמו `roomId` והשינויים שלהם) וחלקים לא תגובתיים (שקוראים רק את הערכים שלהם, כמו `onMessage` קורא `isMuted`). **עכשיו כאשר הקורא 'isMuted' בתוך אירוע אפקט, זה לא צריך להיות תלות של האפקט שלך.** כתוצאה מכך, הצ'אט לא יתחבר מחדש כאשר תפעיל או תכבה את ה"מושתק", ויפתור את הבעיה המקורית!
-#### Wrapping an event handler from the props {/*wrapping-an-event-handler-from-the-props*/}
+#### עטיפת מטפל באירועים מprops {/*לתוף-an-event-handler-from-the-props*/}
-You might run into a similar problem when your component receives an event handler as a prop:
+אתה עלול להיתקל בבעיה דומה כאשר הרכיב שלך מקבל מטפל באירועים כprops:
```js {1,8,11}
function ChatRoom({ roomId, onReceiveMessage }) {
@@ -705,7 +705,7 @@ function ChatRoom({ roomId, onReceiveMessage }) {
// ...
```
-Suppose that the parent component passes a *different* `onReceiveMessage` function on every render:
+נניח שרכיב מעביר פונקציית 'onReceiveMessage' *שונה* בכל עיבוד:
```js {3-5}
<ChatRoom
@@ -716,7 +716,7 @@ Suppose that the parent component passes a *different* `onReceiveMessage` functi
/>
```
-Since `onReceiveMessage` is a dependency, it would cause the Effect to re-synchronize after every parent re-render. This would make it re-connect to the chat. To solve this, wrap the call in an Effect Event:
+מה ש-'onReceiveMessage' הוא תלות, זה יגרום לאפקט להסתנכרן מחדש לאחר כל עיבוד מחדש של הורה. זה יגרום לו להתחבר מחדש לצ'אט. כדי לפתור זאת, עטוף את השיחה באירוע אפקט:
```js {4-6,12,15}
function ChatRoom({ roomId, onReceiveMessage }) {
@@ -737,13 +737,13 @@ function ChatRoom({ roomId, onReceiveMessage }) {
// ...
```
-Effect Events aren't reactive, so you don't need to specify them as dependencies. As a result, the chat will no longer re-connect even if the parent component passes a function that's different on every re-render.
+אירועי אפקט אינם ריאקטיביים, כך שאין צורך לציין אותם כתלות. כתוצאה מכך, הצ'אט כבר לא יתחבר מחדש גם אם רכיב האב יעביר פונקציה שונה בכל רינדור מחדש.
-#### Separating reactive and non-reactive code {/*separating-reactive-and-non-reactive-code*/}
+#### הפרדת קוד תגובתי וקוד לא תגובתי {/*מפריד-תגובתי-ולא-תגובתי-קוד*/}
-In this example, you want to log a visit every time `roomId` changes. You want to include the current `notificationCount` with every log, but you *don't* want a change to `notificationCount` to trigger a log event.
+בדוגמה זו, אתה רוצה לרשום ביקור בכל פעם ש-'roomId' מסתובב. אתה רוצה לכלול את ה-'notificationCount' הנוכחי עם כל יומן, אבל אתה *לא* רוצה לשנות ל-'notificationCount' כדי להפעיל אירוע יומן.
-The solution is again to split out the non-reactive code into an Effect Event:
+הפתרון הוא שוב לפצל את הקוד הלא תגובתי לאירוע אפקט:
```js {2-4,7}
function Chat({ roomId, notificationCount }) {
@@ -758,11 +758,11 @@ function Chat({ roomId, notificationCount }) {
}
```
-You want your logic to be reactive with regards to `roomId`, so you read `roomId` inside of your Effect. However, you don't want a change to `notificationCount` to log an extra visit, so you read `notificationCount` inside of the Effect Event. [Learn more about reading the latest props and state from Effects using Effect Events.](/learn/separating-events-from-effects#reading-latest-props-and-state-with-effect-events)
+אתה רוצה שההיגיון שלך יהיה תגובתי להתנגד ל-'roomId', אז אתה קורא 'roomId' בתוך האפקט שלך. עם זאת, אינך רוצה לשנות את 'notificationCount' כדי לרשום ביקור נוסף, אז אתה קורא את 'notificationCount' בתוך אירוע האפקט. [למידע נוסף על קריאת הprops וstate העדכניים ביותר מאפקטים באמצעות אפקט אירועים.](/learn/separating-events-from-effects#reading-latest-props-and-state-with-effect-events)
-### Does some reactive value change unintentionally? {/*does-some-reactive-value-change-unintentionally*/}
+### האם ערך תגובתי כלשהו משתנה ללא כוונה? {/*הערך-איזה-תגובתי-משתנה-ללא-כוונה*/}
-Sometimes, you *do* want your Effect to "react" to a certain value, but that value changes more often than you'd like--and might not reflect any actual change from the user's perspective. For example, let's say that you create an `options` object in the body of your component, and then read that object from inside of your Effect:
+לפעמים, אתה *דווקא* רוצה שהאפקט שלך "יגיב" לערך מסוים, אבל הערך הזה משתנה לעתים קרובות יותר ממה שאתה רוצה - ואולי לא ישקף שום שינוי ממשי מנקודת המבט של המשתמש. לדוגמה, נניח שאתה יוצר אובייקט 'אפשרויות' בגוף הרכיב שלך, ולאחר מכן קורא את האובייקט הזה מתוך האפקט שלך:
```js {3-6,9}
function ChatRoom({ roomId }) {
@@ -778,7 +778,7 @@ function ChatRoom({ roomId }) {
// ...
```
-This object is declared in the component body, so it's a [reactive value.](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values) When you read a reactive value like this inside an Effect, you declare it as a dependency. This ensures your Effect "reacts" to its changes:
+אובייקט זה מוצהר בגוף הרכיב, כך שהוא [ערך תגובתי.](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values) כאשר אתה קורא ערך תגובתי כזה בתוך אפקט, אתה מכריז עליו כתלות. זה מבטיח שהאפקט שלך "מגיב" לשינויים שלו:
```js {3,6}
// ...
@@ -790,7 +790,7 @@ This object is declared in the component body, so it's a [reactive value.](/lear
// ...
```
-It is important to declare it as a dependency! This ensures, for example, that if the `roomId` changes, your Effect will re-connect to the chat with the new `options`. However, there is also a problem with the code above. To see it, try typing into the input in the sandbox below, and watch what happens in the console:
+חשוב להכריז על כך כתלות! זה מבטיח, למשל, שאם ה-'roomId' משתנה, האפקט שלך יתחבר מחדש לצ'אט עם ה'אפשרויות' החדשות. עם זאת, יש גם בעיה עם הקוד שלמעלה. כדי לראות את זה, נסה להקליד את הקלט בארגז החול למטה, וצפה במה שקורה בקונסולה:
<Sandpack>
@@ -867,11 +867,11 @@ button { margin-left: 10px; }
</Sandpack>
-In the sandbox above, the input only updates the `message` state variable. From the user's perspective, this should not affect the chat connection. However, every time you update the `message`, your component re-renders. When your component re-renders, the code inside of it runs again from scratch.
+בארגז החול למעלה, הקלט מעדכן רק את משתנה הstate 'הודעה'. מנקודת המבט של המשתמש, זה לא אמור להשפיע על חיבור הצ'אט. עם זאת, בכל פעם שאתה מעדכן את ה'הודעה', הרכיב שלך מעבד מחדש. כאשר הרכיב שלך מעבד מחדש, הקוד שבתוכו פועל שוב מאפס.
-A new `options` object is created from scratch on every re-render of the `ChatRoom` component. React sees that the `options` object is a *different object* from the `options` object created during the last render. This is why it re-synchronizes your Effect (which depends on `options`), and the chat re-connects as you type.
+אובייקט `אפשרויות` חדש נוצר מאפס בכל עיבוד מחדש של רכיב `ChatRoom`. React רואה שאובייקט ה-'options' הוא *אובייקט שונה* מעצם ה-'options' חומר על העיבוד האחרון. אני חושב שהוא מסנכרן מחדש את האפקט שלך (התלוי ב'אפשרויות'), והצ'אט מתחבר מחדש תוך כדי הקלדה.
-**This problem only affects objects and functions. In JavaScript, each newly created object and function is considered distinct from all the others. It doesn't matter that the contents inside of them may be the same!**
+**בעיה זו משפיעה רק על אובייקטים ופונקציות. ב-JavaScript, כל אובייקט ופונקציה שהינו נחשבים שונים מכל האחרים. זה לא משנה שהתוכן בתוכם עשוי להיות זהה!**
```js {7-8}
// During the first render
@@ -884,13 +884,13 @@ const options2 = { serverUrl: 'https://localhost:1234', roomId: 'music' };
console.log(Object.is(options1, options2)); // false
```
-**Object and function dependencies can make your Effect re-synchronize more often than you need.**
+**תלות באובייקט ובפונקציה יכולה לגרום לאפקט שלך להסתנכרן מחדש לעתים קרובות יותר ממה שאתה צריך.**
-This is why, whenever possible, you should try to avoid objects and functions as your Effect's dependencies. Instead, try moving them outside the component, inside the Effect, or extracting primitive values out of them.
+זו הסיבה שבמידת האפשר, עליך לנסות להימנע מאובייקטים ומתפקדים כתלות של האפקט שלך. במקום זאת, נסה להעביר אותם מחוץ לרכיב, בתוך האפקט, או לחלץ מהם ערכים פרימיטיביים.
-#### Move static objects and functions outside your component {/*move-static-objects-and-functions-outside-your-component*/}
+#### הזז אובייקטים ופונקציות סטטיות מחוץ לרכיב שלך {/*move-static-objects-and-functions-outside-your-component*/}
-If the object does not depend on any props and state, you can move that object outside your component:
+אם האובייקט אינו תלוי בprops ובstate כלשהו, אתה יכול להעביר את האובייקט אל מחוץ לרכיב שלך:
```js {1-4,13}
const options = {
@@ -909,9 +909,9 @@ function ChatRoom() {
// ...
```
-This way, you *prove* to the linter that it's not reactive. It can't change as a result of a re-render, so it doesn't need to be a dependency. Now re-rendering `ChatRoom` won't cause your Effect to re-synchronize.
+בדרך זו, אתה *מוכיח* ל-לינטר שהוא לא תגובתי. זה לא יכול להשתנות כמו שצריך עיבוד מחדש, אז זה לא יכול להיות תלות. עיבוד מחדש של `ChatRoom` לא יגרום לאפקט מחדש.
-This works for functions too:
+זה עובד גם עבור פונקציות:
```js {1-6,12}
function createOptions() {
@@ -933,11 +933,11 @@ function ChatRoom() {
// ...
```
-Since `createOptions` is declared outside your component, it's not a reactive value. This is why it doesn't need to be specified in your Effect's dependencies, and why it won't ever cause your Effect to re-synchronize.
+מה ש-'createOptions' מוצהר מחוץ לרכיב שלך, זה לא ערך תגובתי. אתה צריך לציין אותו בתלות של האפקט, ומדוע זה לעולם לא יגרום לאפקט להסתנכרן מחדש.
-#### Move dynamic objects and functions inside your Effect {/*move-dynamic-objects-and-functions-inside-your-effect*/}
+#### הזז אובייקטים ופונקציות דינמיות בתוך האפקט שלך {/*move-dynamic-objects-and-functions-inside-your-effect*/}
-If your object depends on some reactive value that may change as a result of a re-render, like a `roomId` prop, you can't pull it *outside* your component. You can, however, move its creation *inside* of your Effect's code:
+אם האובייקט שלך תלוי בערך תגובתי שעשוי להשתנות כמו עיבוד מחדש, כמו props `roomId`, אתה לא יכול למשוך אותו *מחוץ* לרכיב שלך. עם זאת, אתה יכול להעביר את היצירה שלו *בתוך* הקוד של האפקט:
```js {7-10,11,14}
const serverUrl = 'https://localhost:1234';
@@ -957,7 +957,7 @@ function ChatRoom({ roomId }) {
// ...
```
-Now that `options` is declared inside of your Effect, it is no longer a dependency of your Effect. Instead, the only reactive value used by your Effect is `roomId`. Since `roomId` is not an object or function, you can be sure that it won't be *unintentionally* different. In JavaScript, numbers and strings are compared by their content:
+עכשיו, כאשר 'אפשרויות' מוכרזות בתוך האפקט שלך, זה כבר לא תלוי באפקט שלך. במקום זאת, הערך התגובתי היחיד המשמש את האפקט שלך הוא `roomId`. מה ש-'roomId' אינו אובייקט או פונקציה, אתה יכול להיות בטוח שהוא לא יהיה שונה *בלי כוונה*. ב-JavaScript, מספרים ומחרוזות מושווים לפי התוכן שלהם:
```js {7-8}
// During the first render
@@ -970,7 +970,7 @@ const roomId2 = 'music';
console.log(Object.is(roomId1, roomId2)); // true
```
-Thanks to this fix, the chat no longer re-connects if you edit the input:
+הודות לתיקון הזה, הצ'אט כבר לא מתחבר מחדש אם תערוך את הקלט:
<Sandpack>
@@ -1044,9 +1044,9 @@ button { margin-left: 10px; }
</Sandpack>
-However, it *does* re-connect when you change the `roomId` dropdown, as you would expect.
+עם זאת, הוא *מתחבר* מחדש כאשר אתה משנה את התפריט הנפתח 'roomId', כפי שהיית מצפה.
-This works for functions, too:
+זה עובד גם עבור פונקציות:
```js {7-12,14}
const serverUrl = 'https://localhost:1234';
@@ -1070,11 +1070,11 @@ function ChatRoom({ roomId }) {
// ...
```
-You can write your own functions to group pieces of logic inside your Effect. As long as you also declare them *inside* your Effect, they're not reactive values, and so they don't need to be dependencies of your Effect.
+אתה יכול לכתוב פונקציות משלך כדי לקבץ חלקי היגיון בתוך האפקט שלך. כל עוד אתה גם מצהיר עליהם *בתוך* האפקט שלך, הם לא ערכים תגובתיים, ולכן הם לא צריכים להיות תלות של האפקט שלך.
-#### Read primitive values from objects {/*read-primitive-values-from-objects*/}
+#### קרא ערכים פרימיטיביים מאובייקטים {/*קרא-פרימיטיבי-ערכים-מ-אובייקטים*/}
-Sometimes, you may receive an object from props:
+לפעמים, אתה עשוי לקבל חפץ מprops:
```js {1,5,8}
function ChatRoom({ options }) {
@@ -1088,7 +1088,7 @@ function ChatRoom({ options }) {
// ...
```
-The risk here is that the parent component will create the object during rendering:
+הסיכון כאן הוא שרכיב האב יצור את האובייקט במהלך העיבוד:
```js {3-6}
<ChatRoom
@@ -1100,7 +1100,7 @@ The risk here is that the parent component will create the object during renderi
/>
```
-This would cause your Effect to re-connect every time the parent component re-renders. To fix this, read information from the object *outside* the Effect, and avoid having object and function dependencies:
+זה יגרום לאפקט שלך להתחבר מחדש בכל פעם שרכיב האב מעבד מחדש. כדי לתקן זאת, קרא מידע מהאובייקט *מחוץ* לאפקט, והימנע מתלות של אובייקט ופונקציה:
```js {4,7-8,12}
function ChatRoom({ options }) {
@@ -1118,11 +1118,11 @@ function ChatRoom({ options }) {
// ...
```
-The logic gets a little repetitive (you read some values from an object outside an Effect, and then create an object with the same values inside the Effect). But it makes it very explicit what information your Effect *actually* depends on. If an object is re-created unintentionally by the parent component, the chat would not re-connect. However, if `options.roomId` or `options.serverUrl` really are different, the chat would re-connect.
+ההיגיון חוזר על עצמו מעט (אתה קורא כמה ערכים מחוץ לאפקט, ואז יוצר אובייקט עם אותם ערכים בתוך האפקט). אבל זה מבהיר מאוד באיזה מידע האפקט שלך *למעשה* תלוי. אם נוצר מחדש ללא כוונה על ידי רכיב האב, הצ'אט לא יתחבר מחדש. עם זאת, אם `options.roomId` או `options.serverUrl` באמת שונים, הצ'אט יתחבר מחדש.
-#### Calculate primitive values from functions {/*calculate-primitive-values-from-functions*/}
+#### חשב ערכים פרימיטיביים מפונקציות {/*חשב-פרימיטיבי-ערכים-מ-פונקציות*/}
-The same approach can work for functions. For example, suppose the parent component passes a function:
+אותה גישה יכולה לעבוד עבור פונקציות. לדוגמה, נניח שרכיב האב מעביר פונקציה:
```js {3-8}
<ChatRoom
@@ -1136,7 +1136,7 @@ The same approach can work for functions. For example, suppose the parent compon
/>
```
-To avoid making it a dependency (and causing it to re-connect on re-renders), call it outside the Effect. This gives you the `roomId` and `serverUrl` values that aren't objects, and that you can read from inside your Effect:
+כדי ללמוד מהפיכתו לתלות (ולגרום לו להתחבר מחדש בעיבוד מחדש), קרא לזה מחוץ לאפקט. זה נותן לך את הערכים `roomId` ו- `serverUrl` מבקשים, ושתוכל לקרוא מתוך האפקט שלך:
```js {1,4}
function ChatRoom({ getOptions }) {
@@ -1154,32 +1154,32 @@ function ChatRoom({ getOptions }) {
// ...
```
-This only works for [pure](/learn/keeping-components-pure) functions because they are safe to call during rendering. If your function is an event handler, but you don't want its changes to re-synchronize your Effect, [wrap it into an Effect Event instead.](#do-you-want-to-read-a-value-without-reacting-to-its-changes)
+זה עובד רק עבור פעולות [pure](/learn/keeping-components-pure) מה שבטוח לקרוא את העיבוד. אם הפונקציה שלך היא מטפלת באירועים, אך אינך רוצה לשנות את האפקט שלך.
<Recap>
-- Dependencies should always match the code.
-- When you're not happy with your dependencies, what you need to edit is the code.
-- Suppressing the linter leads to very confusing bugs, and you should always avoid it.
-- To remove a dependency, you need to "prove" to the linter that it's not necessary.
-- If some code should run in response to a specific interaction, move that code to an event handler.
-- If different parts of your Effect should re-run for different reasons, split it into several Effects.
-- If you want to update some state based on the previous state, pass an updater function.
-- If you want to read the latest value without "reacting" it, extract an Effect Event from your Effect.
-- In JavaScript, objects and functions are considered different if they were created at different times.
-- Try to avoid object and function dependencies. Move them outside the component or inside the Effect.
+- תלויות תמיד צריכות להתאים לקוד.
+- כאשר אתה לא מרוצה מהתלות שלך, מה שאתה צריך לערוך זה את הקוד.
+- דיכוי ה-linter מוביל לבאגים מאוד מבלים, ותמיד כדאי מאוד.
+- כדי להסיר תלות, אתה צריך "להוכיח" לבלינטר שזה לא הכרחי.
+- אם קוד מסוים אמור לפעול בתגובה לאינטראקציה ספציפית, העבר את הקוד למטפל באירועים.
+- אם חלקים שונים של האפקט שלך צריכים לפעול מחדש מסיבות שונות, פצל אותו למספר אפקטים.
+- אם ברצונך לעדכן מצב כלשהו בהתבסס על הstate הקודם, העבר פונקציית עדכון.
+- אם אתה רוצה לקרוא את הערך העדכני ביותר מבלי "להגיב" עליו, חלץ אירוע אפקט מהאפקט שלך.
+- ב-JavaScript, אובייקטים ופונקציות שונות אם הם נוצרו שונים.
+- נסו להימנע מתלות באובייקט ובתפקוד. הזז אותם מחוץ לרכיב או בתוך האפקט.
</Recap>
<Challenges>
-#### Fix a resetting interval {/*fix-a-resetting-interval*/}
+#### תקן מרווח איפוס {/*fix-a-resetting-interval*/}
-This Effect sets up an interval that ticks every second. You've noticed something strange happening: it seems like the interval gets destroyed and re-created every time it ticks. Fix the code so that the interval doesn't get constantly re-created.
+אפקט זה מגדיר מרווח שמתקתק כל שנייה. שמתם לב שמשהו מוזר קורה: נראה שהמרווח נהרס ונוצר מחדש בכל פעם שהוא מתקתק. תקן את הקוד כך שהמרווח לא ייווצר מחדש כל הזמן.
<Hint>
-It seems like this Effect's code depends on `count`. Is there some way to not need this dependency? There should be a way to update the `count` state based on its previous value without adding a dependency on that value.
+נראה שהקוד של אפקט זה תלוי ב'ספירה'. האם יש דרך לא להזדקק לתלות הזו? צריכה להיות דרך לעדכן את מצב 'ספירה' על סמך הערך הקודם שלו מבלי להוסיף תלות בערך זה.
</Hint>
@@ -1211,9 +1211,9 @@ export default function Timer() {
<Solution>
-You want to update the `count` state to be `count + 1` from inside the Effect. However, this makes your Effect depend on `count`, which changes with every tick, and that's why your interval gets re-created on every tick.
+אתה רוצה לעדכן את מצב 'ספירה' להיות 'ספירה + 1' מתוך האפקט. עם זאת, זה גורם לאפקט שלך להיות תלוי ב'ספירה', שמשתנה עם כל סימון, וזו הסיבה שהמרווח שלך נוצר מחדש בכל סימון.
-To solve this, use the [updater function](/reference/react/useState#updating-state-based-on-the-previous-state) and write `setCount(c => c + 1)` instead of `setCount(count + 1)`:
+כדי לפתור זאת, השתמש ב-[פונקציית העדכון](/reference/react/useState#updating-state-based-on-the-previous-state) וכתוב `setCount(c => c + 1)` במקום `setCount(count + 1)`:
<Sandpack>
@@ -1241,19 +1241,19 @@ export default function Timer() {
</Sandpack>
-Instead of reading `count` inside the Effect, you pass a `c => c + 1` instruction ("increment this number!") to React. React will apply it on the next render. And since you don't need to read the value of `count` inside your Effect anymore, so you can keep your Effect's dependencies empty (`[]`). This prevents your Effect from re-creating the interval on every tick.
+במקום לקרוא 'ספירה' האפקט, אתה מעביר בתוך הוראה 'c => c + 1' ("הגדל את המספר הזה!") ל-React. תגיב תחיל אותו בעיבוד הבא. ומכיוון שאינך צריך לקרוא יותר את הערך של `ספירה` בתוך האפקט שלך, אז אתה יכול לשמור על התלות של האפקט שלך (`[]`). זה מונע מהאפקט שלך ליצור מחדש את הרווח בכל סימון.
</Solution>
-#### Fix a retriggering animation {/*fix-a-retriggering-animation*/}
+#### תקן אנימציה מפעילה מחדש {/*fix-a-retriggering-animation*/}
-In this example, when you press "Show", a welcome message fades in. The animation takes a second. When you press "Remove", the welcome message immediately disappears. The logic for the fade-in animation is implemented in the `animation.js` file as plain JavaScript [animation loop.](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame) You don't need to change that logic. You can treat it as a third-party library. Your Effect creates an instance of `FadeInAnimation` for the DOM node, and then calls `start(duration)` or `stop()` to control the animation. The `duration` is controlled by a slider. Adjust the slider and see how the animation changes.
+בדוגמה זו, כאשר אתה לוחץ על "הצג", הודעת פתיחה נמוגה פנימה. ההנפשה נמשכת שניה. כאשר אתה לוחץ על "הסר", הודעת הפתיחה נעלמת מיד. ההיגיון של הנפשה הדהייה מיושמת בקובץ `animation.js` כ-JavaScript רגיל [לולאת אנימציה.](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame) אינך צריך לשנות את ההיגיון הזה. אתה יכול להתייחס אליו כאל ספריית צד שלישי. האפקט שלך נוצר מופע של 'FadeInAnimation' עבור צומת ה-DOM, קורא ל'start(duration)' או 'stop()' כדי לשלוט בהנפשה. ה'משך' נשלט על ידי מחוון. התאם את המחוון וראה כיצד האנימציה משתנה.
-This code already works, but there is something you want to change. Currently, when you move the slider that controls the `duration` state variable, it retriggers the animation. Change the behavior so that the Effect does not "react" to the `duration` variable. When you press "Show", the Effect should use the current `duration` on the slider. However, moving the slider itself should not by itself retrigger the animation.
+הקוד הזה כבר עובד, אבל יש משהו שאתה רוצה לשנות. נכון לעכשיו, כאשר אתה מזיז את המחוון השולט בשינוי הstate 'משך', הוא מפעיל מחדש את האנימציה. שנה את ההתנהגות כך שהאפקט לא "יגיב" לשינוי `משך`. כאשר אתה לוחץ על "הצג", האפקט להשתמש במשך הנוכחי במחוון. עם זאת, הזזת המחוון עצמו לא אמורה כשלעצמה להפעיל את האנימציה.
<Hint>
-Is there a line of code inside the Effect that should not be reactive? How can you move non-reactive code out of the Effect?
+האם יש שורת קוד בתוך האפקט שלא אמורה להיות תגובתית? איך אתה יכול להעביר קוד לא תגובתי מהאפקט?
</Hint>
@@ -1382,7 +1382,7 @@ html, body { min-height: 300px; }
<Solution>
-Your Effect needs to read the latest value of `duration`, but you don't want it to "react" to changes in `duration`. You use `duration` to start the animation, but starting animation isn't reactive. Extract the non-reactive line of code into an Effect Event, and call that function from your Effect.
+האפקט שלך צריך לקרוא את הערך האחרון של `duration`, אבל אתה לא רוצה שהוא "יגיב" לשינויים ב-`duration`. אתה משתמש ב-'duration' כדי להתחיל את האנימציה, אבל התחלת האנימציה אינה תגובתית. חלץ את שורת הקוד הלא תגובתית ל- Effect Event, וקרא לפונקציה הזו מהאפקט שלך.
<Sandpack>
@@ -1505,19 +1505,19 @@ html, body { min-height: 300px; }
</Sandpack>
-Effect Events like `onAppear` are not reactive, so you can read `duration` inside without retriggering the animation.
+אירועי אפקט כמו 'onAppear' הם ריאקטיביים, כך קראו 'משך' בפנים שלא להפעיל מחדש את האנימציה.
</Solution>
-#### Fix a reconnecting chat {/*fix-a-reconnecting-chat*/}
+#### תקן צ'אט שמתחבר מחדש {/*fix-a-reconnecting-chat*/}
-In this example, every time you press "Toggle theme", the chat re-connects. Why does this happen? Fix the mistake so that the chat re-connects only when you edit the Server URL or choose a different chat room.
+בדוגמה זו, בכל פעם שאתה לוחץ על "החלפת נושא", הצ'אט מתחבר מחדש. למה זה קורה? תקן את הטעות כך שהצ'אט יתחבר מחדש כאשר אתה רק עורך את כתובת ה-URL של השרת או בוחר חדר צ'אט אחר.
-Treat `chat.js` as an external third-party library: you can consult it to check its API, but don't edit it.
+פשוט אל `chat.js` ספריית צד שלישי חיצונית: אתה יכול להתייעץ בה כדי לבדוק את ה-API שלה, אך אל תערוך אותו.
<Hint>
-There's more than one way to fix this, but ultimately you want to avoid having an object as your dependency.
+יש יותר מדרך אחת לתקן את זה, אבל בסופו של דבר אתה רוצה להימנע מעצם התלות שלך.
</Hint>
@@ -1611,9 +1611,9 @@ label, button { display: block; margin-bottom: 5px; }
<Solution>
-Your Effect is re-running because it depends on the `options` object. Objects can be re-created unintentionally, you should try to avoid them as dependencies of your Effects whenever possible.
+האפקט שלך פועל מחדש מכיוון שהוא תלוי באובייקט 'אפשרויות'. ניתן ליצור מחדש אובייקטים ללא כוונה, אתה צריך לנסות להימנע מהם כתלות של האפקטים שלך במידת האפשר.
-The least invasive fix is to read `roomId` and `serverUrl` right outside the Effect, and then make the Effect depend on those primitive values (which can't change unintentionally). Inside the Effect, create an object and pass it to `createConnection`:
+התיקון הכי פחות פולשני הוא לקרוא את `roomId` ו`serverUrl` ממש מחוץ לאפקט, כאשר הוא לגרום לאפקט להיות תלוי בערכים הפרימיטיביים הללו (שלא יכול להשתנות ללא כוונה). בתוך האפקט, צור אובייקט והעביר אותו ל-'createConnection':
<Sandpack>
@@ -1707,7 +1707,7 @@ label, button { display: block; margin-bottom: 5px; }
</Sandpack>
-It would be even better to replace the object `options` prop with the more specific `roomId` and `serverUrl` props:
+עדיף אפילו להחליף את הprops ה-'options' של האובייקט בprops הספציפיים יותר של 'roomId' ו-'serverUrl':
<Sandpack>
@@ -1798,25 +1798,25 @@ label, button { display: block; margin-bottom: 5px; }
</Sandpack>
-Sticking to primitive props where possible makes it easier to optimize your components later.
+היצמדות לprops פרימיטיביים במידת האפשר מקלה על אופטימיזציה של הרכיבים שלך מאוחר יותר.
</Solution>
-#### Fix a reconnecting chat, again {/*fix-a-reconnecting-chat-again*/}
+#### תקן צ'אט שמתחבר מחדש, שוב {/*fix-a-reconnecting-chat-again*/}
-This example connects to the chat either with or without encryption. Toggle the checkbox and notice the different messages in the console when the encryption is on and off. Try changing the room. Then, try toggling the theme. When you're connected to a chat room, you will receive new messages every few seconds. Verify that their color matches the theme you've picked.
+דוגמה זו מתחברת לצ'אט עם או בלי הצפנה. החלף את תיבת הסימון והבחין בהודעות השונות במסוף כאשר ההצפנה מופעלת ומכבה. נסה לשנות את החדר. לאחר מכן, נסה לשנות את ערכת הנושא. כאשר אתה מחובר לחדר צ'אט, תקבל הודעות חדשות כל כמה שניות. ודא שהצבע שלהם מתאים לנושא שבחרת.
-In this example, the chat re-connects every time you try to change the theme. Fix this. After the fix, changing the theme should not re-connect the chat, but toggling encryption settings or changing the room should re-connect.
+בדוגמה זו, הצ'אט מתחבר מחדש בכל פעם שאתה מנסה לשנות את הנושא. תקן את זה. לאחר התיקון, שינוי ערכת הנושא לא אמור לחבר מחדש את הצ'אט, אבל החלפת הגדרות ההצפנה או שינוי החדר אמורה להתחבר מחדש.
-Don't change any code in `chat.js`. Other than that, you can change any code as long as it results in the same behavior. For example, you may find it helpful to change which props are being passed down.
+אל תשנה שום קוד ב- `chat.js`. מלבד זאת, אתה יכול לשנות את כל הקוד. לדוגמה, יכול שיעזור לך לשנות אילו props מועברים.
<Hint>
-You're passing down two functions: `onMessage` and `createConnection`. Both of them are created from scratch every time `App` re-renders. They are considered to be new values every time, which is why they re-trigger your Effect.
+אתה מעביר שתי פונקציות: `onMessage` ו-`createConnection`. שניהם נוצרים מאפס בכל פעם ש'אפליקציה' מעבדת מחדש. הם חשובים לערכים חדשים בכל פעם, וחושבים שהם מפעילים מחדש את האפקט שלך.
-One of these functions is an event handler. Do you know some way to call an event handler an Effect without "reacting" to the new values of the event handler function? That would come in handy!
+אחת מהפונקציות הללו היא מטפל באירועים. האם אתה מכיר דרך כלשהי לקרוא למטפל באירועים אפקט מבלי "להגיב" לערכים החדשים של פונקציית מטפל האירועים? זה יהיה שימושי!
-Another of these functions only exists to pass some state to an imported API method. Is this function really necessary? What is the essential information that's being passed down? You might need to move some imports from `App.js` to `ChatRoom.js`.
+עוד אחת מהפונקציות הללו קיימת רק כדי לספק מצב לשיטת API מיובאת. האם הפונקציה הזו באמת נחוצה? מהו החיוני שמועבר? אתה צריך להעביר חלק מהי יבוא מ-'App.js' ל-'ChatRoom.js'.
</Hint>
@@ -2031,11 +2031,11 @@ label, button { display: block; margin-bottom: 5px; }
<Solution>
-There's more than one correct way to solve this, but here is one possible solution.
+יש יותר מדרך אחת נכונה לפתור את זה, אבל הנה פתרון אפשרי אחד.
-In the original example, toggling the theme caused different `onMessage` and `createConnection` functions to be created and passed down. Since the Effect depended on these functions, the chat would re-connect every time you toggle the theme.
+בדוגמה המקורית, החלפת ערכת הנושא גרמה להעביר פונקציות שונות של 'onMessage' ו-'createConnection'. מה שהאפקט הוא תלוי בפונקציות הללו, זה יתחבר בכל פעם שתחליף את הנושא.
-To fix the problem with `onMessage`, you needed to wrap it into an Effect Event:
+כדי לתקן את הבעיה עם 'onMessage', היית צריך לתת אותה באירוע אפקט:
```js {1,2,6}
export default function ChatRoom({ roomId, createConnection, onMessage }) {
@@ -2047,9 +2047,9 @@ export default function ChatRoom({ roomId, createConnection, onMessage }) {
// ...
```
-Unlike the `onMessage` prop, the `onReceiveMessage` Effect Event is not reactive. This is why it doesn't need to be a dependency of your Effect. As a result, changes to `onMessage` won't cause the chat to re-connect.
+קיים לprops 'onMessage', אירוע אפקט 'onReceiveMessage' אינו תגובתי. זה מה שזה לא צריך להיות תלות של האפקט שלך. כתוצאה מכך, שינויים ב-'onMessage' לא יגרמו לצ'אט להתחבר מחדש.
-You can't do the same with `createConnection` because it *should* be reactive. You *want* the Effect to re-trigger if the user switches between an encrypted and an unencryption connection, or if the user switches the current room. However, because `createConnection` is a function, you can't check whether the information it reads has *actually* changed or not. To solve this, instead of passing `createConnection` down from the `App` component, pass the raw `roomId` and `isEncrypted` values:
+אתה לא יכול לעשות את זה עם `createConnection` כי זה *צריך* להיות תגובתי. אתה *רוצה* שהאפקט יופעל מחדש אם המשתמש עובר בין חיבור מוצפן לחיבור ללא הצפנה, או אם המשתמש יחליף את החדר הנוכחי. עם זאת, מה ש-'createConnection' היא פונקציה, אתה לא יכול לבדוק שהיא קוראת השתנה *בפועל* או לא. כדי לפתור זאת, במקום להעביר את 'createConnection' מהרכיב 'אפליקציה', העבירו את הערכים הגולמיים של 'roomId' ו-'isEncrypted':
```js {2-3}
<ChatRoom
@@ -2061,7 +2061,7 @@ You can't do the same with `createConnection` because it *should* be reactive. Y
/>
```
-Now you can move the `createConnection` function *inside* the Effect instead of passing it down from the `App`:
+עכשיו אתה יכול להעביר את הפונקציה 'createConnection' *בתוך* האפקט במקום להעביר אותה מ'האפליקציה':
```js {1-4,6,10-20}
import {
@@ -2087,7 +2087,7 @@ export default function ChatRoom({ roomId, isEncrypted, onMessage }) {
// ...
```
-After these two changes, your Effect no longer depends on any function values:
+לאחר שני השינויים האלה, האפקט שלך כבר לא תלוי בערכי פונקציה כלשהם:
```js {1,8,10,21}
export default function ChatRoom({ roomId, isEncrypted, onMessage }) { // Reactive values
@@ -2113,7 +2113,7 @@ export default function ChatRoom({ roomId, isEncrypted, onMessage }) { // Reacti
}, [roomId, isEncrypted]); // ✅ All dependencies declared
```
-As a result, the chat re-connects only when something meaningful (`roomId` or `isEncrypted`) changes:
+כתוצאה מכך, הצ'אט מתחבר מחדש רק כאשר משהו משמעותי (`roomId` או `isEncrypted`) ranking:
<Sandpack>
@@ -2332,3 +2332,4 @@ label, button { display: block; margin-bottom: 5px; }
</Solution>
</Challenges>
+
diff --git a/src/content/learn/render-and-commit.md b/src/content/learn/render-and-commit.md
index 3f0593599..7b6f1926c 100644
--- a/src/content/learn/render-and-commit.md
+++ b/src/content/learn/render-and-commit.md
@@ -1,44 +1,44 @@
---
-title: Render and Commit
+title: "רינדור ו-Commit"
---
<Intro>
-Before your components are displayed on screen, they must be rendered by React. Understanding the steps in this process will help you think about how your code executes and explain its behavior.
+לפני שהקומפוננטות שלכם מוצגות על המסך, הם חייבים לעבור רינדור על ידי React. הבנת שלבי תרופות זה תעזור לכם איך הקוד שלכם רץ ולהסביר את ההתנהגות שלו.
</Intro>
<YouWillLearn>
-* What rendering means in React
-* When and why React renders a component
-* The steps involved in displaying a component on screen
-* Why rendering does not always produce a DOM update
+* מה השפעה של רינדור ב-React
+* מתי ולמה תגובה מרנדרת קומפוננטה
+* מהם השלבים שכוללים הצגה של קומפוננטה על המסך
+* למה רינדור לא תמיד מייצר עדכון DOM
</YouWillLearn>
-Imagine that your components are cooks in the kitchen, assembling tasty dishes from ingredients. In this scenario, React is the waiter who puts in requests from customers and brings them their orders. This process of requesting and serving UI has three steps:
+דמיינו שהקומפוננטות שלכם טבחים במטבח שהן מהן מנות טעימות מהן. בתרחיש הזה, React הוא המלצר שמקבל הזמנות מהלקוחות ומביא להם את המנות. בקשה של בקשה והגשה של UI כולל שלושה שלבים:
-1. **Triggering** a render (delivering the guest's order to the kitchen)
-2. **Rendering** the component (preparing the order in the kitchen)
-3. **Committing** to the DOM (placing the order on the table)
+1. **הפעלה (הפעלה)** רינדור (העברת הזמנת הלקוח למטבח)
+2. **רינדור (עיבוד)** הקומפוננטה (הכנת ההזמנה במטבח)
+3. **ביצוע Commit L-DOM (Committing)** (הנחת ההזמנה על השולחן)
<IllustrationBlock sequential>
- <Illustration caption="Trigger" alt="React as a server in a restaurant, fetching orders from the users and delivering them to the Component Kitchen." src="/images/docs/illustrations/i_render-and-commit1.png" />
- <Illustration caption="Render" alt="The Card Chef gives React a fresh Card component." src="/images/docs/illustrations/i_render-and-commit2.png" />
- <Illustration caption="Commit" alt="React delivers the Card to the user at their table." src="/images/docs/illustrations/i_render-and-commit3.png" />
+ <Illustration caption="טריגר" alt="React בתור מלצר במסעדה: לוקח הזמנות מהמשתמשים ומעביר אותן למטבח הקומפוננטות." src="/images/docs/illustrations/i_render-and-commit1.png" />
+ <Illustration caption="רינדור" alt="השף של כרטיס (Card) נותן ל-React קומפוננטת Card חדשה." src="/images/docs/illustrations/i_render-and-commit2.png" />
+ <Illustration caption="קומיט" alt="React מגישה את כרטיס ה-Card למשתמש בשולחן." src="/images/docs/illustrations/i_render-and-commit3.png" />
</IllustrationBlock>
-## Step 1: Trigger a render {/*step-1-trigger-a-render*/}
+## שלב 1: טריגר לרינדור {/*step-1-trigger-a-render*/}
-There are two reasons for a component to render:
+יש שתי סיבות לרינדור של קומפוננטה:
-1. It's the component's **initial render.**
-2. The component's (or one of its ancestors') **state has been updated.**
+1. זהו **הרינדור הראשוני** של הקומפוננטה.
+2. ה-**מצב של הקומפוננטה** (או של אחד מהאבות שלה) עודכן.
-### Initial render {/*initial-render*/}
+### רינדור ראשוני {/*initial-render*/}
-When your app starts, you need to trigger the initial render. Frameworks and sandboxes sometimes hide this code, but it's done by calling [`createRoot`](/reference/react-dom/client/createRoot) with the target DOM node, and then calling its `render` method with your component:
+כשהאפליקציה מתחילה, צריך להפעיל את הרינדור הראשוני. מסגרות ו-sandboxes לפעמים מסתירים את הקוד הזה, אבל הוא מתקדם על ידי קריאה ל-[`createRoot`](/reference/react-dom/client/createRoot) עם צומת DOM יעד, ואז קריאה קודמת שלו עם הקומפוננטה שלכם:
<Sandpack>
@@ -63,28 +63,28 @@ export default function Image() {
</Sandpack>
-Try commenting out the `root.render()` call and see the component disappear!
+נסו להעיר את הקריאה ל-`root.render()` ותראו את הקומפוננטה נעלמת!
-### Re-renders when state updates {/*re-renders-when-state-updates*/}
+### רינדורים חוזרים כש-state מתעדכן {/*re-renders-when-state-updates*/}
-Once the component has been initially rendered, you can trigger further renders by updating its state with the [`set` function.](/reference/react/useState#setstate) Updating your component's state automatically queues a render. (You can imagine these as a restaurant guest ordering tea, dessert, and all sorts of things after putting in their first order, depending on the state of their thirst or hunger.)
+לאחר שהקומפוננטה רונדרה לראשונה, אפשר להפעיל רינדורים נוספים על ידי עדכון מצב עם [פונקציית `set`.](/reference/react/useState#setstate) עדכון ה-state של הקומפוננטה מכניס רינדור לתור אוטומטי אוטומטי. (אפשר להדמיין זאת כאורח במסעדה שמזמין תה, קינוח ועוד דברים אחרי ההזמנה הראשונה, לפי רמת הצמא או הרעב שלו.)
<IllustrationBlock sequential>
- <Illustration caption="State update..." alt="React as a server in a restaurant, serving a Card UI to the user, represented as a patron with a cursor for their head. They patron expresses they want a pink card, not a black one!" src="/images/docs/illustrations/i_rerender1.png" />
- <Illustration caption="...triggers..." alt="React returns to the Component Kitchen and tells the Card Chef they need a pink Card." src="/images/docs/illustrations/i_rerender2.png" />
- <Illustration caption="...render!" alt="The Card Chef gives React the pink Card." src="/images/docs/illustrations/i_rerender3.png" />
+ <Illustration caption="עדכון state..." alt="React כמלצר במסעדה מגיש למשתמש ממשק Card. המשתמש מבקש כרטיס ורוד במקום שחור." src="/images/docs/illustrations/i_rerender1.png" />
+ <Illustration caption="...מפעיל..." alt="React חוזרת למטבח הקומפוננטות ואומרת לשף של Card שצריך כרטיס ורוד." src="/images/docs/illustrations/i_rerender2.png" />
+ <Illustration caption="...רינדור!" alt="שף ה-Card נותן ל-React את הכרטיס הוורוד." src="/images/docs/illustrations/i_rerender3.png" />
</IllustrationBlock>
-## Step 2: React renders your components {/*step-2-react-renders-your-components*/}
+## שלב 2: תגובה מרנדרת את הקומפוננטות שלכם {/*step-2-react-renders-your-components*/}
-After you trigger a render, React calls your components to figure out what to display on screen. **"Rendering" is React calling your components.**
+אחרי שהפעלתם רינדור, הגיבו קוראת לקומפוננטות שלכם כדי להבין מה להציג על המסך. **"עיבוד" הוא תגובה שקוראת לקומפוננטות שלכם.**
-* **On initial render,** React will call the root component.
-* **For subsequent renders,** React will call the function component whose state update triggered the render.
+* **ברינדור הראשוני,** React תקרא לקומפוננת השורש.
+* **ברינדורים הבאים,** תגובה תקרא לקומפוננטת הפונקציה שעדכון ה-state שלה הפעיל את הרינדור.
-This process is recursive: if the updated component returns some other component, React will render _that_ component next, and if that component also returns something, it will render _that_ component next, and so on. The process will continue until there are no more nested components and React knows exactly what should be displayed on screen.
+עשה רקורסיביות: אם הקומפוננטה שעודכנה מחזירה קומפוננטה אחרת, React תרנדר *אותה* בהמשך, ואם גם הקומפוננטה הזו מחזירה משהו, React תרנדר *גם אותו* בהמשך, וכן הלאה. צריך יימשך עד שאין יותר קומפוננטות קוננות ו-React יודע בדיוק מה צריך להיות מוצג על המסך.
-In the following example, React will call `Gallery()` and `Image()` several times:
+בדוגמה הבאה, React תקרא ל-`Gallery()` ול-`Image()` כמה פעמים:
<Sandpack>
@@ -124,36 +124,36 @@ img { margin: 0 10px 10px 0; }
</Sandpack>
-* **During the initial render,** React will [create the DOM nodes](https://developer.mozilla.org/docs/Web/API/Document/createElement) for `<section>`, `<h1>`, and three `<img>` tags.
-* **During a re-render,** React will calculate which of their properties, if any, have changed since the previous render. It won't do anything with that information until the next step, the commit phase.
+* **ברינדור הראשוני,** React תיצור את [DOM nodes](https://developer.mozilla.org/docs/Web/API/Document/createElement) עבור ``<section>``, ``<h1>``, ושלוש תגיות ``<img>``.
+* **בריינדור חוזר,** React תחשב אילו מאפיינים (אם בכלל) השתנו מאז הרינדור הקודם. היא לא תעשה עם זה דבר עד לשלב הבא, שלב ה-commit.
<Pitfall>
-Rendering must always be a [pure calculation](/learn/keeping-components-pure):
+עיבוד חייב תמיד להיות [חישוב טהור](/learn/keeping-components-pure):
-* **Same inputs, same output.** Given the same inputs, a component should always return the same JSX. (When someone orders a salad with tomatoes, they should not receive a salad with onions!)
-* **It minds its own business.** It should not change any objects or variables that existed before rendering. (One order should not change anyone else's order.)
+* **אותם קלטים, אותו פלט.** בהינתן אותם קלטים, קומפוננטה צריכה תמיד להחזיר אותו JSX. (אם מישהו יזמין סלט עם עגבניות, הוא לא אמור לקבל סלט עם בצל!)
+* **היא מתעסקת בעניינים שלה.** היא לא צריכה לשנות אובייקטים או משתנים שהיו קיימים לפני הרינדור. (הזמנה אחת לא אמורה לשנות את ההזמנה של מישהו אחר.)
-Otherwise, you can encounter confusing bugs and unpredictable behavior as your codebase grows in complexity. When developing in "Strict Mode", React calls each component's function twice, which can help surface mistakes caused by impure functions.
+אחרת, אתם צריכים להיתקל בבאגים מבלבלים ובהתנהגות לא צפויה ככל הקוד שאתם גדלים ומסתבך. בפיתוח ב-"Strict Mode", תגובה קוראת לפונקציה של כל קומפוננטה פעמיים, מה שיכול לעזור לחשוף טעויות שנובעות מפונקציות לא טהורות.
</Pitfall>
<DeepDive>
-#### Optimizing performance {/*optimizing-performance*/}
+#### אופטימיזציית ביצועים {/*אופטימיזציה-ביצועים*/}
-The default behavior of rendering all components nested within the updated component is not optimal for performance if the updated component is very high in the tree. If you run into a performance issue, there are several opt-in ways to solve it described in the [Performance](https://reactjs.org/docs/optimizing-performance.html) section. **Don't optimize prematurely!**
+התנהגות ברירת המחדל של רינדור. אם אתם נתקלים בבעיית ביצועים, יש כמה דרכים אופציונליות לפתור כפי אותה שמתואר בחלק [Performance](https://reactjs.org/docs/optimizing-performance.html). **אל תבצעו אופטימיזציה מוקדם מדי!**
</DeepDive>
-## Step 3: React commits changes to the DOM {/*step-3-react-commits-changes-to-the-dom*/}
+## שלב 3: React מבצעת commit לשינויים ב-DOM {/*step-3-react-commits-changes-to-the-dom*/}
-After rendering (calling) your components, React will modify the DOM.
+אחרי רינדור (קריאה) של הקומפוננטות, תגיב תשנה את ה-DOM.
-* **For the initial render,** React will use the [`appendChild()`](https://developer.mozilla.org/docs/Web/API/Node/appendChild) DOM API to put all the DOM nodes it has created on screen.
-* **For re-renders,** React will apply the minimal necessary operations (calculated while rendering!) to make the DOM match the latest rendering output.
+* **בריינדור הראשוני,** React תשתמש ב-API של DOM בשם [`appendChild()`](https://developer.mozilla.org/docs/Web/API/Node/appendChild) כדי לשים על המסך את כל ה-DOM nodes שיצרה.
+* **ברינדורים חוזרים,** React תחיל את הפעולות המינימליות בזמן (שחושבו הרינדור!) כדי ל-DOM להתאים להתאים הרינדור העדכני.
-**React only changes the DOM nodes if there's a difference between renders.** For example, here is a component that re-renders with different props passed from its parent every second. Notice how you can add some text into the `<input>`, updating its `value`, but the text doesn't disappear when the component re-renders:
+**הגיב משנה DOM צמתי רק אם יש הבדל בין רינדורים.** לדוגמה, הנה קומפוננטה שמרונדרת מחדש עם props שונים שמועברים מההורה כל השניה. שימו לב שאפשר לאפשר טקסט בתוך ``<input>``, ולעדכן את ה-`value` שלו, אבל הטקסט לא נעלם כשהקומפוננטה מרונדרת מחדש:
<Sandpack>
@@ -193,21 +193,21 @@ export default function App() {
</Sandpack>
-This works because during this last step, React only updates the content of `<h1>` with the new `time`. It sees that the `<input>` appears in the JSX in the same place as last time, so React doesn't touch the `<input>`—or its `value`!
-## Epilogue: Browser paint {/*epilogue-browser-paint*/}
+זה עובד כי זה האחרון הזה תגובה מעדכנת רק את התוכן של ``<h1>`` עם `זמן` החדש. היא רואה ש-`<input>`` מופיעה ב-JSX באותו מקום כמו פעם הקודמת, אז תגיב לא נוגעת ב-``<input>`` — או ב-`value` שלו!
+## אפילוג: צביעת הדפדפן {/*epilogue-browser-paint*/}
-After rendering is done and React updated the DOM, the browser will repaint the screen. Although this process is known as "browser rendering", we'll refer to it as "painting" to avoid confusion throughout the docs.
+אחרי שהרינדור הסתיים ו-React עדכנה את ה-DOM, הדפדפן יצבע מחדש את המסך. למרות שהתהליך הזה מוכר כ-"עיבוד דפדפן", אנחנו קוראים לו "ציור" כדי למנוע בלבול בתיעוד.
-<Illustration alt="A browser painting 'still life with card element'." src="/images/docs/illustrations/i_browser-paint.png" />
+<Illustration alt="דפדפן שמבצע צביעה מחדש של המסך לאחר עדכון DOM." src="/images/docs/illustrations/i_browser-paint.png" />
<Recap>
-* Any screen update in a React app happens in three steps:
- 1. Trigger
- 2. Render
- 3. Commit
-* You can use Strict Mode to find mistakes in your components
-* React does not touch the DOM if the rendering result is the same as last time
+* כל עדכון מסך באפליקציית תגובה מתרחשת בשלושה שלבים:
+ 1. טריגר (טריגר)
+ 2. רנדר (רינדור)
+ 3. Commit (קומיט)
+* אפשר להשתמש ב-Strict Mode כדי למצוא טעויות בקומפוננטות
+* תגיב לא נוגעת ב-DOM אם תוצאת הרינדור זה לפעם הקודמת
</Recap>
diff --git a/src/content/learn/reusing-logic-with-custom-hooks.md b/src/content/learn/reusing-logic-with-custom-hooks.md
index 13a556c7b..d694efd47 100644
--- a/src/content/learn/reusing-logic-with-custom-hooks.md
+++ b/src/content/learn/reusing-logic-with-custom-hooks.md
@@ -1,30 +1,30 @@
---
-title: 'Reusing Logic with Custom Hooks'
+title: "שימוש חוזר בלוגיקה עם ווים מותאמים"
---
<Intro>
-React comes with several built-in Hooks like `useState`, `useContext`, and `useEffect`. Sometimes, you'll wish that there was a Hook for some more specific purpose: for example, to fetch data, to keep track of whether the user is online, or to connect to a chat room. You might not find these Hooks in React, but you can create your own Hooks for your application's needs.
+React מגיע עם כמה Hooks מובנים כמו `useState`, `useContext` ו-`useEffect`. לפעמים, תרצה שיהיה Hook למטרה ספציפית יותר: למשל, להביא נתונים, לעקוב אם המשתמש מחובר או להתחבר לחדר צ'אט. אולי לא תמצא את ה-Hooks ב-React, אבל אתה יכול ליצור Hooks משלך לצרכי היישום שלך.
</Intro>
<YouWillLearn>
-- What custom Hooks are, and how to write your own
-- How to reuse logic between components
-- How to name and structure your custom Hooks
-- When and why to extract custom Hooks
+- מה הם הHooks מותאמים אישית ואיך לכתוב בעצמך
+- כיצד לעשות שימוש חוזר בלוגיקה בין רכיבים
+- איך לתת שם ולבנות את הווים המותאמים אישית שלך
+- מתי ומדוע לחלץ ווים מותאמים אישית
</YouWillLearn>
-## Custom Hooks: Sharing logic between components {/*custom-hooks-sharing-logic-between-components*/}
+## ווים מותאמים אישית: שיתוף היגיון בין רכיבים {/*custom-hooks-sharing-logic-between-components*/}
-Imagine you're developing an app that heavily relies on the network (as most apps do). You want to warn the user if their network connection has accidentally gone off while they were using your app. How would you go about it? It seems like you'll need two things in your component:
+תארו לעצמכם שאתם מפתחים אפליקציה שנשענת במידה רבה על הרשת (כמו שרוב האפליקציות עושות). אתה רוצה להזהיר את המשתמש אם חיבור הרשת שלו כבה בטעות בזמן שהוא השתמש באפליקציה שלך. איך היית מתנהלת? נראה שתצטרך שני דברים ברכיב שלך:
-1. A piece of state that tracks whether the network is online.
-2. An Effect that subscribes to the global [`online`](https://developer.mozilla.org/en-US/docs/Web/API/Window/online_event) and [`offline`](https://developer.mozilla.org/en-US/docs/Web/API/Window/offline_event) events, and updates that state.
+1. פיסת state שעוקבת אחר האם הרשת מקוונת.
+2. אפקט שנרשם לאירועים הגלובליים [`מקוון`](https://developer.mozilla.org/en-US/docs/Web/API/Window/online_event) ו-[`offline`](https://developer.mozilla.org/en-US/docs/Web/API/Window/offline_event).
-This will keep your component [synchronized](/learn/synchronizing-with-effects) with the network status. You might start with something like this:
+זה ישמור את הרכיב שלך [מסונכרן](/learn/synchronizing-with-effects) עם סטטוס הרשת. אתה יכול להתחיל עם משהו כזה:
<Sandpack>
@@ -54,11 +54,11 @@ export default function StatusBar() {
</Sandpack>
-Try turning your network on and off, and notice how this `StatusBar` updates in response to your actions.
+נסה להפעיל ולכבות את הרשת שלך, ושם לב כיצד 'סרגל הstate' הזה מתעדכן בתגובה לפעולות שלך.
-Now imagine you *also* want to use the same logic in a different component. You want to implement a Save button that will become disabled and show "Reconnecting..." instead of "Save" while the network is off.
+עכשיו דמיינו שאתם *גם* רוצים להשתמש באותו היגיון ברכיב אחר. ברצונך ליישם כפתור שמירה שיהפוך לבלתי זמין ויראה "מתחבר מחדש..." במקום "שמור" בזמן שהרשת כבויה.
-To start, you can copy and paste the `isOnline` state and the Effect into `SaveButton`:
+כדי להתחיל, אתה יכול להעתיק ולהדביק את מצב `isOnline` ואת האפקט לתוך `SaveButton`:
<Sandpack>
@@ -96,13 +96,13 @@ export default function SaveButton() {
</Sandpack>
-Verify that, if you turn off the network, the button will change its appearance.
+ודא שאם תכבה את הרשת, הכפתור ישנה את מראהו.
-These two components work fine, but the duplication in logic between them is unfortunate. It seems like even though they have different *visual appearance,* you want to reuse the logic between them.
+שני הרכיבים האלה עובדים מצוין, אבל הכפילות בלוגיקה ביניהם היא מצערת. נראה שלמרות שיש להם *מראה חזותי* שונה, אתה רוצה לעשות שימוש חוזר בהיגיון ביניהם.
-### Extracting your own custom Hook from a component {/*extracting-your-own-custom-hook-from-a-component*/}
+### חילוץ Hook מותאם אישית משלך מרכיב {/*חילוץ-שלך-מתאים-מותאם-אישית-מ-a-component*/}
-Imagine for a moment that, similar to [`useState`](/reference/react/useState) and [`useEffect`](/reference/react/useEffect), there was a built-in `useOnlineStatus` Hook. Then both of these components could be simplified and you could remove the duplication between them:
+תארו לעצמכם לרגע שבדומה ל-[`useState`](/reference/react/useState) ו-[`useEffect`](/reference/react/useEffect), היה Hook של `useOnlineStatus` מובנה. אז ניתן יהיה לפשט את שני הרכיבים הללו ולהסיר את הכפילות ביניהם:
```js {2,7}
function StatusBar() {
@@ -125,7 +125,7 @@ function SaveButton() {
}
```
-Although there is no such built-in Hook, you can write it yourself. Declare a function called `useOnlineStatus` and move all the duplicated code into it from the components you wrote earlier:
+למרות שאין Hook מובנה כזה, אתה יכול לכתוב את זה בעצמך. הכריז על פונקציה בשם `useOnlineStatus` והעבר לתוכה את כל הקוד המשוכפל מהרכיבים שכתבת קודם:
```js {2-16}
function useOnlineStatus() {
@@ -148,7 +148,7 @@ function useOnlineStatus() {
}
```
-At the end of the function, return `isOnline`. This lets your components read that value:
+בסוף הפונקציה, החזר `isOnline`. זה מאפשר לרכיבים שלך לקרוא את הערך הזה:
<Sandpack>
@@ -209,36 +209,36 @@ export function useOnlineStatus() {
</Sandpack>
-Verify that switching the network on and off updates both components.
+ודא כי הפעלה וכיבוי של הרשת מעדכנת את שני הרכיבים.
-Now your components don't have as much repetitive logic. **More importantly, the code inside them describes *what they want to do* (use the online status!) rather than *how to do it* (by subscribing to the browser events).**
+כעת לרכיבים שלך אין כל כך הרבה היגיון חוזר. **חשוב מכך, הקוד בתוכם מתאר *מה הם רוצים לעשות* (השתמשו בסטטוס המקוון!) במקום *איך לעשות זאת* (על ידי הרשמה לאירועי הדפדפן).**
-When you extract logic into custom Hooks, you can hide the gnarly details of how you deal with some external system or a browser API. The code of your components expresses your intent, not the implementation.
+כאשר אתה מחלץ היגיון לתוך Hooks מותאמים אישית, אתה יכול להסתיר את הפרטים המסובכים של איך אתה מתמודד עם מערכת חיצונית כלשהי או API של דפדפן. הקוד של הרכיבים שלך מבטא את כוונתך, לא את היישום.
-### Hook names always start with `use` {/*hook-names-always-start-with-use*/}
+### שמות Hook תמיד מתחילים ב-`use` {/*hook-names-always-start-with-use*/}
-React applications are built from components. Components are built from Hooks, whether built-in or custom. You'll likely often use custom Hooks created by others, but occasionally you might write one yourself!
+יישומי React בנויים מרכיבים. רכיבים בנויים מ-Hooks, בין אם מובנים או מותאמים אישית. סביר להניח שלעתים קרובות תשתמש ב-Hooks מותאמים אישית שנוצרו על ידי אחרים, אבל לפעמים אתה עשוי לכתוב אחד בעצמך!
-You must follow these naming conventions:
+עליך לפעול לפי מוסכמות השמות הבאות:
-1. **React component names must start with a capital letter,** like `StatusBar` and `SaveButton`. React components also need to return something that React knows how to display, like a piece of JSX.
-2. **Hook names must start with `use` followed by a capital letter,** like [`useState`](/reference/react/useState) (built-in) or `useOnlineStatus` (custom, like earlier on the page). Hooks may return arbitrary values.
+1. **שמות רכיבי React חייבים להתחיל באות גדולה,** כמו 'StatusBar' ו-'SaveButton'. רכיבי React צריכים גם להחזיר משהו שראקט יודע להציג, כמו חתיכת JSX.
+2. **שמות Hook חייבים להתחיל ב-`use` ואחריו באות גדולה,** כמו [`useState`](/reference/react/useState) (מובנה) או `useOnlineStatus` (מותאם אישית, כמו קודם בדף). הHooks עשויים להחזיר ערכים שרירותיים.
-This convention guarantees that you can always look at a component and know where its state, Effects, and other React features might "hide". For example, if you see a `getColor()` function call inside your component, you can be sure that it can't possibly contain React state inside because its name doesn't start with `use`. However, a function call like `useOnlineStatus()` will most likely contain calls to other Hooks inside!
+מוסכמה זו מבטיחה שתמיד תוכל להסתכל על רכיב ולדעת היכן מצבו, אפקטים ושאר תכונות React עשויות "להסתתר". לדוגמה, אם אתה רואה קריאה לפונקציה `getColor()` בתוך הרכיב שלך, אתה יכול להיות בטוח שהיא לא יכולה להכיל מצב React בפנים כי השם שלה לא מתחיל ב-`use`. עם זאת, קריאת פונקציה כמו `useOnlineStatus()` תכיל ככל הנראה קריאות ל-Hooks אחרים בפנים!
<Note>
-If your linter is [configured for React,](/learn/editor-setup#linting) it will enforce this naming convention. Scroll up to the sandbox above and rename `useOnlineStatus` to `getOnlineStatus`. Notice that the linter won't allow you to call `useState` or `useEffect` inside of it anymore. Only Hooks and components can call other Hooks!
+אם ה-linter שלך הוא [מוגדר עבור React,](/learn/editor-setup#linting) הוא יאכוף את מוסכמות השמות הזו. גלול למעלה אל ארגז החול למעלה ושנה את השם של 'useOnlineStatus' ל'getOnlineStatus'. שימו לב שה-linter לא יאפשר לכם לקרוא 'useState' או 'useEffect' בתוכו יותר. רק הHooks ורכיבים יכולים לקרוא לHooks אחרים!
</Note>
<DeepDive>
-#### Should all functions called during rendering start with the use prefix? {/*should-all-functions-called-during-rendering-start-with-the-use-prefix*/}
+#### האם כל הפונקציות שנקראות במהלך העיבוד צריכות להתחיל בקידומת השימוש? {/*צריך-כל-הפונקציות-שנקראות-במהלך-רינדור-להתחיל-עם-the-use-prefix*/}
-No. Functions that don't *call* Hooks don't need to *be* Hooks.
+לא. פונקציות שלא *קוראות* לHooks לא צריכות *להיות* Hooks.
-If your function doesn't call any Hooks, avoid the `use` prefix. Instead, write it as a regular function *without* the `use` prefix. For example, `useSorted` below doesn't call Hooks, so call it `getSorted` instead:
+אם הפונקציה שלך לא קוראת לאף Hooks, הימנע מקידומת 'שימוש'. במקום זאת, כתוב אותה כפונקציה רגילה *ללא* הקידומת 'שימוש'. לדוגמה, 'useSorted' למטה לא קורא Hooks, אז קרא לזה 'getSorted' במקום זאת:
```js
// 🔴 Avoid: A Hook that doesn't use Hooks
@@ -252,7 +252,7 @@ function getSorted(items) {
}
```
-This ensures that your code can call this regular function anywhere, including conditions:
+זה מבטיח שהקוד שלך יכול לקרוא לפונקציה הרגילה הזו בכל מקום, כולל תנאים:
```js
function List({ items, shouldSort }) {
@@ -265,7 +265,7 @@ function List({ items, shouldSort }) {
}
```
-You should give `use` prefix to a function (and thus make it a Hook) if it uses at least one Hook inside of it:
+עליך לתת קידומת 'use' לפונקציה (ובכך להפוך אותה ל-Hook) אם היא משתמשת לפחות Hook אחד בתוכה:
```js
// ✅ Good: A Hook that uses other Hooks
@@ -274,7 +274,7 @@ function useAuth() {
}
```
-Technically, this isn't enforced by React. In principle, you could make a Hook that doesn't call other Hooks. This is often confusing and limiting so it's best to avoid that pattern. However, there may be rare cases where it is helpful. For example, maybe your function doesn't use any Hooks right now, but you plan to add some Hook calls to it in the future. Then it makes sense to name it with the `use` prefix:
+מבחינה טכנית, זה לא נאכף על ידי React. באופן עקרוני, אתה יכול לעשות Hook שלא קורא לHook אחרים. זה לעתים קרובות מבלבל ומגביל ולכן עדיף להימנע מהדפוס הזה. עם זאת, ייתכנו מקרים נדירים שבהם זה מועיל. לדוגמה, אולי הפונקציה שלך לא משתמשת באף Hooks כרגע, אבל אתה מתכנן להוסיף לה כמה שיחות Hook בעתיד. אז הגיוני לתת לזה שם עם הקידומת 'שימוש':
```js {3-4}
// ✅ Good: A Hook that will likely use some other Hooks later
@@ -285,13 +285,13 @@ function useAuth() {
}
```
-Then components won't be able to call it conditionally. This will become important when you actually add Hook calls inside. If you don't plan to use Hooks inside it (now or later), don't make it a Hook.
+אז רכיבים לא יוכלו לקרוא לזה מותנה. זה יהפוך חשוב כאשר אתה באמת מוסיף שיחות Hook פנימה. אם אינכם מתכננים להשתמש בHooks בתוכו (עכשיו או מאוחר יותר), אל תהפכו אותו לHook.
</DeepDive>
-### Custom Hooks let you share stateful logic, not state itself {/*custom-hooks-let-you-share-stateful-logic-not-state-itself*/}
+### ווים מותאמים מאפשרים לך לשתף היגיון מצבי, לא להגדיר את עצמו {/*custom-hooks-let-you-share-stateful-logic-not-state-itself*/}
-In the earlier example, when you turned the network on and off, both components updated together. However, it's wrong to think that a single `isOnline` state variable is shared between them. Look at this code:
+בדוגמה הקודמת, כאשר הפעלת וכיבית את הרשת, שני הרכיבים עודכנו יחד. עם זאת, זה לא נכון לחשוב שמשתנה מצב 'isOnline' יחיד משותף ביניהם. תסתכל על הקוד הזה:
```js {2,7}
function StatusBar() {
@@ -305,7 +305,7 @@ function SaveButton() {
}
```
-It works the same way as before you extracted the duplication:
+זה עובד באותו אופן כמו לפני שחילצת את הכפילות:
```js {2-5,10-13}
function StatusBar() {
@@ -325,9 +325,9 @@ function SaveButton() {
}
```
-These are two completely independent state variables and Effects! They happened to have the same value at the same time because you synchronized them with the same external value (whether the network is on).
+אלו שני משתני מצב ואפקטים בלתי תלויים לחלוטין! במקרה היה להם אותו ערך בו-זמנית כי סינכרנתם אותם עם אותו ערך חיצוני (בין אם הרשת מופעלת).
-To better illustrate this, we'll need a different example. Consider this `Form` component:
+כדי להמחיש זאת טוב יותר, נצטרך דוגמה אחרת. שקול את רכיב ה'טופס' הזה:
<Sandpack>
@@ -369,13 +369,13 @@ input { margin-left: 10px; }
</Sandpack>
-There's some repetitive logic for each form field:
+יש היגיון שחוזר על עצמו עבור כל שדה טופס:
-1. There's a piece of state (`firstName` and `lastName`).
-1. There's a change handler (`handleFirstNameChange` and `handleLastNameChange`).
-1. There's a piece of JSX that specifies the `value` and `onChange` attributes for that input.
+1. יש פיסת state (`שם פרטי` ו`שם משפחה`).
+1. יש מטפל בשינוי (`handleFirstNameChange` ו-`handleLastNameChange`).
+1. יש קטע של JSX שמציין את התכונות 'ערך' ו-'onChange' עבור הקלט הזה.
-You can extract the repetitive logic into this `useFormInput` custom Hook:
+אתה יכול לחלץ את ההיגיון החוזר על ה-Hook המותאם אישית של 'useFormInput':
<Sandpack>
@@ -428,9 +428,9 @@ input { margin-left: 10px; }
</Sandpack>
-Notice that it only declares *one* state variable called `value`.
+שימו לב שהוא מכריז רק על משתנה מצב *אחד* בשם 'ערך'.
-However, the `Form` component calls `useFormInput` *two times:*
+עם זאת, הרכיב 'Form' קורא 'useFormInput' *פעמיים:*
```js
function Form() {
@@ -439,17 +439,17 @@ function Form() {
// ...
```
-This is why it works like declaring two separate state variables!
+זו הסיבה שזה עובד כמו הכרזה על שני משתני מצב נפרדים!
-**Custom Hooks let you share *stateful logic* but not *state itself.* Each call to a Hook is completely independent from every other call to the same Hook.** This is why the two sandboxes above are completely equivalent. If you'd like, scroll back up and compare them. The behavior before and after extracting a custom Hook is identical.
+**Custom Hooks מאפשרים לך לשתף *היגיון מצבי* אבל לא *לציין את עצמו.* כל קריאה ל-Hook עצמאית לחלוטין מכל קריאה אחרת לאותו Hook.** זו הסיבה ששתי ארגזי החול שלמעלה שוות לחלוטין. אם תרצה, גלול חזרה למעלה והשווה ביניהם. ההתנהגות לפני ואחרי חילוץ Hook מותאם אישית זהה.
-When you need to share the state itself between multiple components, [lift it up and pass it down](/learn/sharing-state-between-components) instead.
+כאשר אתה צריך לשתף את הstate עצמו בין רכיבים מרובים, [הרם אותו והעביר אותו למטה](/learn/sharing-state-between-components) במקום זאת.
-## Passing reactive values between Hooks {/*passing-reactive-values-between-hooks*/}
+## העברת ערכים תגובתיים בין Hooks {/*העברת-reactive-values-between-hooks*/}
-The code inside your custom Hooks will re-run during every re-render of your component. This is why, like components, custom Hooks [need to be pure.](/learn/keeping-components-pure) Think of custom Hooks' code as part of your component's body!
+הקוד בתוך Hooks המותאמים אישית שלך יפעל מחדש במהלך כל רינדור מחדש של הרכיב שלך. זו הסיבה, כמו רכיבים, Hooks מותאמים אישית [צריכים להיות טהורים.](/learn/keeping-components-pure) חשבו על הקוד המותאם אישית של Hooks כחלק מגוף הרכיב שלכם!
-Because custom Hooks re-render together with your component, they always receive the latest props and state. To see what this means, consider this chat room example. Change the server URL or the chat room:
+מכיוון שה-Hooks מותאמים אישית מעבדים מחדש יחד עם הרכיב שלך, הם תמיד מקבלים את הprops וstate העדכניים ביותר. כדי לראות מה זה אומר, שקול את הדוגמה הזו לחדר צ'אט. שנה את כתובת האתר של השרת או את חדר הצ'אט:
<Sandpack>
@@ -599,9 +599,9 @@ button { margin-left: 10px; }
</Sandpack>
-When you change `serverUrl` or `roomId`, the Effect ["reacts" to your changes](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values) and re-synchronizes. You can tell by the console messages that the chat re-connects every time that you change your Effect's dependencies.
+כאשר אתה משנה `serverUrl` או `roomId`, האפקט ["מגיב" לשינויים שלך](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values) ומסתנכרן מחדש. אתה יכול לראות לפי הודעות המסוף שהצ'אט מתחבר מחדש בכל פעם שאתה משנה את התלות של האפקט שלך.
-Now move the Effect's code into a custom Hook:
+כעת העבר את הקוד של האפקט ל-Hook מותאם אישית:
```js {2-13}
export function useChatRoom({ serverUrl, roomId }) {
@@ -620,7 +620,7 @@ export function useChatRoom({ serverUrl, roomId }) {
}
```
-This lets your `ChatRoom` component call your custom Hook without worrying about how it works inside:
+זה מאפשר לרכיב `ChatRoom` שלך לקרוא ל-Hook המותאם אישית שלך מבלי לדאוג איך זה עובד בפנים:
```js {4-7}
export default function ChatRoom({ roomId }) {
@@ -643,9 +643,9 @@ export default function ChatRoom({ roomId }) {
}
```
-This looks much simpler! (But it does the same thing.)
+זה נראה הרבה יותר פשוט! (אבל זה עושה את אותו הדבר.)
-Notice that the logic *still responds* to prop and state changes. Try editing the server URL or the selected room:
+שימו לב שההיגיון *עדיין מגיב* לשינויי תמיכה וstate. נסה לערוך את כתובת האתר של השרת או את החדר שנבחר:
<Sandpack>
@@ -807,7 +807,7 @@ button { margin-left: 10px; }
</Sandpack>
-Notice how you're taking the return value of one Hook:
+שים לב איך אתה לוקח את ערך ההחזר של Hook אחד:
```js {2}
export default function ChatRoom({ roomId }) {
@@ -820,7 +820,7 @@ export default function ChatRoom({ roomId }) {
// ...
```
-and pass it as an input to another Hook:
+והעבירו אותו כקלט לHook אחר:
```js {6}
export default function ChatRoom({ roomId }) {
@@ -833,17 +833,17 @@ export default function ChatRoom({ roomId }) {
// ...
```
-Every time your `ChatRoom` component re-renders, it passes the latest `roomId` and `serverUrl` to your Hook. This is why your Effect re-connects to the chat whenever their values are different after a re-render. (If you ever worked with audio or video processing software, chaining Hooks like this might remind you of chaining visual or audio effects. It's as if the output of `useState` "feeds into" the input of the `useChatRoom`.)
+בכל פעם שרכיב `ChatRoom` שלך מעבד מחדש, הוא מעביר את `roomId` ואת `serverUrl` העדכניים ביותר ל-Hook שלך. זו הסיבה שהאפקט שלך מתחבר מחדש לצ'אט בכל פעם שהערכים שלהם שונים לאחר עיבוד מחדש. (אם אי פעם עבדת עם תוכנת עיבוד אודיו או וידאו, שרשור Hooks כזה עשוי להזכיר לך שרשור אפקטים ויזואליים או אודיו. זה כאילו הפלט של `useState` "מוזן" לקלט של `useChatRoom`.)
-### Passing event handlers to custom Hooks {/*passing-event-handlers-to-custom-hooks*/}
+### העברת מטפלי אירועים ל-Hooks מותאמים אישית {/*passing-event-handlers-to-custom-hooks*/}
<Wip>
-This section describes an **experimental API that has not yet been released** in a stable version of React.
+סעיף זה מתאר **API ניסיוני שעדיין לא שוחרר** בגרסה יציבה של React.
</Wip>
-As you start using `useChatRoom` in more components, you might want to let components customize its behavior. For example, currently, the logic for what to do when a message arrives is hardcoded inside the Hook:
+ככל שתתחיל להשתמש ב-'useChatRoom' ברכיבים נוספים, אולי תרצה לאפשר לרכיבים להתאים אישית את ההתנהגות שלו. לדוגמה, נכון לעכשיו, ההיגיון של מה לעשות כשמגיעה הודעה מקודד בתוך ה-Hook:
```js {9-11}
export function useChatRoom({ serverUrl, roomId }) {
@@ -862,7 +862,7 @@ export function useChatRoom({ serverUrl, roomId }) {
}
```
-Let's say you want to move this logic back to your component:
+נניח שאתה רוצה להעביר את ההיגיון הזה בחזרה לרכיב שלך:
```js {7-9}
export default function ChatRoom({ roomId }) {
@@ -878,7 +878,7 @@ export default function ChatRoom({ roomId }) {
// ...
```
-To make this work, change your custom Hook to take `onReceiveMessage` as one of its named options:
+כדי לגרום לזה לעבוד, שנה את ה-Hook המותאם אישית שלך כדי לקחת את 'onReceiveMessage' כאחת מהאפשרויות הנקראות שלו:
```js {1,10,13}
export function useChatRoom({ serverUrl, roomId, onReceiveMessage }) {
@@ -897,9 +897,9 @@ export function useChatRoom({ serverUrl, roomId, onReceiveMessage }) {
}
```
-This will work, but there's one more improvement you can do when your custom Hook accepts event handlers.
+זה יעבוד, אבל יש עוד שיפור אחד שאתה יכול לעשות כאשר ה-Hook המותאם אישית שלך מקבל מטפלי אירועים.
-Adding a dependency on `onReceiveMessage` is not ideal because it will cause the chat to re-connect every time the component re-renders. [Wrap this event handler into an Effect Event to remove it from the dependencies:](/learn/removing-effect-dependencies#wrapping-an-event-handler-from-the-props)
+הוספת תלות ב-'onReceiveMessage' אינה אידיאלית מכיוון שהיא תגרום לצ'אט להתחבר מחדש בכל פעם שהרכיב מעבד מחדש. [עטפו את מטפל האירוע הזה לתוך אירוע אפקט כדי להסיר אותו מהתלות:](/learn/removing-effect-dependencies#wrapping-an-event-handler-from-the-props)
```js {1,4,5,15,18}
import { useEffect, useEffectEvent } from 'react';
@@ -923,7 +923,7 @@ export function useChatRoom({ serverUrl, roomId, onReceiveMessage }) {
}
```
-Now the chat won't re-connect every time that the `ChatRoom` component re-renders. Here is a fully working demo of passing an event handler to a custom Hook that you can play with:
+כעת הצ'אט לא יתחבר מחדש בכל פעם שרכיב `ChatRoom` מעבד מחדש. הנה הדגמה עובדת מלאה של העברת מטפל באירועים לHook מותאם אישית שתוכל לשחק איתו:
<Sandpack>
@@ -1091,15 +1091,15 @@ button { margin-left: 10px; }
</Sandpack>
-Notice how you no longer need to know *how* `useChatRoom` works in order to use it. You could add it to any other component, pass any other options, and it would work the same way. That's the power of custom Hooks.
+שים לב איך אתה כבר לא צריך לדעת *איך* `useChatRoom` עובד כדי להשתמש בו. אתה יכול להוסיף אותו לכל רכיב אחר, להעביר כל אופציה אחרת, וזה יעבוד באותה צורה. זה הכוח של הHooks מותאמים אישית.
-## When to use custom Hooks {/*when-to-use-custom-hooks*/}
+## מתי להשתמש ב-Hooks מותאמים אישית {/*when-to-use-custom-hooks*/}
-You don't need to extract a custom Hook for every little duplicated bit of code. Some duplication is fine. For example, extracting a `useFormInput` Hook to wrap a single `useState` call like earlier is probably unnecessary.
+אינך צריך לחלץ Hook מותאם אישית עבור כל פיסת קוד משוכפלת קטנה. כמה כפילות זה בסדר. לדוגמה, חילוץ `useFormInput` Hook כדי לכרוך קריאת `useState` בודדת כמו קודם הוא כנראה מיותר.
-However, whenever you write an Effect, consider whether it would be clearer to also wrap it in a custom Hook. [You shouldn't need Effects very often,](/learn/you-might-not-need-an-effect) so if you're writing one, it means that you need to "step outside React" to synchronize with some external system or to do something that React doesn't have a built-in API for. Wrapping it into a custom Hook lets you precisely communicate your intent and how the data flows through it.
+עם זאת, בכל פעם שאתה כותב אפקט, שקול אם יהיה ברור יותר לעטוף אותו גם בHook מותאם אישית. [לא צריך אפקטים לעתים קרובות מאוד,](/learn/you-might-not-need-an-effect) אז אם אתה כותב אחד, זה אומר שאתה צריך "לצאת מחוץ ל-React" כדי להסתנכרן עם מערכת חיצונית כלשהי או לעשות משהו של-React אין API מובנה עבורו. לעטוף אותו לתוך Hook מותאם אישית מאפשר לך לתקשר במדויק את כוונתך וכיצד הנתונים זורמים דרכו.
-For example, consider a `ShippingForm` component that displays two dropdowns: one shows the list of cities, and another shows the list of areas in the selected city. You might start with some code that looks like this:
+לדוגמה, שקול רכיב `ShippingForm` המציג שתי תפריטים נפתחים: אחד מציג את רשימת הערים, ואחר מציג את רשימת האזורים בעיר שנבחרה. אתה יכול להתחיל עם איזה קוד שנראה כך:
```js {3-16,20-35}
function ShippingForm({ country }) {
@@ -1141,7 +1141,7 @@ function ShippingForm({ country }) {
// ...
```
-Although this code is quite repetitive, [it's correct to keep these Effects separate from each other.](/learn/removing-effect-dependencies#is-your-effect-doing-several-unrelated-things) They synchronize two different things, so you shouldn't merge them into one Effect. Instead, you can simplify the `ShippingForm` component above by extracting the common logic between them into your own `useData` Hook:
+למרות שהקוד הזה די חוזר על עצמו, [נכון לשמור על אפקטים אלה נפרדים זה מזה.](/learn/removing-effect-dependencies#is-your-effect-doing-several-unrelated-things) הם מסנכרנים שני דברים שונים, אז לא כדאי למזג אותם לאפקט אחד. במקום זאת, אתה יכול לפשט את רכיב `ShippingForm` למעלה על ידי חילוץ ההיגיון המשותף ביניהם לתוך ה-`useData` שלך:
```js {2-18}
function useData(url) {
@@ -1165,7 +1165,7 @@ function useData(url) {
}
```
-Now you can replace both Effects in the `ShippingForm` components with calls to `useData`:
+כעת אתה יכול להחליף את שני האפקטים ברכיבי `ShippingForm` בקריאות ל-`useData`:
```js {2,4}
function ShippingForm({ country }) {
@@ -1175,33 +1175,33 @@ function ShippingForm({ country }) {
// ...
```
-Extracting a custom Hook makes the data flow explicit. You feed the `url` in and you get the `data` out. By "hiding" your Effect inside `useData`, you also prevent someone working on the `ShippingForm` component from adding [unnecessary dependencies](/learn/removing-effect-dependencies) to it. With time, most of your app's Effects will be in custom Hooks.
+חילוץ Hook מותאם אישית הופך את זרימת הנתונים למפורשת. אתה מזין את ה'כתובת' פנימה ואתה מוציא את ה'נתונים'. על ידי "הסתרת" האפקט שלך בתוך `useData`, אתה גם מונע ממישהו שעובד על רכיב `ShippingForm` להוסיף לו [תלות מיותרת](/learn/removing-effect-dependencies). עם הזמן, רוב האפקטים של האפליקציה שלך יהיו ב-Hooks מותאמים אישית.
<DeepDive>
-#### Keep your custom Hooks focused on concrete high-level use cases {/*keep-your-custom-hooks-focused-on-concrete-high-level-use-cases*/}
+#### שמור את ה-Hooks המותאמים אישית שלך ממוקדים במקרים של שימוש בטון ברמה גבוהה {/*לשמור-your-custom-hooks-focused-on-concrete-high-level-use-cases*/}
-Start by choosing your custom Hook's name. If you struggle to pick a clear name, it might mean that your Effect is too coupled to the rest of your component's logic, and is not yet ready to be extracted.
+התחל בבחירת השם המותאם אישית של Hook. אם אתה מתקשה לבחור שם ברור, זה עשוי לומר שהאפקט שלך מחובר מדי לשאר ההיגיון של הרכיב שלך, ועדיין אינו מוכן לחילוץ.
-Ideally, your custom Hook's name should be clear enough that even a person who doesn't write code often could have a good guess about what your custom Hook does, what it takes, and what it returns:
+באופן אידיאלי, השם של ה-Hook המותאם אישית שלך צריך להיות ברור מספיק כדי שאפילו אדם שלא כותב קוד לעתים קרובות יוכל לנחש היטב מה ה-Hook המותאם אישית שלך עושה, מה הוא דורש ומה הוא מחזיר:
* ✅ `useData(url)`
* ✅ `useImpressionLog(eventName, extraData)`
-* ✅ `useChatRoom(options)`
+* ✅ `שימוש בצ'אט (אפשרויות)`
-When you synchronize with an external system, your custom Hook name may be more technical and use jargon specific to that system. It's good as long as it would be clear to a person familiar with that system:
+כאשר אתה מסתנכרן עם מערכת חיצונית, השם Hook המותאם אישית שלך עשוי להיות טכני יותר ולהשתמש בז'רגון ספציפי לאותה מערכת. זה טוב כל עוד זה יהיה ברור לאדם שמכיר את המערכת הזו:
-* ✅ `useMediaQuery(query)`
+* ✅ `useMediaQuery(שאילתה)`
* ✅ `useSocket(url)`
* ✅ `useIntersectionObserver(ref, options)`
-**Keep custom Hooks focused on concrete high-level use cases.** Avoid creating and using custom "lifecycle" Hooks that act as alternatives and convenience wrappers for the `useEffect` API itself:
+**שמור על הHooks מותאמים אישית ממוקדים במקרים של שימוש בטון ברמה גבוהה.** הימנע מיצירה ושימוש ב-Hooks מותאמים אישית של "מחזור חיים" הפועלים כאלטרנטיבות ועטיפות נוחות עבור ממשק ה-API של 'useEffect' עצמו:
* 🔴 `useMount(fn)`
* 🔴 `useEffectOnce(fn)`
* 🔴 `useUpdateEffect(fn)`
-For example, this `useMount` Hook tries to ensure some code only runs "on mount":
+לדוגמה, ה-'useMount' Hook הזה מנסה להבטיח שקוד מסוים רץ רק "על mount":
```js {4-5,14-15}
function ChatRoom({ roomId }) {
@@ -1225,9 +1225,9 @@ function useMount(fn) {
}
```
-**Custom "lifecycle" Hooks like `useMount` don't fit well into the React paradigm.** For example, this code example has a mistake (it doesn't "react" to `roomId` or `serverUrl` changes), but the linter won't warn you about it because the linter only checks direct `useEffect` calls. It won't know about your Hook.
+**Hooks של "מחזור חיים" מותאם אישית כמו `useMount` אינם מתאימים היטב לפרדיגמת React.** לדוגמה, בדוגמה של קוד זו יש טעות (הוא לא "מגיב" לשינויים של `roomId` או `serverUrl`), אבל ה-linter לא מזהיר אותך על כך מכיוון שה-linter בודק רק קריאות ישירות של 'useEffect'. זה לא יידע על Hook שלך.
-If you're writing an Effect, start by using the React API directly:
+אם אתה כותב אפקט, התחל על ידי שימוש ישירות ב-React API:
```js
function ChatRoom({ roomId }) {
@@ -1249,7 +1249,7 @@ function ChatRoom({ roomId }) {
}
```
-Then, you can (but don't have to) extract custom Hooks for different high-level use cases:
+לאחר מכן, אתה יכול (אך לא חייב) לחלץ Hooks מותאמים אישית עבור מקרי שימוש שונים ברמה גבוהה:
```js
function ChatRoom({ roomId }) {
@@ -1262,15 +1262,15 @@ function ChatRoom({ roomId }) {
}
```
-**A good custom Hook makes the calling code more declarative by constraining what it does.** For example, `useChatRoom(options)` can only connect to the chat room, while `useImpressionLog(eventName, extraData)` can only send an impression log to the analytics. If your custom Hook API doesn't constrain the use cases and is very abstract, in the long run it's likely to introduce more problems than it solves.
+**Hook מותאם אישית טוב הופך את הקוד הקורא להצהרתי יותר על ידי הגבלה של מה שהוא עושה.** לדוגמה, `useChatRoom(options)` יכול להתחבר רק לחדר הצ'אט, בעוד ש-`useImpressionLog(eventName, extraData)` יכול לשלוח רק יומן הופעות לניתוח. אם ה-API המותאם אישית של Hook לא מגביל את מקרי השימוש והוא מאוד מופשט, בטווח הארוך הוא צפוי להציג יותר בעיות ממה שהוא פותר.
</DeepDive>
-### Custom Hooks help you migrate to better patterns {/*custom-hooks-help-you-migrate-to-better-patterns*/}
+### ווים מותאמים אישית עוזרים לך לעבור לדפוסים טובים יותר {/*custom-hooks-help-you-migrate-to-better-patterns*/}
-Effects are an ["escape hatch"](/learn/escape-hatches): you use them when you need to "step outside React" and when there is no better built-in solution for your use case. With time, the React team's goal is to reduce the number of the Effects in your app to the minimum by providing more specific solutions to more specific problems. Wrapping your Effects in custom Hooks makes it easier to upgrade your code when these solutions become available.
+אפקטים הם ["פתח מילוט"](/learn/escape-hatches): אתה משתמש בהם כאשר אתה צריך "לצאת החוצה React" וכאשר אין פתרון מובנה טוב יותר עבור מקרה השימוש שלך. עם הזמן, המטרה של צוות React היא לצמצם את מספר האפקטים באפליקציה שלך למינימום על ידי מתן פתרונות ספציפיים יותר לבעיות ספציפיות יותר. עטיפה של האפקטים שלך ב-Hooks מותאמים אישית מקלה על שדרוג הקוד שלך כאשר הפתרונות האלה יהיו זמינים.
-Let's return to this example:
+נחזור לדוגמא הזו:
<Sandpack>
@@ -1331,9 +1331,9 @@ export function useOnlineStatus() {
</Sandpack>
-In the above example, `useOnlineStatus` is implemented with a pair of [`useState`](/reference/react/useState) and [`useEffect`.](/reference/react/useEffect) However, this isn't the best possible solution. There is a number of edge cases it doesn't consider. For example, it assumes that when the component mounts, `isOnline` is already `true`, but this may be wrong if the network already went offline. You can use the browser [`navigator.onLine`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/onLine) API to check for that, but using it directly would not work on the server for generating the initial HTML. In short, this code could be improved.
+בדוגמה שלמעלה, `useOnlineStatus` מיושם עם זוג של [`useState`](/reference/react/useState) ו-[`useEffect`.](/reference/react/useEffect) עם זאת, זה לא הפתרון הטוב ביותר האפשרי. יש מספר מקרי קצה שהיא לא לוקחת בחשבון. לדוגמה, הוא מניח שכאשר הרכיב נטען, `isOnline` כבר `נכון`, אבל זה עשוי להיות שגוי אם הרשת כבר יצאה לstate לא מקוון. אתה יכול להשתמש בממשק ה-API של הדפדפן [`navigator.onLine`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/onLine) כדי לבדוק זאת, אך השימוש בו ישירות לא יעבוד בשרת ליצירת ה-HTML הראשוני. בקיצור, ניתן לשפר את הקוד הזה.
-Luckily, React 18 includes a dedicated API called [`useSyncExternalStore`](/reference/react/useSyncExternalStore) which takes care of all of these problems for you. Here is how your `useOnlineStatus` Hook, rewritten to take advantage of this new API:
+למרבה המזל, React 18 כולל API ייעודי בשם [`useSyncExternalStore`](/reference/react/useSyncExternalStore) שמטפל בכל הבעיות הללו עבורך. הנה איך ה-'useOnlineStatus' שלך נכתב מחדש כדי לנצל את ה-API החדש הזה:
<Sandpack>
@@ -1393,7 +1393,7 @@ export function useOnlineStatus() {
</Sandpack>
-Notice how **you didn't need to change any of the components** to make this migration:
+שימו לב כיצד **לא היית צריך לשנות אף אחד מהרכיבים** כדי לבצע את ההגירה הזו:
```js {2,7}
function StatusBar() {
@@ -1407,19 +1407,19 @@ function SaveButton() {
}
```
-This is another reason for why wrapping Effects in custom Hooks is often beneficial:
+זו סיבה נוספת לכך שעטיפה של אפקטים בHooks מותאמים אישית היא לעתים קרובות מועילה:
-1. You make the data flow to and from your Effects very explicit.
-2. You let your components focus on the intent rather than on the exact implementation of your Effects.
-3. When React adds new features, you can remove those Effects without changing any of your components.
+1. אתה הופך את זרימת הנתונים אל האפקטים שלך וממנו בצורה מאוד מפורשת.
+2. אתה נותן לרכיבים שלך להתמקד בכוונה ולא ביישום המדויק של האפקטים שלך.
+3. כאשר React מוסיף תכונות חדשות, אתה יכול להסיר את האפקטים האלה מבלי לשנות אף אחד מהרכיבים שלך.
-Similar to a [design system,](https://uxdesign.cc/everything-you-need-to-know-about-design-systems-54b109851969) you might find it helpful to start extracting common idioms from your app's components into custom Hooks. This will keep your components' code focused on the intent, and let you avoid writing raw Effects very often. Many excellent custom Hooks are maintained by the React community.
+בדומה ל[מערכת עיצוב,](https://uxdesign.cc/everything-you-need-to-know-about-design-systems-54b109851969) אולי יעזור לך להתחיל לחלץ ניבים נפוצים ממרכיבי האפליקציה שלך לתוך Hooks מותאמים אישית. זה ישמור על הקוד של הרכיבים שלך ממוקד בכוונה, ויאפשר לך להימנע מכתיבת אפקטים גולמיים לעתים קרובות מאוד. הHooks מותאמים אישית רבים מתוחזקים על ידי קהילת React.
<DeepDive>
-#### Will React provide any built-in solution for data fetching? {/*will-react-provide-any-built-in-solution-for-data-fetching*/}
+#### האם React יספק כל פתרון מובנה לאיסוף נתונים? {/*תגיב-לספק-כל-פתרון-מובנה-לשליפת-נתונים*/}
-We're still working out the details, but we expect that in the future, you'll write data fetching like this:
+אנחנו עדיין עובדים על הפרטים, אבל אנו מצפים שבעתיד תכתוב איסוף נתונים כך:
```js {1,4,6}
import { use } from 'react'; // Not available yet!
@@ -1431,13 +1431,13 @@ function ShippingForm({ country }) {
// ...
```
-If you use custom Hooks like `useData` above in your app, it will require fewer changes to migrate to the eventually recommended approach than if you write raw Effects in every component manually. However, the old approach will still work fine, so if you feel happy writing raw Effects, you can continue to do that.
+אם אתה משתמש ב-Hooks מותאמים אישית כמו 'useData' למעלה באפליקציה שלך, זה ידרוש פחות שינויים כדי לעבור לגישה המומלצת בסופו של דבר מאשר אם תכתוב אפקטים גולמיים בכל רכיב באופן ידני. עם זאת, הגישה הישנה עדיין תעבוד בסדר, אז אם אתה מרגיש שמח לכתוב אפקטים גולמיים, אתה יכול להמשיך לעשות זאת.
</DeepDive>
-### There is more than one way to do it {/*there-is-more-than-one-way-to-do-it*/}
+### יש יותר מדרך אחת לעשות את זה {/*יש-יותר-מאחת-דרך-לעשות-זה*/}
-Let's say you want to implement a fade-in animation *from scratch* using the browser [`requestAnimationFrame`](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame) API. You might start with an Effect that sets up an animation loop. During each frame of the animation, you could change the opacity of the DOM node you [hold in a ref](/learn/manipulating-the-dom-with-refs) until it reaches `1`. Your code might start like this:
+נניח שאתה רוצה ליישם אנימציה דהייה *מאפס* באמצעות דפדפן [`requestAnimationFrame`](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame) API. אתה יכול להתחיל עם אפקט שמגדיר לולאת אנימציה. במהלך כל פריים של האנימציה, אתה יכול לשנות את האטימות של צומת ה-DOM שאתה [מחזיק ב-ref](/learn/manipulating-the-dom-with-refs) עד שהוא מגיע ל-`1`. הקוד שלך עשוי להתחיל כך:
<Sandpack>
@@ -1520,7 +1520,7 @@ html, body { min-height: 300px; }
</Sandpack>
-To make the component more readable, you might extract the logic into a `useFadeIn` custom Hook:
+כדי להפוך את הרכיב לקריאה יותר, תוכל לחלץ את ההיגיון לתוך Hook מותאם אישית של 'useFadeIn':
<Sandpack>
@@ -1611,7 +1611,7 @@ html, body { min-height: 300px; }
</Sandpack>
-You could keep the `useFadeIn` code as is, but you could also refactor it more. For example, you could extract the logic for setting up the animation loop out of `useFadeIn` into a custom `useAnimationLoop` Hook:
+אתה יכול לשמור את הקוד 'useFadeIn' כפי שהוא, אבל אתה יכול גם לשחזר אותו יותר. לדוגמה, אתה יכול לחלץ את ההיגיון להגדרת לולאת האנימציה מתוך `useFadeIn` ל-`useAnimationLoop` Hook מותאם אישית:
<Sandpack>
@@ -1715,7 +1715,7 @@ html, body { min-height: 300px; }
</Sandpack>
-However, you didn't *have to* do that. As with regular functions, ultimately you decide where to draw the boundaries between different parts of your code. You could also take a very different approach. Instead of keeping the logic in the Effect, you could move most of the imperative logic inside a JavaScript [class:](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes)
+עם זאת, לא *חייב* לעשות זאת. כמו בפונקציות רגילות, בסופו של דבר אתה מחליט היכן לשרטט את הגבולות בין חלקים שונים של הקוד שלך. אתה יכול גם לנקוט בגישה שונה מאוד. במקום לשמור על ההיגיון באפקט, אתה יכול להעביר את רוב ההיגיון החיוני בתוך JavaScript [מחלקה:](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes)
<Sandpack>
@@ -1813,9 +1813,9 @@ html, body { min-height: 300px; }
</Sandpack>
-Effects let you connect React to external systems. The more coordination between Effects is needed (for example, to chain multiple animations), the more it makes sense to extract that logic out of Effects and Hooks *completely* like in the sandbox above. Then, the code you extracted *becomes* the "external system". This lets your Effects stay simple because they only need to send messages to the system you've moved outside React.
+אפקטים מאפשרים לך לחבר את React למערכות חיצוניות. ככל שנדרש יותר תיאום בין אפקטים (לדוגמה, לשרשרת אנימציות מרובות), יותר הגיוני לחלץ את ההיגיון הזה מתוך אפקטים וHooks *לגמרי* כמו בארגז החול שלמעלה. לאחר מכן, הקוד שחילצת *הופך* ל"מערכת החיצונית". זה מאפשר לאפקטים שלך להישאר פשוטים מכיוון שהם רק צריכים לשלוח הודעות למערכת שהעברת מחוץ ל-React.
-The examples above assume that the fade-in logic needs to be written in JavaScript. However, this particular fade-in animation is both simpler and much more efficient to implement with a plain [CSS Animation:](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animations/Using_CSS_animations)
+הדוגמאות לעיל מניחות שהלוגיקת ה-Fade-in צריכה להיות כתובה ב-JavaScript. עם זאת, אנימציית הדה-אין הספציפית הזו פשוטה יותר והרבה יותר יעילה ליישום עם [CSS Animation:](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animations/Using_CSS_animations)
<Sandpack>
@@ -1870,27 +1870,27 @@ html, body { min-height: 300px; }
</Sandpack>
-Sometimes, you don't even need a Hook!
+לפעמים, אתה אפילו לא צריך Hook!
<Recap>
-- Custom Hooks let you share logic between components.
-- Custom Hooks must be named starting with `use` followed by a capital letter.
-- Custom Hooks only share stateful logic, not state itself.
-- You can pass reactive values from one Hook to another, and they stay up-to-date.
-- All Hooks re-run every time your component re-renders.
-- The code of your custom Hooks should be pure, like your component's code.
-- Wrap event handlers received by custom Hooks into Effect Events.
-- Don't create custom Hooks like `useMount`. Keep their purpose specific.
-- It's up to you how and where to choose the boundaries of your code.
+- ווים מותאמים אישית מאפשרים לך לשתף היגיון בין רכיבים.
+- יש לתת שם ל-Custom Hooks שמתחיל ב-'use' ואחריו באות גדולה.
+- ווים מותאמים אישית חולקים רק היגיון מצבי, לא מצב עצמו.
+- אתה יכול להעביר ערכים תגובתיים מHook אחד למשנהו, והם נשארים מעודכנים.
+- כל הHooks פועלים מחדש בכל פעם שהרכיב שלך מעבד מחדש.
+- הקוד של Hooks המותאמים אישית שלך צריך להיות טהור, כמו הקוד של הרכיב שלך.
+- עטוף מטפלי אירועים שהתקבלו על ידי Hooks מותאמים אישית לאירועי אפקט.
+- אל תיצור ווים מותאמים אישית כמו `useMount`. שמור על ייעודם ספציפי.
+- זה תלוי בך איך והיכן לבחור את גבולות הקוד שלך.
</Recap>
<Challenges>
-#### Extract a `useCounter` Hook {/*extract-a-usecounter-hook*/}
+#### חלץ Hook של `useCounter` {/*extract-a-usecounter-hook*/}
-This component uses a state variable and an Effect to display a number that increments every second. Extract this logic into a custom Hook called `useCounter`. Your goal is to make the `Counter` component implementation look exactly like this:
+רכיב זה משתמש במשתנה מצב ובאפקט כדי להציג מספר שגדל כל שנייה. חלץ את ההיגיון הזה לתוך Hook מותאם אישית בשם `useCounter`. המטרה שלך היא לגרום למימוש רכיב 'Counter' להיראות בדיוק כך:
```js
export default function Counter() {
@@ -1899,7 +1899,7 @@ export default function Counter() {
}
```
-You'll need to write your custom Hook in `useCounter.js` and import it into the `Counter.js` file.
+תצטרך לכתוב את ה-Hook המותאם אישית שלך ב-`useCounter.js` ולייבא אותו לקובץ `Counter.js`.
<Sandpack>
@@ -1926,7 +1926,7 @@ export default function Counter() {
<Solution>
-Your code should look like this:
+הקוד שלך אמור להיראות כך:
<Sandpack>
@@ -1956,13 +1956,13 @@ export function useCounter() {
</Sandpack>
-Notice that `App.js` doesn't need to import `useState` or `useEffect` anymore.
+שימו לב ש-'App.js' לא צריך לייבא יותר את 'useState' או 'useEffect'.
</Solution>
-#### Make the counter delay configurable {/*make-the-counter-delay-configurable*/}
+#### הפוך את השהיית המונה לניתנת להגדרה {/*הפוך-את-הדלפק-להגדרה*/}
-In this example, there is a `delay` state variable controlled by a slider, but its value is not used. Pass the `delay` value to your custom `useCounter` Hook, and change the `useCounter` Hook to use the passed `delay` instead of hardcoding `1000` ms.
+בדוגמה זו, קיים משתנה מצב 'עיכוב' שנשלט על ידי מחוון, אך הערך שלו אינו בשימוש. העבר את ערך ה-'delay' ל-'useCounter'-Hook המותאם אישית שלך, ושנו את ה-'useCounter'-Hook כדי להשתמש ב-'delay' שעבר במקום לקודד קשה של '1000' אלפיות השנייה.
<Sandpack>
@@ -2012,7 +2012,7 @@ export function useCounter() {
<Solution>
-Pass the `delay` to your Hook with `useCounter(delay)`. Then, inside the Hook, use `delay` instead of the hardcoded `1000` value. You'll need to add `delay` to your Effect's dependencies. This ensures that a change in `delay` will reset the interval.
+העבר את ה-'delay' לHook שלך עם 'useCounter(delay)'. לאחר מכן, בתוך ה-Hook, השתמש ב-'delay' במקום בערך '1000' המקודד. תצטרך להוסיף 'עיכוב' לתלות של האפקט שלך. זה מבטיח ששינוי ב'עיכוב' יאפס את המרווח.
<Sandpack>
@@ -2062,9 +2062,9 @@ export function useCounter(delay) {
</Solution>
-#### Extract `useInterval` out of `useCounter` {/*extract-useinterval-out-of-usecounter*/}
+#### חלץ `useInterval` מתוך `useCounter` {/*extract-useinterval-out-of-usecounter*/}
-Currently, your `useCounter` Hook does two things. It sets up an interval, and it also increments a state variable on every interval tick. Split out the logic that sets up the interval into a separate Hook called `useInterval`. It should take two arguments: the `onTick` callback, and the `delay`. After this change, your `useCounter` implementation should look like this:
+נכון לעכשיו, ה-'useCounter' Hook שלך עושה שני דברים. הוא מגדיר מרווח, והוא גם מגדיל משתנה מצב על כל סימון מרווח. חלקו את ההיגיון שמגדיר את המרווח ל-Hook נפרד שנקרא `useInterval`. זה צריך לקחת שני ארגומנטים: ה-'onTick' callback, וה-'delay'. לאחר השינוי הזה, היישום 'useCounter' שלך אמור להיראות כך:
```js
export function useCounter(delay) {
@@ -2076,7 +2076,7 @@ export function useCounter(delay) {
}
```
-Write `useInterval` in the `useInterval.js` file and import it into the `useCounter.js` file.
+כתוב 'useInterval' בקובץ 'useInterval.js' וייבא אותו לקובץ 'useCounter.js'.
<Sandpack>
@@ -2113,7 +2113,7 @@ export function useCounter(delay) {
<Solution>
-The logic inside `useInterval` should set up and clear the interval. It doesn't need to do anything else.
+ההיגיון בתוך 'useInterval' צריך להגדיר ולנקות את המרווח. זה לא צריך לעשות שום דבר אחר.
<Sandpack>
@@ -2152,17 +2152,17 @@ export function useInterval(onTick, delay) {
</Sandpack>
-Note that there is a bit of a problem with this solution, which you'll solve in the next challenge.
+שימו לב שיש קצת בעיה עם הפתרון הזה, אותה תפתרו באתגר הבא.
</Solution>
-#### Fix a resetting interval {/*fix-a-resetting-interval*/}
+#### תקן מרווח איפוס {/*fix-a-resetting-interval*/}
-In this example, there are *two* separate intervals.
+בדוגמה זו, יש *שני* מרווחים נפרדים.
-The `App` component calls `useCounter`, which calls `useInterval` to update the counter every second. But the `App` component *also* calls `useInterval` to randomly update the page background color every two seconds.
+רכיב ה'אפליקציה' קורא ל'useCounter', שקורא ל'useInterval' כדי לעדכן את המונה בכל שנייה. אבל רכיב ה'אפליקציה' *גם* קורא 'useInterval' כדי לעדכן באופן אקראי את צבע הרקע של העמוד כל שתי שניות.
-For some reason, the callback that updates the page background never runs. Add some logs inside `useInterval`:
+מסיבה כלשהי, ה-callback שמעדכן את רקע העמוד אף פעם לא פועל. הוסף כמה יומנים בתוך 'useInterval':
```js {2,5}
useEffect(() => {
@@ -2175,13 +2175,13 @@ For some reason, the callback that updates the page background never runs. Add s
}, [onTick, delay]);
```
-Do the logs match what you expect to happen? If some of your Effects seem to re-synchronize unnecessarily, can you guess which dependency is causing that to happen? Is there some way to [remove that dependency](/learn/removing-effect-dependencies) from your Effect?
+האם היומנים תואמים למה שאתה מצפה שיקרה? אם נראה שחלק מהאפקטים שלך מסתנכרנים מחדש שלא לצורך, האם אתה יכול לנחש איזו תלות גורמת לזה לקרות? האם יש דרך כלשהי [להסיר את התלות הזו](/learn/removing-effect-dependencies) מהאפקט שלך?
-After you fix the issue, you should expect the page background to update every two seconds.
+לאחר שתתקן את הבעיה, עליך לצפות שרקע הדף יתעדכן כל שתי שניות.
<Hint>
-It looks like your `useInterval` Hook accepts an event listener as an argument. Can you think of some way to wrap that event listener so that it doesn't need to be a dependency of your Effect?
+זה נראה כאילו ה-'useInterval' שלך מקבל מאזין אירועים כטיעון. האם אתה יכול לחשוב על איזושהי דרך לעטוף את המאזין לאירועים כך שהוא לא צריך להיות תלוי באפקט שלך?
</Hint>
@@ -2250,11 +2250,11 @@ export function useInterval(onTick, delay) {
<Solution>
-Inside `useInterval`, wrap the tick callback into an Effect Event, as you did [earlier on this page.](/learn/reusing-logic-with-custom-hooks#passing-event-handlers-to-custom-hooks)
+בתוך `useInterval`, עטפו את ה-Tick Callback לאירוע אפקט, כפי שעשיתם [קודם בדף זה.](/learn/reusing-logic-with-custom-hooks#passing-event-handlers-to-custom-hooks)
-This will allow you to omit `onTick` from dependencies of your Effect. The Effect won't re-synchronize on every re-render of the component, so the page background color change interval won't get reset every second before it has a chance to fire.
+זה יאפשר לך להשמיט את 'onTick' מהתלות של האפקט שלך. האפקט לא יסונכרן מחדש בכל עיבוד מחדש של הרכיב, כך שמרווח שינוי צבע הרקע של הדף לא יתאפס כל שנייה לפני שתהיה לו הזדמנות להפעיל.
-With this change, both intervals work as expected and don't interfere with each other:
+עם שינוי זה, שני המרווחים פועלים כמצופה ואינם מפריעים זה לזה:
<Sandpack>
@@ -2321,21 +2321,21 @@ export function useInterval(callback, delay) {
</Solution>
-#### Implement a staggering movement {/*implement-a-staggering-movement*/}
+#### יישם תנועה מדהימה {/*יישם-תנועה-מדהימה*/}
-In this example, the `usePointerPosition()` Hook tracks the current pointer position. Try moving your cursor or your finger over the preview area and see the red dot follow your movement. Its position is saved in the `pos1` variable.
+בדוגמה זו, Hook `usePointerPosition()` עוקב אחר מיקום הstateיע הנוכחי. נסה להזיז את הסמן או את האצבע שלך על אזור התצוגה המקדימה וראה את הנקודה האדומה עוקבת אחר התנועה שלך. המיקום שלו נשמר במשתנה `pos1`.
-In fact, there are five (!) different red dots being rendered. You don't see them because currently they all appear at the same position. This is what you need to fix. What you want to implement instead is a "staggered" movement: each dot should "follow" the previous dot's path. For example, if you quickly move your cursor, the first dot should follow it immediately, the second dot should follow the first dot with a small delay, the third dot should follow the second dot, and so on.
+למעשה, יש חמש (!) נקודות אדומות שונות המוצגות. אתה לא רואה אותם כי כרגע כולם מופיעים באותו מיקום. זה מה שאתה צריך לתקן. מה שאתה רוצה ליישם במקום זאת הוא תנועה "מדורגת": כל נקודה צריכה "לעקוב אחרי" הנתיב של הנקודה הקודמת. לדוגמה, אם תזיז במהירות את הסמן, הנקודה הראשונה צריכה לעקוב אחריו מיד, הנקודה השנייה צריכה לעקוב אחרי הנקודה הראשונה בהשהייה קטנה, הנקודה השלישית צריכה לעקוב אחרי הנקודה השנייה, וכן הלאה.
-You need to implement the `useDelayedValue` custom Hook. Its current implementation returns the `value` provided to it. Instead, you want to return the value back from `delay` milliseconds ago. You might need some state and an Effect to do this.
+עליך ליישם את ה-Hook המותאם אישית 'useDelayedValue'. היישום הנוכחי שלו מחזיר את ה'ערך' שסופק לו. במקום זאת, אתה רוצה להחזיר את הערך בחזרה מלפני אלפיות שנייה של 'עיכוב'. ייתכן שתזדקק לאיזשהו מצב ואפקט כדי לעשות זאת.
-After you implement `useDelayedValue`, you should see the dots move following one another.
+לאחר הטמעת 'useDelayedValue', אתה אמור לראות את הנקודות זזות אחת אחרי השנייה.
<Hint>
-You'll need to store the `delayedValue` as a state variable inside your custom Hook. When the `value` changes, you'll want to run an Effect. This Effect should update `delayedValue` after the `delay`. You might find it helpful to call `setTimeout`.
+יהיה עליך לאחסן את `delayedValue` כמשתנה מצב בתוך ה-Hook המותאם אישית שלך. כאשר ה'ערך' משתנה, תרצה להפעיל אפקט. אפקט זה אמור לעדכן את 'delayedValue' לאחר ה-'delay'. אולי יעזור לך לקרוא ל'setTimeout'.
-Does this Effect need cleanup? Why or why not?
+האם האפקט הזה צריך ניקוי? למה או למה לא?
</Hint>
@@ -2408,7 +2408,7 @@ body { min-height: 300px; }
<Solution>
-Here is a working version. You keep the `delayedValue` as a state variable. When `value` updates, your Effect schedules a timeout to update the `delayedValue`. This is why the `delayedValue` always "lags behind" the actual `value`.
+הנה גרסה עובדת. אתה שומר את ה-'delayedValue' כמשתנה מצב. כאשר 'ערך' מתעדכן, האפקט שלך מתזמן פסק זמן לעדכון ה-'delayedValue'. זו הסיבה שה-`delayedValue` תמיד "נגרר מאחורי" ה`ערך` בפועל.
<Sandpack>
@@ -2485,8 +2485,9 @@ body { min-height: 300px; }
</Sandpack>
-Note that this Effect *does not* need cleanup. If you called `clearTimeout` in the cleanup function, then each time the `value` changes, it would reset the already scheduled timeout. To keep the movement continuous, you want all the timeouts to fire.
+שימו לב שהאפקט הזה *לא* זקוק לניקוי. אם קראת 'clearTimeout' בפונקציית הניקוי, אז בכל פעם שה'ערך' משתנה, זה יאפס את הזמן הקצוב שכבר מתוזמן. כדי לשמור על התנועה רציפה, אתה רוצה שכל פסקי הזמן יפעלו.
</Solution>
</Challenges>
+
diff --git a/src/content/learn/scaling-up-with-reducer-and-context.md b/src/content/learn/scaling-up-with-reducer-and-context.md
index c3da0c637..562c8f0bc 100644
--- a/src/content/learn/scaling-up-with-reducer-and-context.md
+++ b/src/content/learn/scaling-up-with-reducer-and-context.md
@@ -1,24 +1,24 @@
---
-title: Scaling Up with Reducer and Context
+title: "הגדלה עם reducer ו-הקשר"
---
<Intro>
-Reducers let you consolidate a component's state update logic. Context lets you pass information deep down to other components. You can combine reducers and context together to manage state of a complex screen.
+reducer מאפשרים לך לאחד את לוגיקת עדכון הstate של רכיב. ההקשר מאפשר לך להעביר מידע עמוק למטה לרכיבים אחרים. אתה יכול לשלב reducer והקשר יחד כדי לנהל מצב של מסך מורכב.
</Intro>
<YouWillLearn>
-* How to combine a reducer with context
-* How to avoid passing state and dispatch through props
-* How to keep context and state logic in a separate file
+* איך לשלב reducer עם הקשר
+* איך להימנע ממעבר state ומשלוח דרך props
+* איך לשמור על הקשר והיגיון מצב בקובץ נפרד
</YouWillLearn>
-## Combining a reducer with context {/*combining-a-reducer-with-context*/}
+## שילוב של reducer עם הקשר {/*שילוב-reducer-עם-הקשר*/}
-In this example from [the introduction to reducers](/learn/extracting-state-logic-into-a-reducer), the state is managed by a reducer. The reducer function contains all of the state update logic and is declared at the bottom of this file:
+בדוגמה זו מ[המבוא לreducers](/learn/extracting-state-logic-to-a-reducer), הstate מנוהלת על ידי reducer. פונקציית הreducer מכילה את כל הלוגיקה של עדכון הstate ומוצהרת בתחתית הקובץ הזה:
<Sandpack>
@@ -207,9 +207,9 @@ ul, li { margin: 0; padding: 0; }
</Sandpack>
-A reducer helps keep the event handlers short and concise. However, as your app grows, you might run into another difficulty. **Currently, the `tasks` state and the `dispatch` function are only available in the top-level `TaskApp` component.** To let other components read the list of tasks or change it, you have to explicitly [pass down](/learn/passing-props-to-a-component) the current state and the event handlers that change it as props.
+reducer עוזר לשמור על מטפלי האירועים קצרים ותמציתיים. עם זאת, ככל שהאפליקציה שלך תגדל, אתה עלול להיתקל בקושי נוסף. **כרגע, מצב 'משימות' ופונקציית 'שיגור' זמינים רק ברכיב 'TaskApp' ברמה העליונה.** כדי לאפשר לרכיבים אחרים לקרוא את רשימת המשימות או לשנות אותה, עליך במפורש [להעביר למטה](/learn/passing-props-to-a-component) את הstate הנוכחי ואת המטפלים באירועים שמשנים אותו כprops.
-For example, `TaskApp` passes a list of tasks and the event handlers to `TaskList`:
+לדוגמה, `TaskApp` מעביר רשימה של משימות ואת מטפלי האירועים ל`TaskList`:
```js
<TaskList
@@ -219,7 +219,7 @@ For example, `TaskApp` passes a list of tasks and the event handlers to `TaskLis
/>
```
-And `TaskList` passes the event handlers to `Task`:
+ו-'TaskList' מעביר את מטפלי האירועים ל-'Task':
```js
<Task
@@ -229,30 +229,30 @@ And `TaskList` passes the event handlers to `Task`:
/>
```
-In a small example like this, this works well, but if you have tens or hundreds of components in the middle, passing down all state and functions can be quite frustrating!
+בדוגמה קטנה כמו זו, זה עובד היטב, אבל אם יש לך עשרות או מאות רכיבים באמצע, העברת כל הstates והפונקציות יכול להיות די מתסכל!
-This is why, as an alternative to passing them through props, you might want to put both the `tasks` state and the `dispatch` function [into context.](/learn/passing-data-deeply-with-context) **This way, any component below `TaskApp` in the tree can read the tasks and dispatch actions without the repetitive "prop drilling".**
+זו הסיבה, כחלופה להעברתם דרך props, אולי תרצה להכניס גם את מצב `משימות` וגם את פונקציית `שיגור` [להקשר.](/learn/passing-data-deeply-with-context) **בדרך זו, כל רכיב מתחת ל-TaskApp בעץ יכול לקרוא את המשימות ולשלוח פעולות ללא "** תרגיל חוזר".
-Here is how you can combine a reducer with context:
+הנה איך אתה יכול לשלב reducer עם הקשר:
-1. **Create** the context.
-2. **Put** state and dispatch into context.
-3. **Use** context anywhere in the tree.
+1. **צור** את ההקשר.
+2. **הצב** מצב ושליחה בהקשר.
+3. **השתמש** בהקשר בכל מקום בעץ.
-### Step 1: Create the context {/*step-1-create-the-context*/}
+### שלב 1: צור את ההקשר {/*step-1-create-the-context*/}
-The `useReducer` Hook returns the current `tasks` and the `dispatch` function that lets you update them:
+ה- 'useReducer' Hook מחזיר את ה'משימות' הנוכחיות ואת הפונקציה 'שיגור' המאפשרת לך לעדכן אותן:
```js
const [tasks, dispatch] = useReducer(tasksReducer, initialTasks);
```
-To pass them down the tree, you will [create](/learn/passing-data-deeply-with-context#step-2-use-the-context) two separate contexts:
+כדי להעביר אותם בעץ, [תיצור](/learn/passing-data-deeply-with-context#step-2-use-the-context) שני הקשרים נפרדים:
-- `TasksContext` provides the current list of tasks.
-- `TasksDispatchContext` provides the function that lets components dispatch actions.
+- `TasksContext` מספק את רשימת המשימות הנוכחית.
+- `TasksDispatchContext` מספק את הפונקציה המאפשרת לרכיבים לשלוח פעולות.
-Export them from a separate file so that you can later import them from other files:
+ייצא אותם מקובץ נפרד כדי שתוכל לייבא אותם מאוחר יותר מקבצים אחרים:
<Sandpack>
@@ -448,11 +448,11 @@ ul, li { margin: 0; padding: 0; }
</Sandpack>
-Here, you're passing `null` as the default value to both contexts. The actual values will be provided by the `TaskApp` component.
+כאן, אתה מעביר את 'null' כערך ברירת המחדל לשני ההקשרים. הערכים בפועל יסופקו על ידי רכיב 'TaskApp'.
-### Step 2: Put state and dispatch into context {/*step-2-put-state-and-dispatch-into-context*/}
+### שלב 2: הכנס מצב ושליחה להקשר {/*שלב-2-הכנס-מצב-ושיגור-להקשר*/}
-Now you can import both contexts in your `TaskApp` component. Take the `tasks` and `dispatch` returned by `useReducer()` and [provide them](/learn/passing-data-deeply-with-context#step-3-provide-the-context) to the entire tree below:
+כעת אתה יכול לייבא את שני ההקשרים ברכיב 'TaskApp' שלך. קח את ה'משימות' וה'שליחות' שהוחזרו על ידי 'useReducer()' ו-[ספק אותן](/learn/passing-data-deeply-with-context#step-3-provide-the-context) לעץ המלא למטה:
```js {4,7-8}
import { TasksContext, TasksDispatchContext } from './TasksContext.js';
@@ -470,7 +470,7 @@ export default function TaskApp() {
}
```
-For now, you pass the information both via props and in context:
+לעת עתה, אתה מעביר את המידע הן באמצעות props והן בהקשר:
<Sandpack>
@@ -669,11 +669,11 @@ ul, li { margin: 0; padding: 0; }
</Sandpack>
-In the next step, you will remove prop passing.
+בשלב הבא, תסיר את העברת הprops.
-### Step 3: Use context anywhere in the tree {/*step-3-use-context-anywhere-in-the-tree*/}
+### שלב 3: השתמש בהקשר בכל מקום בעץ {/*step-3-use-context-anywhere-in-the-tree*/}
-Now you don't need to pass the list of tasks or the event handlers down the tree:
+כעת אינך צריך להעביר את רשימת המשימות או את מטפלי האירועים בעץ:
```js {4-5}
<TasksContext.Provider value={tasks}>
@@ -685,7 +685,7 @@ Now you don't need to pass the list of tasks or the event handlers down the tree
</TasksContext.Provider>
```
-Instead, any component that needs the task list can read it from the `TaskContext`:
+במקום זאת, כל רכיב שזקוק לרשימת המשימות יכול לקרוא אותה מתוך ה-TaskContext:
```js {2}
export default function TaskList() {
@@ -693,7 +693,7 @@ export default function TaskList() {
// ...
```
-To update the task list, any component can read the `dispatch` function from context and call it:
+כדי לעדכן את רשימת המשימות, כל רכיב יכול לקרוא את פונקציית 'שיגור' מהקשר ולקרוא לה:
```js {3,9-13}
export default function AddTask() {
@@ -713,7 +713,7 @@ export default function AddTask() {
// ...
```
-**The `TaskApp` component does not pass any event handlers down, and the `TaskList` does not pass any event handlers to the `Task` component either.** Each component reads the context that it needs:
+**רכיב `TaskApp` אינו מעביר אף מטפל באירועים, ו-`TaskList` אינו מעביר אף מטפל באירועים לרכיב `Task`.** כל רכיב קורא את ההקשר שהוא צריך:
<Sandpack>
@@ -897,11 +897,11 @@ ul, li { margin: 0; padding: 0; }
</Sandpack>
-**The state still "lives" in the top-level `TaskApp` component, managed with `useReducer`.** But its `tasks` and `dispatch` are now available to every component below in the tree by importing and using these contexts.
+**הstate עדיין "חיה" ברכיב `TaskApp` ברמה העליונה, המנוהל באמצעות `useReducer`.** אבל `משימות` ו`משלוח` שלו זמינים כעת לכל רכיב למטה בעץ על ידי ייבוא ושימוש בהקשרים אלו.
-## Moving all wiring into a single file {/*moving-all-wiring-into-a-single-file*/}
+## העברת כל החיווט לקובץ בודד {/*העברת-כל-החיווט-לקובץ-יחיד*/}
-You don't have to do this, but you could further declutter the components by moving both reducer and context into a single file. Currently, `TasksContext.js` contains only two context declarations:
+אתה לא חייב לעשות זאת, אבל אתה יכול עוד יותר לבטל את הרכיבים על ידי העברת הreducer וההקשר לקובץ בודד. נכון לעכשיו, `TasksContext.js` מכיל רק שתי הצהרות הקשר:
```js
import { createContext } from 'react';
@@ -910,11 +910,11 @@ export const TasksContext = createContext(null);
export const TasksDispatchContext = createContext(null);
```
-This file is about to get crowded! You'll move the reducer into that same file. Then you'll declare a new `TasksProvider` component in the same file. This component will tie all the pieces together:
+הקובץ הזה עומד להיות צפוף! אתה תעביר את הreducer לאותו קובץ. לאחר מכן תכריז על רכיב `TasksProvider` חדש באותו קובץ. רכיב זה יקשר את כל החלקים יחד:
-1. It will manage the state with a reducer.
-2. It will provide both contexts to components below.
-3. It will [take `children` as a prop](/learn/passing-props-to-a-component#passing-jsx-as-children) so you can pass JSX to it.
+1. היא תנהל את הstate עם reducer.
+2. זה יספק את שני ההקשרים לרכיבים למטה.
+3. זה [ייקח `ילדים` כprops](/learn/passing-props-to-a-component#passing-jsx-as-children) כך שתוכל להעביר אליו JSX.
```js
export function TasksProvider({ children }) {
@@ -930,7 +930,7 @@ export function TasksProvider({ children }) {
}
```
-**This removes all the complexity and wiring from your `TaskApp` component:**
+**זה מסיר את כל המורכבות והחיווט מרכיב ה-TaskApp שלך:**
<Sandpack>
@@ -1121,7 +1121,7 @@ ul, li { margin: 0; padding: 0; }
</Sandpack>
-You can also export functions that _use_ the context from `TasksContext.js`:
+אתה יכול גם לייצא פונקציות ש_משתמשות_ בהקשר מתוך `TasksContext.js`:
```js
export function useTasks() {
@@ -1133,14 +1133,14 @@ export function useTasksDispatch() {
}
```
-When a component needs to read context, it can do it through these functions:
+כאשר רכיב צריך לקרוא את ההקשר, הוא יכול לעשות זאת באמצעות הפונקציות הבאות:
```js
const tasks = useTasks();
const dispatch = useTasksDispatch();
```
-This doesn't change the behavior in any way, but it lets you later split these contexts further or add some logic to these functions. **Now all of the context and reducer wiring is in `TasksContext.js`. This keeps the components clean and uncluttered, focused on what they display rather than where they get the data:**
+זה לא משנה את ההתנהגות בשום צורה, אבל זה מאפשר לך מאוחר יותר לפצל את ההקשרים האלה או להוסיף קצת היגיון לפונקציות האלה. **עכשיו כל ההקשר והחיווט הreducer נמצאים ב-'TasksContext.js'. זה שומר על הרכיבים נקיים ולא מבולגנים, ממוקדים במה שהם מציגים במקום היכן הם מקבלים את הנתונים:**
<Sandpack>
@@ -1340,27 +1340,28 @@ ul, li { margin: 0; padding: 0; }
</Sandpack>
-You can think of `TasksProvider` as a part of the screen that knows how to deal with tasks, `useTasks` as a way to read them, and `useTasksDispatch` as a way to update them from any component below in the tree.
+אתה יכול לחשוב על 'TasksProvider' כחלק מהמסך שיודע להתמודד עם משימות, על 'useTasks' כדרך לקרוא אותן, ועל 'useTasksDispatch' כדרך לעדכן אותן מכל רכיב למטה בעץ.
<Note>
-Functions like `useTasks` and `useTasksDispatch` are called *[Custom Hooks.](/learn/reusing-logic-with-custom-hooks)* Your function is considered a custom Hook if its name starts with `use`. This lets you use other Hooks, like `useContext`, inside it.
+פונקציות כמו `useTasks` ו-`useTasksDispatch` נקראות *[Custom Hooks.](/learn/reusing-logic-with-custom-hooks)* הפונקציה שלך נחשבת Hook מותאמת אישית אם השם שלה מתחיל ב-`use`. זה מאפשר לך להשתמש ב-Hooks אחרים, כמו 'useContext', בתוכו.
</Note>
-As your app grows, you may have many context-reducer pairs like this. This is a powerful way to scale your app and [lift state up](/learn/sharing-state-between-components) without too much work whenever you want to access the data deep in the tree.
+ככל שהאפליקציה שלך תגדל, ייתכן שיהיו לך הרבה זוגות reducerי הקשר כמו זה. זוהי דרך רבת עוצמה להרחיב את קנה המידה של האפליקציה שלך ו[lift state up](/learn/sharing-state-between-components) ללא יותר מדי עבודה בכל פעם שאתה רוצה לגשת לנתונים עמוק בעץ.
<Recap>
-- You can combine reducer with context to let any component read and update state above it.
-- To provide state and the dispatch function to components below:
- 1. Create two contexts (for state and for dispatch functions).
- 2. Provide both contexts from the component that uses the reducer.
- 3. Use either context from components that need to read them.
-- You can further declutter the components by moving all wiring into one file.
- - You can export a component like `TasksProvider` that provides context.
- - You can also export custom Hooks like `useTasks` and `useTasksDispatch` to read it.
-- You can have many context-reducer pairs like this in your app.
+- אתה יכול לשלב reducer עם הקשר כדי לאפשר לכל רכיב לקרוא ולעדכן מצב מעליו.
+- כדי לספק מצב ופונקציית השיגור לרכיבים הבאים:
+ 1. צור שני הקשרים (עבור מצב ופונקציות שיגור).
+ 2. ספק את שני ההקשרים מהרכיב שמשתמש בreducer.
+ 3. השתמש בכל אחד מההקשרים מרכיבים שצריכים לקרוא אותם.
+- אתה יכול לשחרר עוד יותר את הרכיבים על ידי העברת כל החיווט לקובץ אחד.
+ - אתה יכול לייצא רכיב כמו `TasksProvider` שמספק הקשר.
+ - אתה יכול גם לייצא Hooks מותאמים אישית כמו `useTasks` ו-`useTasksDispatch` כדי לקרוא אותו.
+- אתה יכול לקבל הרבה זוגות reducerי הקשר כמו זה באפליקציה שלך.
</Recap>
+
diff --git a/src/content/learn/separating-events-from-effects.md b/src/content/learn/separating-events-from-effects.md
index ac65d2b60..19c923347 100644
--- a/src/content/learn/separating-events-from-effects.md
+++ b/src/content/learn/separating-events-from-effects.md
@@ -1,37 +1,37 @@
---
-title: 'Separating Events from Effects'
+title: "הפרדת אירועים מ-אפקטים"
---
<Intro>
-Event handlers only re-run when you perform the same interaction again. Unlike event handlers, Effects re-synchronize if some value they read, like a prop or a state variable, is different from what it was during the last render. Sometimes, you also want a mix of both behaviors: an Effect that re-runs in response to some values but not others. This page will teach you how to do that.
+מטפלי אירועים פועלים מחדש רק כאשר אתה מבצע שוב את אותה אינטראקציה. שלא כמו מטפלים באירועים, אפקטים מסתנכרנים מחדש אם ערך כלשהו שהם קוראים, כמו אב או משתנה מצב, שונה ממה שהיה במהלך העיבוד האחרון. לפעמים, אתה גם רוצה שילוב של שתי ההתנהגויות: אפקט המופעל מחדש בתגובה לערכים מסוימים אך לא לאחרים. הדף הזה ילמד אותך איך לעשות זאת.
</Intro>
<YouWillLearn>
-- How to choose between an event handler and an Effect
-- Why Effects are reactive, and event handlers are not
-- What to do when you want a part of your Effect's code to not be reactive
-- What Effect Events are, and how to extract them from your Effects
-- How to read the latest props and state from Effects using Effect Events
+- כיצד לבחור בין מטפל באירועים לבין אפקט
+- מדוע אפקטים מגיבים, ומטפלי אירועים אינם
+- מה לעשות כאשר אתה רוצה שחלק מהקוד של האפקט שלך לא יהיה תגובתי
+- מהם אירועי אפקט וכיצד לחלץ אותם מהאפקטים שלך
+- כיצד לקרוא את הprops וstate העדכניים ביותר מאפקטים באמצעות אפקט אירועים
</YouWillLearn>
-## Choosing between event handlers and Effects {/*choosing-between-event-handlers-and-effects*/}
+## בחירה בין מטפלי אירועים לאפקטים {/*בחירה-בין-event-handlers-and-effects*/}
-First, let's recap the difference between event handlers and Effects.
+ראשית, בואו נסכם את ההבדל בין מטפלי אירועים לאפקטים.
-Imagine you're implementing a chat room component. Your requirements look like this:
+תאר לעצמך שאתה מיישם רכיב של חדר צ'אט. הדרישות שלך נראות כך:
-1. Your component should automatically connect to the selected chat room.
-1. When you click the "Send" button, it should send a message to the chat.
+1. הרכיב שלך אמור להתחבר אוטומטית לחדר הצ'אט הנבחר.
+1. כאשר אתה לוחץ על כפתור "שלח", זה אמור לשלוח הודעה לצ'אט.
-Let's say you've already implemented the code for them, but you're not sure where to put it. Should you use event handlers or Effects? Every time you need to answer this question, consider [*why* the code needs to run.](/learn/synchronizing-with-effects#what-are-effects-and-how-are-they-different-from-events)
+נניח שכבר יישמת את הקוד עבורם, אבל אתה לא בטוח איפה לשים אותו. האם להשתמש במטפלי אירועים או אפקטים? בכל פעם שאתה צריך לענות על שאלה זו, שקול [*למה* הקוד צריך לפעול.](/learn/synchronizing-with-effects#what-are-effects-and-how-the-they-different-from-events)
-### Event handlers run in response to specific interactions {/*event-handlers-run-in-response-to-specific-interactions*/}
+### מטפלי אירועים פועלים בתגובה לאינטראקציות ספציפיות {/*event-handlers-run-in-response-to-specific-interactions*/}
-From the user's perspective, sending a message should happen *because* the particular "Send" button was clicked. The user will get rather upset if you send their message at any other time or for any other reason. This is why sending a message should be an event handler. Event handlers let you handle specific interactions:
+מנקודת המבט של המשתמש, שליחת הודעה צריכה להתרחש *מכיוון* שנלחצה על כפתור ה"שלח" המסוים. המשתמש יתעצבן למדי אם תשלח את ההודעה שלו בכל זמן אחר או מכל סיבה אחרת. זו הסיבה ששליחת הודעה צריכה להיות מטפל באירועים. מטפלי אירועים מאפשרים לך לטפל באינטראקציות ספציפיות:
```js {4-6}
function ChatRoom({ roomId }) {
@@ -50,13 +50,13 @@ function ChatRoom({ roomId }) {
}
```
-With an event handler, you can be sure that `sendMessage(message)` will *only* run if the user presses the button.
+עם מטפל באירועים, אתה יכול להיות בטוח ש'sendMessage(message)' יפעל *רק* אם המשתמש ילחץ על הכפתור.
-### Effects run whenever synchronization is needed {/*effects-run-whenever-synchronization-is-needed*/}
+### אפקטים פועלים בכל פעם שיש צורך בסנכרון {/*effects-run-whenever-synchronization-is-needed*/}
-Recall that you also need to keep the component connected to the chat room. Where does that code go?
+זכור כי אתה גם צריך לשמור את הרכיב מחובר לחדר הצ'אט. לאן הולך הקוד הזה?
-The *reason* to run this code is not some particular interaction. It doesn't matter why or how the user navigated to the chat room screen. Now that they're looking at it and could interact with it, the component needs to stay connected to the selected chat server. Even if the chat room component was the initial screen of your app, and the user has not performed any interactions at all, you would *still* need to connect. This is why it's an Effect:
+*הסיבה* להפעיל את הקוד הזה אינה אינטראקציה מסוימת. זה לא משנה למה או איך המשתמש נווט למסך חדר הצ'אט. כעת, כשהם מסתכלים עליו ויכולים ליצור איתו אינטראקציה, הרכיב צריך להישאר מחובר לשרת הצ'אט שנבחר. גם אם רכיב חדר הצ'אט היה המסך הראשוני של האפליקציה שלך, והמשתמש לא ביצע אינטראקציות כלל, תצטרך *עדיין* להתחבר. זו הסיבה שזה אפקט:
```js {3-9}
function ChatRoom({ roomId }) {
@@ -72,7 +72,7 @@ function ChatRoom({ roomId }) {
}
```
-With this code, you can be sure that there is always an active connection to the currently selected chat server, *regardless* of the specific interactions performed by the user. Whether the user has only opened your app, selected a different room, or navigated to another screen and back, your Effect ensures that the component will *remain synchronized* with the currently selected room, and will [re-connect whenever it's necessary.](/learn/lifecycle-of-reactive-effects#why-synchronization-may-need-to-happen-more-than-once)
+עם קוד זה, אתה יכול להיות בטוח שתמיד יש חיבור פעיל לשרת הצ'אט שנבחר כעת, *ללא קשר* לאינטראקציות הספציפיות שמבצע המשתמש. בין אם המשתמש רק פתח את האפליקציה שלך, בחר חדר אחר או ניווט למסך אחר ובחזרה, האפקט שלך מבטיח שהרכיב *יישאר מסונכרן* עם החדר שנבחר כעת, ו[יתחבר מחדש בכל פעם שנדרש.](/learn/lifecycle-of-reactive-effects#why-synchronization-cany-reactive-to-han
<Sandpack>
@@ -154,13 +154,13 @@ input, select { margin-right: 20px; }
</Sandpack>
-## Reactive values and reactive logic {/*reactive-values-and-reactive-logic*/}
+## ערכים ריאקטיביים והיגיון תגובתי {/*reactive-values-and-reactive-logic*/}
-Intuitively, you could say that event handlers are always triggered "manually", for example by clicking a button. Effects, on the other hand, are "automatic": they run and re-run as often as it's needed to stay synchronized.
+באופן אינטואיטיבי, אפשר לומר שמטפלי אירועים תמיד מופעלים "ידנית", למשל על ידי לחיצה על כפתור. האפקטים, לעומת זאת, הם "אוטומטיים": הם פועלים ומופעלים מחדש בתדירות הנדרשת כדי להישאר מסונכרנים.
-There is a more precise way to think about this.
+יש דרך יותר מדויקת לחשוב על זה.
-Props, state, and variables declared inside your component's body are called <CodeStep step={2}>reactive values</CodeStep>. In this example, `serverUrl` is not a reactive value, but `roomId` and `message` are. They participate in the rendering data flow:
+props, מצב ומשתנים המוצהרים בתוך גוף הרכיב שלך נקראים <CodeStep step={2}>ערכים תגובתיים</CodeStep>. בדוגמה זו, `serverUrl` אינו ערך תגובתי, אבל `roomId` ו-`message` כן. הם משתתפים בזרימת הנתונים בעיבוד:
```js [[2, 3, "roomId"], [2, 4, "message"]]
const serverUrl = 'https://localhost:1234';
@@ -172,16 +172,16 @@ function ChatRoom({ roomId }) {
}
```
-Reactive values like these can change due to a re-render. For example, the user may edit the `message` or choose a different `roomId` in a dropdown. Event handlers and Effects respond to changes differently:
+ערכים תגובתיים כמו אלה יכולים להשתנות עקב עיבוד מחדש. לדוגמה, המשתמש יכול לערוך את ה'הודעה' או לבחור 'roomId' אחר בתפריט נפתח. מטפלי אירועים ואפקטים מגיבים לשינויים בצורה שונה:
-- **Logic inside event handlers is *not reactive.*** It will not run again unless the user performs the same interaction (e.g. a click) again. Event handlers can read reactive values without "reacting" to their changes.
-- **Logic inside Effects is *reactive.*** If your Effect reads a reactive value, [you have to specify it as a dependency.](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values) Then, if a re-render causes that value to change, React will re-run your Effect's logic with the new value.
+- **ההיגיון בתוך מטפלי אירועים הוא *לא תגובתי.*** זה לא יפעל שוב אלא אם המשתמש יבצע שוב את אותה אינטראקציה (למשל, קליק). מטפלי אירועים יכולים לקרוא ערכים תגובתיים מבלי "להגיב" לשינויים שלהם.
+- **ההיגיון בתוך Effects הוא *reactive.*** אם האפקט שלך קורא ערך תגובתי, [עליך לציין אותו כתלות.](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values) לאחר מכן, אם עיבוד מחדש גורם לערך זה להשתנות, React יפעיל מחדש את הלוגיקה של האפקט החדש שלך.
-Let's revisit the previous example to illustrate this difference.
+בואו נחזור על הדוגמה הקודמת כדי להמחיש את ההבדל הזה.
-### Logic inside event handlers is not reactive {/*logic-inside-event-handlers-is-not-reactive*/}
+### ההיגיון בתוך מטפלי אירועים אינו תגובתי {/*logic-inside-event-handlers-is-not-reactive*/}
-Take a look at this line of code. Should this logic be reactive or not?
+תסתכל על שורת הקוד הזו. האם ההיגיון הזה צריך להיות תגובתי או לא?
```js [[2, 2, "message"]]
// ...
@@ -189,7 +189,7 @@ Take a look at this line of code. Should this logic be reactive or not?
// ...
```
-From the user's perspective, **a change to the `message` does _not_ mean that they want to send a message.** It only means that the user is typing. In other words, the logic that sends a message should not be reactive. It should not run again only because the <CodeStep step={2}>reactive value</CodeStep> has changed. That's why it belongs in the event handler:
+מנקודת המבט של המשתמש, **שינוי ב'הודעה' _לא_ אומר שהוא רוצה לשלוח הודעה.** זה רק אומר שהמשתמש מקליד. במילים אחרות, ההיגיון ששולח הודעה לא צריך להיות תגובתי. זה לא אמור לפעול שוב רק בגלל ש<CodeStep step={2}>ערך התגובה</CodeStep> השתנה. לכן זה שייך למטפל באירועים:
```js {2}
function handleSendClick() {
@@ -197,11 +197,11 @@ From the user's perspective, **a change to the `message` does _not_ mean that th
}
```
-Event handlers aren't reactive, so `sendMessage(message)` will only run when the user clicks the Send button.
+מטפלי אירועים אינם ריאקטיביים, כך ש'sendMessage(message)' יפעל רק כאשר המשתמש ילחץ על כפתור השליחה.
-### Logic inside Effects is reactive {/*logic-inside-effects-is-reactive*/}
+### ההיגיון בתוך Effects הוא תגובתי {/*logic-inside-effects-is-reactive*/}
-Now let's return to these lines:
+כעת נחזור לשורות אלו:
```js [[2, 2, "roomId"]]
// ...
@@ -210,7 +210,7 @@ Now let's return to these lines:
// ...
```
-From the user's perspective, **a change to the `roomId` *does* mean that they want to connect to a different room.** In other words, the logic for connecting to the room should be reactive. You *want* these lines of code to "keep up" with the <CodeStep step={2}>reactive value</CodeStep>, and to run again if that value is different. That's why it belongs in an Effect:
+מנקודת המבט של המשתמש, **שינוי ב-`roomId` *משמעו* שהם רוצים להתחבר לחדר אחר.** במילים אחרות, ההיגיון לחיבור לחדר צריך להיות תגובתי. אתה *רוצה* ששורות הקוד האלה "יעמדו בקצב" עם <CodeStep step={2}>הערך הריאקטיבי</CodeStep>, ויפעלו שוב אם הערך הזה שונה. לכן זה שייך לאפקט:
```js {2-3}
useEffect(() => {
@@ -222,13 +222,13 @@ From the user's perspective, **a change to the `roomId` *does* mean that they wa
}, [roomId]);
```
-Effects are reactive, so `createConnection(serverUrl, roomId)` and `connection.connect()` will run for every distinct value of `roomId`. Your Effect keeps the chat connection synchronized to the currently selected room.
+האפקטים הם תגובתיים, אז `createConnection(serverUrl, roomId)` ו-`connection.connect()` יפעלו עבור כל ערך מובחן של `roomId`. האפקט שלך שומר על חיבור הצ'אט מסונכרן לחדר שנבחר כעת.
-## Extracting non-reactive logic out of Effects {/*extracting-non-reactive-logic-out-of-effects*/}
+## חילוץ לוגיקה לא-ריאקטיבית מתוך אפקטים {/*חילוץ-לא-ריאקטיבי-לוגיקה-מחוץ-להשפעות*/}
-Things get more tricky when you want to mix reactive logic with non-reactive logic.
+דברים נעשים מסובכים יותר כאשר אתה רוצה לערבב לוגיקה תגובתית עם לוגיקה לא תגובתית.
-For example, imagine that you want to show a notification when the user connects to the chat. You read the current theme (dark or light) from the props so that you can show the notification in the correct color:
+לדוגמה, דמיינו שאתם רוצים להציג התראה כאשר המשתמש מתחבר לצ'אט. אתה קורא את הנושא הנוכחי (כהה או בהיר) מprops כדי שתוכל להציג את ההודעה בצבע הנכון:
```js {1,4-6}
function ChatRoom({ roomId, theme }) {
@@ -241,7 +241,7 @@ function ChatRoom({ roomId, theme }) {
// ...
```
-However, `theme` is a reactive value (it can change as a result of re-rendering), and [every reactive value read by an Effect must be declared as its dependency.](/learn/lifecycle-of-reactive-effects#react-verifies-that-you-specified-every-reactive-value-as-a-dependency) Now you have to specify `theme` as a dependency of your Effect:
+עם זאת, `theme` הוא ערך תגובתי (הוא יכול להשתנות כתוצאה מעיבוד מחדש), ו[כל ערך תגובתי הנקרא על ידי אפקט חייב להיות מוכרז כתלות שלו.](/learn/lifecycle-of-reactive-effects#react-verifies-that-you-specificated-every-reactive-value-the-reactive-value-the-me-a-dependency: now
```js {5,11}
function ChatRoom({ roomId, theme }) {
@@ -258,7 +258,7 @@ function ChatRoom({ roomId, theme }) {
// ...
```
-Play with this example and see if you can spot the problem with this user experience:
+שחק עם הדוגמה הזו וראה אם אתה יכול לזהות את הבעיה בחוויית המשתמש הזו:
<Sandpack>
@@ -386,9 +386,9 @@ label { display: block; margin-top: 10px; }
</Sandpack>
-When the `roomId` changes, the chat re-connects as you would expect. But since `theme` is also a dependency, the chat *also* re-connects every time you switch between the dark and the light theme. That's not great!
+כאשר ה-'roomId' משתנה, הצ'אט מתחבר מחדש כפי שהיית מצפה. אבל מכיוון ש'נושא' הוא גם תלות, הצ'אט *גם* מתחבר מחדש בכל פעם שאתה מחליף בין הנושא הכהה והבהיר. זה לא נהדר!
-In other words, you *don't* want this line to be reactive, even though it is inside an Effect (which is reactive):
+במילים אחרות, אתה *לא* רוצה שהשורה הזו תהיה תגובתית, למרות שהיא בתוך אפקט (שהוא תגובתי):
```js
// ...
@@ -396,17 +396,17 @@ In other words, you *don't* want this line to be reactive, even though it is ins
// ...
```
-You need a way to separate this non-reactive logic from the reactive Effect around it.
+אתה צריך דרך להפריד את ההיגיון הלא תגובתי הזה מהאפקט התגובתי סביבו.
-### Declaring an Effect Event {/*declaring-an-effect-event*/}
+### הכרזה על אירוע אפקט {/*הכרזה-על-אירוע-אפקט*/}
<Wip>
-This section describes an **experimental API that has not yet been released** in a stable version of React.
+סעיף זה מתאר **API ניסיוני שעדיין לא שוחרר** בגרסה יציבה של React.
</Wip>
-Use a special Hook called [`useEffectEvent`](/reference/react/experimental_useEffectEvent) to extract this non-reactive logic out of your Effect:
+השתמש בהוק מיוחד בשם [`useEffectEvent`](/reference/react/experimental_useEffectEvent) כדי לחלץ את ההיגיון הלא תגובתי הזה מהאפקט שלך:
```js {1,4-6}
import { useEffect, useEffectEvent } from 'react';
@@ -418,9 +418,9 @@ function ChatRoom({ roomId, theme }) {
// ...
```
-Here, `onConnected` is called an *Effect Event.* It's a part of your Effect logic, but it behaves a lot more like an event handler. The logic inside it is not reactive, and it always "sees" the latest values of your props and state.
+כאן, `onConnected` נקרא *Effect Event.* זה חלק מהלוגיקת האפקט שלך, אבל הוא מתנהג הרבה יותר כמו מטפל באירועים. ההיגיון בתוכו אינו תגובתי, והוא תמיד "רואה" את הערכים העדכניים ביותר של הprops וstate שלך.
-Now you can call the `onConnected` Effect Event from inside your Effect:
+עכשיו אתה יכול לקרוא לאירוע 'onConnected' אפקט מתוך האפקט שלך:
```js {2-4,9,13}
function ChatRoom({ roomId, theme }) {
@@ -439,9 +439,9 @@ function ChatRoom({ roomId, theme }) {
// ...
```
-This solves the problem. Note that you had to *remove* `onConnected` from the list of your Effect's dependencies. **Effect Events are not reactive and must be omitted from dependencies.**
+זה פותר את הבעיה. שים לב שהיית צריך *להסיר* את 'onConnected' מרשימת התלות של האפקט שלך. **אירועי אפקט אינם ריאקטיביים ויש להשמיט אותם מהתלות.**
-Verify that the new behavior works as you would expect:
+ודא שההתנהגות החדשה פועלת כפי שהיית מצפה:
<Sandpack>
@@ -574,19 +574,19 @@ label { display: block; margin-top: 10px; }
</Sandpack>
-You can think of Effect Events as being very similar to event handlers. The main difference is that event handlers run in response to a user interactions, whereas Effect Events are triggered by you from Effects. Effect Events let you "break the chain" between the reactivity of Effects and code that should not be reactive.
+אתה יכול לחשוב על אפקט אירועים כדומים מאוד למטפלי אירועים. ההבדל העיקרי הוא שמטפלי אירועים פועלים בתגובה לאינטראקציות של משתמש, בעוד שאירועי אפקט מופעלים על ידך מ- Effects. אפקט אירועים מאפשרים לך "לשבור את השרשרת" בין התגובתיות של אפקטים לקוד שלא אמור להיות תגובתי.
-### Reading latest props and state with Effect Events {/*reading-latest-props-and-state-with-effect-events*/}
+### קריאת הprops האחרונים וstate עם אפקט אירועים {/*reading-latest-props-and-state-with-effect-events*/}
<Wip>
-This section describes an **experimental API that has not yet been released** in a stable version of React.
+סעיף זה מתאר **API ניסיוני שעדיין לא שוחרר** בגרסה יציבה של React.
</Wip>
-Effect Events let you fix many patterns where you might be tempted to suppress the dependency linter.
+אירועי אפקט מאפשרים לך לתקן דפוסים רבים שבהם אתה עלול להתפתות לדכא את קו התלות.
-For example, say you have an Effect to log the page visits:
+לדוגמה, נניח שיש לך אפקט לרישום הביקורים בדף:
```js
function Page() {
@@ -597,7 +597,7 @@ function Page() {
}
```
-Later, you add multiple routes to your site. Now your `Page` component receives a `url` prop with the current path. You want to pass the `url` as a part of your `logVisit` call, but the dependency linter complains:
+מאוחר יותר, אתה מוסיף מספר מסלולים לאתר שלך. כעת רכיב ה'דף' שלך מקבל props 'כתובת אתר' עם הנתיב הנוכחי. אתה רוצה להעביר את ה-URL כחלק משיחת ה-'logVisit' שלך, אבל קו התלות מתלונן:
```js {1,3}
function Page({ url }) {
@@ -608,7 +608,7 @@ function Page({ url }) {
}
```
-Think about what you want the code to do. You *want* to log a separate visit for different URLs since each URL represents a different page. In other words, this `logVisit` call *should* be reactive with respect to the `url`. This is why, in this case, it makes sense to follow the dependency linter, and add `url` as a dependency:
+תחשוב מה אתה רוצה שהקוד יעשה. אתה *רוצה* לרשום ביקור נפרד עבור כתובות אתרים שונות מכיוון שכל כתובת אתר מייצגת דף אחר. במילים אחרות, קריאת `logVisit` זו *צריכה* להיות תגובתית ביחס לכתובת ה-URL. זו הסיבה, שבמקרה זה, הגיוני לעקוב אחר קו התלות ולהוסיף 'כתובת אתר' בתור תלות:
```js {4}
function Page({ url }) {
@@ -619,7 +619,7 @@ function Page({ url }) {
}
```
-Now let's say you want to include the number of items in the shopping cart together with every page visit:
+כעת נניח שברצונך לכלול את מספר הפריטים בעגלת הקניות יחד עם כל ביקור בדף:
```js {2-3,6}
function Page({ url }) {
@@ -633,9 +633,9 @@ function Page({ url }) {
}
```
-You used `numberOfItems` inside the Effect, so the linter asks you to add it as a dependency. However, you *don't* want the `logVisit` call to be reactive with respect to `numberOfItems`. If the user puts something into the shopping cart, and the `numberOfItems` changes, this *does not mean* that the user visited the page again. In other words, *visiting the page* is, in some sense, an "event". It happens at a precise moment in time.
+השתמשת ב-'numberOfItems' בתוך האפקט, אז ה-linter מבקש ממך להוסיף אותו כתלות. עם זאת, אתה *לא* רוצה שהקריאה 'logVisit' תהיה תגובתית ביחס ל'numberOfItems'. אם המשתמש מכניס משהו לעגלת הקניות, ו-'numberOfItems' משתנה, זה *לא אומר* שהמשתמש ביקר שוב בעמוד. במילים אחרות, *ביקור בדף* הוא, במובן מסוים, "אירוע". זה קורה ברגע מדויק בזמן.
-Split the code in two parts:
+פצל את הקוד לשני חלקים:
```js {5-7,10}
function Page({ url }) {
@@ -653,15 +653,15 @@ function Page({ url }) {
}
```
-Here, `onVisit` is an Effect Event. The code inside it isn't reactive. This is why you can use `numberOfItems` (or any other reactive value!) without worrying that it will cause the surrounding code to re-execute on changes.
+כאן, 'onVisit' הוא אירוע אפקט. הקוד שבתוכו אינו מגיב. זו הסיבה שאתה יכול להשתמש ב-'numberOfItems' (או בכל ערך תגובתי אחר!) מבלי לדאוג שזה יגרום לקוד שמסביב להפעיל מחדש בשינויים.
-On the other hand, the Effect itself remains reactive. Code inside the Effect uses the `url` prop, so the Effect will re-run after every re-render with a different `url`. This, in turn, will call the `onVisit` Effect Event.
+מצד שני, האפקט עצמו נשאר תגובתי. הקוד בתוך האפקט משתמש בprops `url`, כך שהאפקט יפעל מחדש לאחר כל רינדור מחדש עם `url` אחר. זה, בתורו, יקרא את אירוע אפקט 'onVisit'.
-As a result, you will call `logVisit` for every change to the `url`, and always read the latest `numberOfItems`. However, if `numberOfItems` changes on its own, this will not cause any of the code to re-run.
+כתוצאה מכך, תתקשר ל-'logVisit' עבור כל שינוי ב-'url', ותמיד תקרא את ה-'numberOfItems' העדכני ביותר. עם זאת, אם 'numberOfItems' משתנה מעצמו, זה לא יגרום לאף אחד מהקודים להפעיל מחדש.
<Note>
-You might be wondering if you could call `onVisit()` with no arguments, and read the `url` inside it:
+אולי אתה תוהה אם אתה יכול לקרוא ל- `onVisit()` ללא ארגומנטים, ולקרוא את ה-URL שבתוכו:
```js {2,6}
const onVisit = useEffectEvent(() => {
@@ -673,7 +673,7 @@ You might be wondering if you could call `onVisit()` with no arguments, and read
}, [url]);
```
-This would work, but it's better to pass this `url` to the Effect Event explicitly. **By passing `url` as an argument to your Effect Event, you are saying that visiting a page with a different `url` constitutes a separate "event" from the user's perspective.** The `visitedUrl` is a *part* of the "event" that happened:
+זה יעבוד, אבל עדיף להעביר את ה-URL הזה לאירוע אפקט במפורש. **על ידי העברת 'כתובת אתר' כטיעון לאירוע האפקט שלך, אתה אומר שביקור בדף עם 'כתובת אתר' שונה מהווה "אירוע" נפרד מנקודת המבט של המשתמש.** ה-'visitedUrl' הוא *חלק* מה"אירוע" שקרה:
```js {1-2,6}
const onVisit = useEffectEvent(visitedUrl => {
@@ -685,9 +685,9 @@ This would work, but it's better to pass this `url` to the Effect Event explicit
}, [url]);
```
-Since your Effect Event explicitly "asks" for the `visitedUrl`, now you can't accidentally remove `url` from the Effect's dependencies. If you remove the `url` dependency (causing distinct page visits to be counted as one), the linter will warn you about it. You want `onVisit` to be reactive with regards to the `url`, so instead of reading the `url` inside (where it wouldn't be reactive), you pass it *from* your Effect.
+מכיוון שאירוע האפקט שלך "מבקש" במפורש את ה-'visitedUrl', כעת אינך יכול להסיר בטעות 'url' מהתלות של האפקט. אם תסיר את התלות של 'כתובת האתר' (מה שגורם לביקורים נפרדים בדפים להיספר כאחד), ה-linter יזהיר אותך על כך. אתה רוצה ש-'onVisit' יהיה תגובתי ביחס ל-'url', אז במקום לקרוא את ה-'url' בפנים (היכן שהוא לא יהיה תגובתי), אתה מעביר אותו *מה* אפקט שלך.
-This becomes especially important if there is some asynchronous logic inside the Effect:
+זה הופך להיות חשוב במיוחד אם יש היגיון אסינכרוני כלשהו בתוך האפקט:
```js {6,8}
const onVisit = useEffectEvent(visitedUrl => {
@@ -701,15 +701,15 @@ This becomes especially important if there is some asynchronous logic inside the
}, [url]);
```
-Here, `url` inside `onVisit` corresponds to the *latest* `url` (which could have already changed), but `visitedUrl` corresponds to the `url` that originally caused this Effect (and this `onVisit` call) to run.
+כאן, `url` בתוך `onVisit` תואם ל`כתובת האתר` *האחרונה* (שיכולה כבר הייתה להשתנות), אבל `visitedUrl` תואמת את ה-url שבמקור גרמה לאפקט הזה (ולקריאת `onVisit` זו) לפעול.
</Note>
<DeepDive>
-#### Is it okay to suppress the dependency linter instead? {/*is-it-okay-to-suppress-the-dependency-linter-instead*/}
+#### האם זה בסדר לדכא את קו התלות במקום זאת? {/*האם-זה-בסדר-להדכא-לנטרל-תלות-במקום-זאת*/}
-In the existing codebases, you may sometimes see the lint rule suppressed like this:
+בבסיסי הקוד הקיימים, לפעמים אתה עשוי לראות את כלל המוך מודחק כך:
```js {7-9}
function Page({ url }) {
@@ -725,13 +725,13 @@ function Page({ url }) {
}
```
-After `useEffectEvent` becomes a stable part of React, we recommend **never suppressing the linter**.
+לאחר ש-'useEffectEvent' הופך לחלק יציב ב-React, אנו ממליצים **לעולם לא לדכא את ה-linter**.
-The first downside of suppressing the rule is that React will no longer warn you when your Effect needs to "react" to a new reactive dependency you've introduced to your code. In the earlier example, you added `url` to the dependencies *because* React reminded you to do it. You will no longer get such reminders for any future edits to that Effect if you disable the linter. This leads to bugs.
+החיסרון הראשון של דיכוי הכלל הוא ש-React כבר לא מזהיר אותך כאשר האפקט שלך צריך "להגיב" לתלות תגובתית חדשה שהכנסת לקוד שלך. בדוגמה הקודמת, הוספת 'url' לתלויות *כי* React הזכיר לך לעשות זאת. לא תקבל עוד תזכורות כאלה עבור כל עריכה עתידית של אפקט זה אם תשבית את ה-linter. זה מוביל לבאגים.
-Here is an example of a confusing bug caused by suppressing the linter. In this example, the `handleMove` function is supposed to read the current `canMove` state variable value in order to decide whether the dot should follow the cursor. However, `canMove` is always `true` inside `handleMove`.
+הנה דוגמה לבאג מבלבל שנגרם על ידי דיכוי ה-linter. בדוגמה זו, הפונקציה `handleMove` אמורה לקרוא את ערך משתנה הstate הנוכחי `canMove` על מנת להחליט אם הנקודה צריכה לעקוב אחר הסמן. עם זאת, `canMove` תמיד `נכון` בתוך `handleMove`.
-Can you see why?
+אתה יכול לראות למה?
<Sandpack>
@@ -790,13 +790,13 @@ body {
</Sandpack>
-The problem with this code is in suppressing the dependency linter. If you remove the suppression, you'll see that this Effect should depend on the `handleMove` function. This makes sense: `handleMove` is declared inside the component body, which makes it a reactive value. Every reactive value must be specified as a dependency, or it can potentially get stale over time!
+הבעיה עם הקוד הזה היא בדיכוי ה-dependency linter. אם תסיר את הדיכוי, תראה שהאפקט הזה צריך להיות תלוי בפונקציה 'handleMove'. זה הגיוני: `handleMove` מוצהר בתוך גוף הרכיב, מה שהופך אותו לערך תגובתי. כל ערך תגובתי חייב להיות מוגדר כתלות, אחרת הוא עלול להתייאש עם הזמן!
-The author of the original code has "lied" to React by saying that the Effect does not depend (`[]`) on any reactive values. This is why React did not re-synchronize the Effect after `canMove` has changed (and `handleMove` with it). Because React did not re-synchronize the Effect, the `handleMove` attached as a listener is the `handleMove` function created during the initial render. During the initial render, `canMove` was `true`, which is why `handleMove` from the initial render will forever see that value.
+מחבר הקוד המקורי "שיקר" ל-React באומרו שהאפקט אינו תלוי (`[]`) בערכים תגובתיים כלשהם. זו הסיבה ש-React לא סינכרן מחדש את האפקט לאחר ש-'canMove' השתנה (ו-'handleMove' איתו). מכיוון ש-React לא סינכרן מחדש את האפקט, ה-'handleMove' המצורף כמאזין הוא הפונקציה 'handleMove' שנוצרה במהלך העיבוד הראשוני. במהלך העיבוד הראשוני, `canMove` היה `נכון`, וזו הסיבה ש`handleMove` מהרינדור הראשוני יראה לנצח את הערך הזה.
-**If you never suppress the linter, you will never see problems with stale values.**
+**אם לעולם לא תדחיק את ה-linter, לעולם לא תראה בעיות עם ערכים מיושנים.**
-With `useEffectEvent`, there is no need to "lie" to the linter, and the code works as you would expect:
+עם `useEffectEvent`, אין צורך "לשקר" ל-linter, והקוד עובד כפי שהיית מצפה:
<Sandpack>
@@ -870,26 +870,26 @@ body {
</Sandpack>
-This doesn't mean that `useEffectEvent` is *always* the correct solution. You should only apply it to the lines of code that you don't want to be reactive. In the above sandbox, you didn't want the Effect's code to be reactive with regards to `canMove`. That's why it made sense to extract an Effect Event.
+זה לא אומר ש-'useEffectEvent' הוא *תמיד* הפתרון הנכון. עליך להחיל אותו רק על שורות הקוד שאינך רוצה שיהיו תגובתיים. בארגז החול שלמעלה, לא רצית שהקוד של האפקט יהיה תגובתי לגבי `canMove`. לכן היה הגיוני לחלץ אירוע אפקט.
-Read [Removing Effect Dependencies](/learn/removing-effect-dependencies) for other correct alternatives to suppressing the linter.
+קרא את [הסרת תלות אפקט](/learn/removing-effect-dependencies) לקבלת חלופות נכונות אחרות לדיכוי ה-linter.
</DeepDive>
-### Limitations of Effect Events {/*limitations-of-effect-events*/}
+### מגבלות של אירועי אפקט {/*limitations-of-effect-events*/}
<Wip>
-This section describes an **experimental API that has not yet been released** in a stable version of React.
+סעיף זה מתאר **API ניסיוני שעדיין לא שוחרר** בגרסה יציבה של React.
</Wip>
-Effect Events are very limited in how you can use them:
+אירועי אפקט מוגבלים מאוד איך אתה יכול להשתמש בהם:
-* **Only call them from inside Effects.**
-* **Never pass them to other components or Hooks.**
+* **התקשר אליהם רק מתוך אפקטים.**
+* **לעולם אל תעביר אותם לרכיבים אחרים או לווים.**
-For example, don't declare and pass an Effect Event like this:
+לדוגמה, אל תצהיר ותעביר אירוע אפקט בצורה הבאה:
```js {4-6,8}
function Timer() {
@@ -916,7 +916,7 @@ function useTimer(callback, delay) {
}
```
-Instead, always declare Effect Events directly next to the Effects that use them:
+במקום זאת, תמיד הכריז על אפקט אירועים ישירות ליד האפקטים המשתמשים בהם:
```js {10-12,16,21}
function Timer() {
@@ -943,31 +943,31 @@ function useTimer(callback, delay) {
}
```
-Effect Events are non-reactive "pieces" of your Effect code. They should be next to the Effect using them.
+אירועי אפקט הם "חלקים" לא תגובתיים של קוד האפקט שלך. הם צריכים להיות ליד האפקט המשתמש בהם.
<Recap>
-- Event handlers run in response to specific interactions.
-- Effects run whenever synchronization is needed.
-- Logic inside event handlers is not reactive.
-- Logic inside Effects is reactive.
-- You can move non-reactive logic from Effects into Effect Events.
-- Only call Effect Events from inside Effects.
-- Don't pass Effect Events to other components or Hooks.
+- מטפלי אירועים פועלים בתגובה לאינטראקציות ספציפיות.
+- אפקטים פועלים בכל פעם שיש צורך בסנכרון.
+- ההיגיון בתוך מטפלי אירועים אינו תגובתי.
+- ההיגיון בתוך אפקטים הוא תגובתי.
+- אתה יכול להעביר לוגיקה לא תגובתית מאפקטים לאירועי אפקט.
+- התקשר רק ל-Effect Events מתוך Effects.
+- אל תעביר אירועי אפקט לרכיבים אחרים או הHooks.
</Recap>
<Challenges>
-#### Fix a variable that doesn't update {/*fix-a-variable-that-doesnt-update*/}
+#### תקן משתנה שלא מתעדכן {/*תקן-משתנה-שלא-מעדכן*/}
-This `Timer` component keeps a `count` state variable which increases every second. The value by which it's increasing is stored in the `increment` state variable. You can control the `increment` variable with the plus and minus buttons.
+רכיב 'טיימר' זה שומר על משתנה מצב 'ספירה' אשר גדל כל שנייה. הערך שבאמצעותו הוא גדל מאוחסן במשתנה הstate 'increment'. אתה יכול לשלוט במשתנה 'increment' עם לחצני הפלוס והמינוס.
-However, no matter how many times you click the plus button, the counter is still incremented by one every second. What's wrong with this code? Why is `increment` always equal to `1` inside the Effect's code? Find the mistake and fix it.
+עם זאת, לא משנה כמה פעמים תלחץ על כפתור הפלוס, המונה עדיין גדל באחד בכל שנייה. מה רע בקוד הזה? מדוע `increment` תמיד שווה ל`1` בתוך הקוד של האפקט? מצא את הטעות ותקן אותה.
<Hint>
-To fix this code, it's enough to follow the rules.
+כדי לתקן את הקוד הזה, מספיק לעקוב אחר הכללים.
</Hint>
@@ -1020,9 +1020,9 @@ button { margin: 10px; }
<Solution>
-As usual, when you're looking for bugs in Effects, start by searching for linter suppressions.
+כרגיל, כשאתה מחפש באגים ב- Effects, התחל בחיפוש אחר דיכוי לנטר.
-If you remove the suppression comment, React will tell you that this Effect's code depends on `increment`, but you "lied" to React by claiming that this Effect does not depend on any reactive values (`[]`). Add `increment` to the dependency array:
+אם תסיר את הערת הדיכוי, React יגיד לך שהקוד של אפקט זה תלוי ב-`increment`, אבל "שיקרת" ל-React בטענה שהאפקט הזה אינו תלוי בשום ערכים תגובתיים (`[]`). הוסף 'increment' למערך התלות:
<Sandpack>
@@ -1070,19 +1070,19 @@ button { margin: 10px; }
</Sandpack>
-Now, when `increment` changes, React will re-synchronize your Effect, which will restart the interval.
+כעת, כאשר ה'increment' משתנה, React יסנכרן מחדש את האפקט שלך, מה שיפעיל מחדש את המרווח.
</Solution>
-#### Fix a freezing counter {/*fix-a-freezing-counter*/}
+#### תקן מונה הקפאה {/*תיקון-א-הקפאה-מונה*/}
-This `Timer` component keeps a `count` state variable which increases every second. The value by which it's increasing is stored in the `increment` state variable, which you can control it with the plus and minus buttons. For example, try pressing the plus button nine times, and notice that the `count` now increases each second by ten rather than by one.
+רכיב 'טיימר' זה שומר על משתנה מצב 'ספירה' אשר גדל כל שנייה. הערך שבאמצעותו הוא גדל מאוחסן במשתנה הstate 'increment', שבו אתה יכול לשלוט בו באמצעות לחצני הפלוס והמינוס. לדוגמה, נסה ללחוץ על כפתור הפלוס תשע פעמים, ושם לב שה'ספירה' גדלה כעת בכל שנייה בעשר במקום באחת.
-There is a small issue with this user interface. You might notice that if you keep pressing the plus or minus buttons faster than once per second, the timer itself seems to pause. It only resumes after a second passes since the last time you've pressed either button. Find why this is happening, and fix the issue so that the timer ticks on *every* second without interruptions.
+יש בעיה קטנה בממשק המשתמש הזה. אולי תשים לב שאם תמשיך ללחוץ על כפתורי הפלוס או המינוס מהר יותר מפעם בשנייה, נראה שהטיימר עצמו נעצר. זה מתחדש רק לאחר שעוברת שנייה מאז הפעם האחרונה שלחצת על אחד מהלחצנים. מצא מדוע זה קורה, ותקן את הבעיה כך שהטיימר יפעל *כל* שנייה ללא הפרעות.
<Hint>
-It seems like the Effect which sets up the timer "reacts" to the `increment` value. Does the line that uses the current `increment` value in order to call `setCount` really need to be reactive?
+זה נראה כאילו האפקט שמגדיר את הטיימר "מגיב" לערך ה'increment'. האם השורה שמשתמשת בערך ה-'increment' הנוכחי כדי לקרוא ל-'setCount' באמת צריכה להיות תגובתית?
</Hint>
@@ -1151,9 +1151,9 @@ button { margin: 10px; }
<Solution>
-The issue is that the code inside the Effect uses the `increment` state variable. Since it's a dependency of your Effect, every change to `increment` causes the Effect to re-synchronize, which causes the interval to clear. If you keep clearing the interval every time before it has a chance to fire, it will appear as if the timer has stalled.
+הבעיה היא שהקוד בתוך האפקט משתמש במשתנה הstate 'increment'. מכיוון שזו תלות של האפקט שלך, כל שינוי ל-'increment' גורם לאפקט להסתנכרן מחדש, מה שגורם למרווח להתנקות. אם תמשיך לנקות את המרווח בכל פעם לפני שתהיה לו הזדמנות לירות, זה ייראה כאילו הטיימר נתקע.
-To solve the issue, extract an `onTick` Effect Event from the Effect:
+כדי לפתור את הבעיה, חלץ אירוע אפקט 'onTick' מהאפקט:
<Sandpack>
@@ -1223,17 +1223,17 @@ button { margin: 10px; }
</Sandpack>
-Since `onTick` is an Effect Event, the code inside it isn't reactive. The change to `increment` does not trigger any Effects.
+מכיוון ש-'onTick' הוא אירוע אפקט, הקוד שבתוכו אינו מגיב. השינוי ל'increment' אינו מפעיל אפקטים.
</Solution>
-#### Fix a non-adjustable delay {/*fix-a-non-adjustable-delay*/}
+#### תקן השהייה שאינה ניתנת להתאמה {/*fix-a-non-adjustable-delay*/}
-In this example, you can customize the interval delay. It's stored in a `delay` state variable which is updated by two buttons. However, even if you press the "plus 100 ms" button until the `delay` is 1000 milliseconds (that is, a second), you'll notice that the timer still increments very fast (every 100 ms). It's as if your changes to the `delay` are ignored. Find and fix the bug.
+בדוגמה זו, אתה יכול להתאים אישית את השהיית המרווחים. הוא מאוחסן במשתנה מצב 'עיכוב' שמתעדכן על ידי שני כפתורים. עם זאת, גם אם תלחץ על כפתור "פלוס 100 ms" עד שה-`השהיה` תהיה 1000 אלפיות השנייה (כלומר, שנייה), תבחין שהטיימר עדיין עולה מהר מאוד (כל 100 אלפיות השנייה). זה כאילו שמתעלמים מהשינויים שלך ב-`השהיה`. מצא ותקן את הבאג.
<Hint>
-Code inside Effect Events is not reactive. Are there cases in which you would _want_ the `setInterval` call to re-run?
+הקוד בתוך Effect Events אינו תגובתי. האם יש מקרים שבהם _תרצה_ שהקריאה 'setInterval' תפעל מחדש?
</Hint>
@@ -1322,7 +1322,7 @@ button { margin: 10px; }
<Solution>
-The problem with the above example is that it extracted an Effect Event called `onMount` without considering what the code should actually be doing. You should only extract Effect Events for a specific reason: when you want to make a part of your code non-reactive. However, the `setInterval` call *should* be reactive with respect to the `delay` state variable. If the `delay` changes, you want to set up the interval from scratch! To fix this code, pull all the reactive code back inside the Effect:
+הבעיה עם הדוגמה שלמעלה היא שהיא חילצה אירוע אפקט שנקרא 'onMount' מבלי לשקול מה הקוד אמור לעשות בפועל. עליך לחלץ אירועי אפקט רק מסיבה מסוימת: כאשר אתה רוצה להפוך חלק מהקוד שלך ללא תגובתי. עם זאת, הקריאה 'setInterval' *צריכה* להיות תגובתית ביחס למשתנה הstate 'השהיה'. אם 'השהיה' משתנה, אתה רוצה להגדיר את המרווח מאפס! כדי לתקן את הקוד הזה, משוך את כל הקוד התגובתי בחזרה לתוך האפקט:
<Sandpack>
@@ -1402,21 +1402,21 @@ button { margin: 10px; }
</Sandpack>
-In general, you should be suspicious of functions like `onMount` that focus on the *timing* rather than the *purpose* of a piece of code. It may feel "more descriptive" at first but it obscures your intent. As a rule of thumb, Effect Events should correspond to something that happens from the *user's* perspective. For example, `onMessage`, `onTick`, `onVisit`, or `onConnected` are good Effect Event names. Code inside them would likely not need to be reactive. On the other hand, `onMount`, `onUpdate`, `onUnmount`, or `onAfterRender` are so generic that it's easy to accidentally put code that *should* be reactive into them. This is why you should name your Effect Events after *what the user thinks has happened,* not when some code happened to run.
+באופן כללי, אתה צריך לחשוד בפונקציות כמו 'onMount' המתמקדות ב*תזמון* ולא ב*מטרה* של קטע קוד. זה אולי מרגיש "יותר תיאורי" בהתחלה אבל זה מטשטש את הכוונה שלך. ככלל אצבע, אירועי אפקט צריכים להתאים למשהו שקורה מנקודת המבט של *המשתמש*. לדוגמה, `onMessage`, `onTick`, `onVisit` או `onConnected` הם שמות אירועי אפקט טובים. סביר להניח שהקוד בתוכם לא יצטרך להיות תגובתי. מצד שני, `onMount`, `onUpdate`, `onUnmount` או `onAfterRender` הם כל כך גנריים שקל להכניס בהם בטעות קוד ש*צריך* להיות תגובתי. זו הסיבה שאתה צריך לקרוא ל-Effect Events שלך על שם *מה שהמשתמש חושב שקרה,* לא כאשר במקרה רץ קוד כלשהו.
</Solution>
-#### Fix a delayed notification {/*fix-a-delayed-notification*/}
+#### תקן התראה מושהית {/*fix-a-delayed-notification*/}
-When you join a chat room, this component shows a notification. However, it doesn't show the notification immediately. Instead, the notification is artificially delayed by two seconds so that the user has a chance to look around the UI.
+כאשר אתה מצטרף לחדר צ'אט, רכיב זה מציג התראה. עם זאת, זה לא מציג את ההודעה מיד. במקום זאת, ההודעה מתעכבת באופן מלאכותי בשתי שניות, כך שלמשתמש יש הזדמנות להסתכל סביב ממשק המשתמש.
-This almost works, but there is a bug. Try changing the dropdown from "general" to "travel" and then to "music" very quickly. If you do it fast enough, you will see two notifications (as expected!) but they will *both* say "Welcome to music".
+זה כמעט עובד, אבל יש באג. נסה לשנות את התפריט הנפתח מ"כללי" ל"נסיעות" ואז ל"מוזיקה" מהר מאוד. אם תעשה את זה מספיק מהר, תראה שתי התראות (כצפוי!) אבל *שתיהן* יגידו "ברוכים הבאים למוזיקה".
-Fix it so that when you switch from "general" to "travel" and then to "music" very quickly, you see two notifications, the first one being "Welcome to travel" and the second one being "Welcome to music". (For an additional challenge, assuming you've *already* made the notifications show the correct rooms, change the code so that only the latter notification is displayed.)
+תקן את זה כך שכשאתה עובר מ"כללי" ל"נסיעות" ואז ל"מוזיקה" מהר מאוד, תראה שתי התראות, הראשונה היא "ברוכים הבאים לנסיעה" והשנייה היא "ברוכים הבאים למוזיקה". (לאתגר נוסף, בהנחה ש*כבר* גרמת להודעות להציג את החדרים הנכונים, שנה את הקוד כך שרק ההודעה האחרונה תוצג).
<Hint>
-Your Effect knows which room it connected to. Is there any information that you might want to pass to your Effect Event?
+האפקט שלך יודע לאיזה חדר הוא התחבר. האם יש מידע שאולי תרצה להעביר לאירוע האפקט שלך?
</Hint>
@@ -1555,11 +1555,11 @@ label { display: block; margin-top: 10px; }
<Solution>
-Inside your Effect Event, `roomId` is the value *at the time Effect Event was called.*
+בתוך אירוע האפקט שלך, 'roomId' הוא הערך *בזמן הקריאה לאירוע אפקט.*
-Your Effect Event is called with a two second delay. If you're quickly switching from the travel to the music room, by the time the travel room's notification shows, `roomId` is already `"music"`. This is why both notifications say "Welcome to music".
+אירוע האפקט שלך נקרא בהשהייה של שתי שניות. אם אתה עובר במהירות מהנסיעה לחדר המוזיקה, כאשר מופיעה ההתראה של חדר הנסיעות, `roomId` הוא כבר `"מוזיקה"`. זו הסיבה ששתי ההתראות אומרות "ברוכים הבאים למוזיקה".
-To fix the issue, instead of reading the *latest* `roomId` inside the Effect Event, make it a parameter of your Effect Event, like `connectedRoomId` below. Then pass `roomId` from your Effect by calling `onConnected(roomId)`:
+כדי לתקן את הבעיה, במקום לקרוא את ה'roomId' *האחרון* בתוך אירוע האפקט, הפוך אותו לפרמטר של אירוע האפקט שלך, כמו 'connectedRoomId' למטה. לאחר מכן העבר את 'roomId' מהאפקט שלך על ידי קריאה ל'onConnected(roomId)':
<Sandpack>
@@ -1694,9 +1694,9 @@ label { display: block; margin-top: 10px; }
</Sandpack>
-The Effect that had `roomId` set to `"travel"` (so it connected to the `"travel"` room) will show the notification for `"travel"`. The Effect that had `roomId` set to `"music"` (so it connected to the `"music"` room) will show the notification for `"music"`. In other words, `connectedRoomId` comes from your Effect (which is reactive), while `theme` always uses the latest value.
+האפקט ש-'roomId' הוגדר ל-'"travel"' (כך שהוא התחבר לחדר ה-''travel'') יציג את ההתראה עבור ''travel''. האפקט שבו הוגדר `roomId` ל-`"מוזיקה"` (כך שהוא התחבר לחדר `"מוזיקה"`) יציג את ההתראה עבור `"מוזיקה"`. במילים אחרות, `connectedRoomId` מגיע מהאפקט שלך (שהינו תגובתי), בעוד `theme` משתמש תמיד בערך האחרון.
-To solve the additional challenge, save the notification timeout ID and clear it in the cleanup function of your Effect:
+כדי לפתור את האתגר הנוסף, שמור את מזהה הזמן הקצוב להודעה ונקה אותו בפונקציית הניקוי של האפקט שלך:
<Sandpack>
@@ -1837,8 +1837,9 @@ label { display: block; margin-top: 10px; }
</Sandpack>
-This ensures that already scheduled (but not yet displayed) notifications get cancelled when you change rooms.
+זה מבטיח שהתראות שכבר מתוזמנות (אך עדיין לא הוצגו) יבוטלו כאשר אתה מחליף חדר.
</Solution>
</Challenges>
+
diff --git a/src/content/learn/sharing-state-between-components.md b/src/content/learn/sharing-state-between-components.md
index 52eaf28f8..8d5888239 100644
--- a/src/content/learn/sharing-state-between-components.md
+++ b/src/content/learn/sharing-state-between-components.md
@@ -1,31 +1,31 @@
---
-title: Sharing State Between Components
+title: "שיתוף state בין קומפוננטות"
---
<Intro>
-Sometimes, you want the state of two components to always change together. To do it, remove state from both of them, move it to their closest common parent, and then pass it down to them via props. This is known as *lifting state up,* and it's one of the most common things you will do writing React code.
+לפעמים, אתה רוצה שstateם של שני רכיבים ישתנה תמיד ביחד. כדי לעשות זאת, הסר מצב משניהם, העבר אותו להורה המשותף הקרוב ביותר שלהם, ולאחר מכן העביר אותו אליהם באמצעות props. זה ידוע בתור *lifting state up* וזה אחד הדברים הנפוצים ביותר שתעשו בכתיבת קוד React.
</Intro>
<YouWillLearn>
-- How to share state between components by lifting it up
-- What are controlled and uncontrolled components
+- כיצד לחלוק מצב בין רכיבים על ידי הרמתו למעלה
+- מהם רכיבים מבוקרים ובלתי מבוקרים
</YouWillLearn>
-## Lifting state up by example {/*lifting-state-up-by-example*/}
+## מצב הרמה למעלה לפי דוגמה {/*הרמה-מצב-מעלה-לפי-דוגמה*/}
-In this example, a parent `Accordion` component renders two separate `Panel`s:
+בדוגמה זו, רכיב 'אקורדיון' אב יוצר שני 'פאנלים' נפרדים:
-* `Accordion`
- - `Panel`
- - `Panel`
+* `אקורדיון`
+ - `פאנל`
+ - `פאנל`
-Each `Panel` component has a boolean `isActive` state that determines whether its content is visible.
+לכל רכיב 'פאנל' יש מצב 'isActive' בוליאני שקובע אם התוכן שלו גלוי.
-Press the Show button for both panels:
+לחץ על כפתור הצג עבור שני הפאנלים:
<Sandpack>
@@ -73,59 +73,59 @@ h3, p { margin: 5px 0px; }
</Sandpack>
-Notice how pressing one panel's button does not affect the other panel--they are independent.
+שימו לב כיצד לחיצה על כפתור של לוח אחד לא משפיעה על הלוח השני - הם עצמאיים.
<DiagramGroup>
<Diagram name="sharing_state_child" height={367} width={477} alt="Diagram showing a tree of three components, one parent labeled Accordion and two children labeled Panel. Both Panel components contain isActive with value false.">
-Initially, each `Panel`'s `isActive` state is `false`, so they both appear collapsed
+בתחילה, מצב ה-'isActive' של כל 'פאנל' הוא 'שקר', כך ששניהם נראים מכווצים
</Diagram>
<Diagram name="sharing_state_child_clicked" height={367} width={480} alt="The same diagram as the previous, with the isActive of the first child Panel component highlighted indicating a click with the isActive value set to true. The second Panel component still contains value false." >
-Clicking either `Panel`'s button will only update that `Panel`'s `isActive` state alone
+לחיצה על כפתורי ה'פאנל' תעדכן רק את מצב ה'isActive' של אותו 'פאנל' בלבד
</Diagram>
</DiagramGroup>
-**But now let's say you want to change it so that only one panel is expanded at any given time.** With that design, expanding the second panel should collapse the first one. How would you do that?
+**אבל עכשיו נניח שאתה רוצה לשנות אותו כך שרק לוח אחד יורחב בכל זמן נתון.** עם העיצוב הזה, הרחבת הפאנל השני אמורה לכווץ את הלוח הראשון. איך היית עושה את זה?
-To coordinate these two panels, you need to "lift their state up" to a parent component in three steps:
+כדי לתאם את שני הלוחות הללו, עליך "להרים את מצבם" לרכיב אב בשלושה שלבים:
-1. **Remove** state from the child components.
-2. **Pass** hardcoded data from the common parent.
-3. **Add** state to the common parent and pass it down together with the event handlers.
+1. **הסר** מצב ממרכיבי הצאצא.
+2. **עבר** נתונים מקודדים מההורה המשותף.
+3. **הוסף** מצב להורה המשותף והעביר אותו יחד עם מטפלי האירועים.
-This will allow the `Accordion` component to coordinate both `Panel`s and only expand one at a time.
+זה יאפשר לרכיב 'אקורדיון' לתאם את שני ה'פאנלים' ולהרחיב רק אחד בכל פעם.
-### Step 1: Remove state from the child components {/*step-1-remove-state-from-the-child-components*/}
+### שלב 1: הסר מצב מהרכיבים הצאצאים {/*step-1-remove-state-from-the-child-components*/}
-You will give control of the `Panel`'s `isActive` to its parent component. This means that the parent component will pass `isActive` to `Panel` as a prop instead. Start by **removing this line** from the `Panel` component:
+אתה תיתן שליטה ב-'isActive' של ה-Panel לרכיב האב שלו. משמעות הדבר היא שרכיב האב יעביר את 'isActive' ל'פאנל' בתור props במקום. התחל על ידי **הסרת השורה הזו** מהרכיב 'פאנל':
```js
const [isActive, setIsActive] = useState(false);
```
-And instead, add `isActive` to the `Panel`'s list of props:
+ובמקום זאת, הוסף את 'isActive' לרשימת הprops של ה'פאנל':
```js
function Panel({ title, children, isActive }) {
```
-Now the `Panel`'s parent component can *control* `isActive` by [passing it down as a prop.](/learn/passing-props-to-a-component) Conversely, the `Panel` component now has *no control* over the value of `isActive`--it's now up to the parent component!
+כעת רכיב האב של `הפאנל` יכול *לשלוט* ב`isActive` על ידי [העברתו בתור אב.](/learn/passing-props-to-a-component) לעומת זאת, לרכיב `Panel` אין כעת *שליטה* על הערך של `isActive`--זה תלוי כעת ברכיב האב!
-### Step 2: Pass hardcoded data from the common parent {/*step-2-pass-hardcoded-data-from-the-common-parent*/}
+### שלב 2: העבר נתונים מקודדים קשיחים מההורה המשותף {/*שלב-2-מעבר-המקודד-הקשה-נתונים-מההורה-המשותף*/}
-To lift state up, you must locate the closest common parent component of *both* of the child components that you want to coordinate:
+כדי להעלות את הstate למעלה, עליך לאתר את רכיב האב המשותף הקרוב ביותר של *שני* רכיבי הצאצא שברצונך לתאם:
-* `Accordion` *(closest common parent)*
- - `Panel`
- - `Panel`
+* `אקורדיון` *(הורה המשותף הקרוב ביותר)*
+ - `פאנל`
+ - `פאנל`
-In this example, it's the `Accordion` component. Since it's above both panels and can control their props, it will become the "source of truth" for which panel is currently active. Make the `Accordion` component pass a hardcoded value of `isActive` (for example, `true`) to both panels:
+בדוגמה זו, זה רכיב 'אקורדיון'. מכיוון שהוא מעל שני הפאנלים ויכול לשלוט בprops שלהם, הוא יהפוך ל"מקור האמת" שעבורו הפאנל פעיל כרגע. הפוך את הרכיב 'אקורדיון' להעביר ערך מקודד של 'isActive' (לדוגמה, 'true') לשני הפאנלים:
<Sandpack>
@@ -172,21 +172,21 @@ h3, p { margin: 5px 0px; }
</Sandpack>
-Try editing the hardcoded `isActive` values in the `Accordion` component and see the result on the screen.
+נסה לערוך את ערכי ה-'isActive' המקודדים ברכיב 'אקורדיון' וראה את התוצאה על המסך.
-### Step 3: Add state to the common parent {/*step-3-add-state-to-the-common-parent*/}
+### שלב 3: הוסף מצב להורה המשותף {/*step-3-add-state-to-the-common-parent*/}
-Lifting state up often changes the nature of what you're storing as state.
+הרמת מצב למעלה משנה לעתים קרובות את האופי של מה שאתה מאחסן כstate.
-In this case, only one panel should be active at a time. This means that the `Accordion` common parent component needs to keep track of *which* panel is the active one. Instead of a `boolean` value, it could use a number as the index of the active `Panel` for the state variable:
+במקרה זה, רק פאנל אחד צריך להיות פעיל בכל פעם. משמעות הדבר היא שרכיב האב הנפוץ 'אקורדיון' צריך לעקוב אחר *איזה* פאנל הוא הפאנל הפעיל. במקום ערך 'בוליאני', הוא יכול להשתמש במספר בתור האינדקס של ה'פאנל' הפעיל עבור משתנה הstate:
```js
const [activeIndex, setActiveIndex] = useState(0);
```
-When the `activeIndex` is `0`, the first panel is active, and when it's `1`, it's the second one.
+כאשר `activeIndex` הוא `0`, החלונית הראשונה פעילה, וכאשר היא `1`, היא השנייה.
-Clicking the "Show" button in either `Panel` needs to change the active index in `Accordion`. A `Panel` can't set the `activeIndex` state directly because it's defined inside the `Accordion`. The `Accordion` component needs to *explicitly allow* the `Panel` component to change its state by [passing an event handler down as a prop](/learn/responding-to-events#passing-event-handlers-as-props):
+לחיצה על כפתור "הצג" בכל אחד מה'פאנלים' צריכה לשנות את האינדקס הפעיל ב'אקורדיון'. `פאנל` לא יכול להגדיר את מצב `activeIndex` ישירות מכיוון שהוא מוגדר בתוך `האקורדיון`. הרכיב 'אקורדיון' צריך *לאפשר* במפורש לרכיב ה'פאנל' לשנות את מצבו על ידי [העברת מטפל באירועים כעזר](/learn/responding-to-events#passing-event-handlers-as-props):
```js
<>
@@ -205,7 +205,7 @@ Clicking the "Show" button in either `Panel` needs to change the active index in
</>
```
-The `<button>` inside the `Panel` will now use the `onShow` prop as its click event handler:
+ה-`<button>` בתוך ה-Panel ישתמש כעת ב-'onShow' כמטפל באירועי קליק שלו:
<Sandpack>
@@ -266,19 +266,19 @@ h3, p { margin: 5px 0px; }
</Sandpack>
-This completes lifting state up! Moving state into the common parent component allowed you to coordinate the two panels. Using the active index instead of two "is shown" flags ensured that only one panel is active at a given time. And passing down the event handler to the child allowed the child to change the parent's state.
+זה משלים את מצב הרמה למעלה! העברת הstate לרכיב האב המשותף אפשרה לך לתאם את שני הפאנלים. שימוש באינדקס הפעיל במקום שני דגלים "מוצג" הבטיח שרק פאנל אחד פעיל בזמן נתון. והעברת מטפל האירוע לילד אפשרה לילד לשנות את מצב ההורה.
<DiagramGroup>
<Diagram name="sharing_state_parent" height={385} width={487} alt="Diagram showing a tree of three components, one parent labeled Accordion and two children labeled Panel. Accordion contains an activeIndex value of zero which turns into isActive value of true passed to the first Panel, and isActive value of false passed to the second Panel." >
-Initially, `Accordion`'s `activeIndex` is `0`, so the first `Panel` receives `isActive = true`
+בתחילה, `activeIndex` של `Accordion` הוא `0`, כך שה`פאנל` הראשון מקבל `isActive = true`
</Diagram>
<Diagram name="sharing_state_parent_clicked" height={385} width={521} alt="The same diagram as the previous, with the activeIndex value of the parent Accordion component highlighted indicating a click with the value changed to one. The flow to both of the children Panel components is also highlighted, and the isActive value passed to each child is set to the opposite: false for the first Panel and true for the second one." >
-When `Accordion`'s `activeIndex` state changes to `1`, the second `Panel` receives `isActive = true` instead
+כאשר מצב `activeIndex` של `Accordion` משתנה ל`1`, ה`פאנל` השני מקבל במקום זאת `isActive = true`
</Diagram>
@@ -286,48 +286,48 @@ When `Accordion`'s `activeIndex` state changes to `1`, the second `Panel` receiv
<DeepDive>
-#### Controlled and uncontrolled components {/*controlled-and-uncontrolled-components*/}
+#### רכיבים מבוקרים ובלתי מבוקרים {/*רכיבים-מבוקרים-ובלתי-מבוקרים*/}
-It is common to call a component with some local state "uncontrolled". For example, the original `Panel` component with an `isActive` state variable is uncontrolled because its parent cannot influence whether the panel is active or not.
+מקובל לקרוא לרכיב עם state מקומית כלשהי "לא מבוקר". לדוגמה, רכיב ה-'Panel' המקורי עם משתנה הstate 'isActive' אינו מבוקר מכיוון שהאב שלו אינו יכול להשפיע אם הפאנל פעיל או לא.
-In contrast, you might say a component is "controlled" when the important information in it is driven by props rather than its own local state. This lets the parent component fully specify its behavior. The final `Panel` component with the `isActive` prop is controlled by the `Accordion` component.
+לעומת זאת, אפשר לומר שרכיב "נשלט" כאשר המידע החשוב בו מונע על ידי props ולא על ידי הstate המקומית שלו. זה מאפשר לרכיב האב לציין באופן מלא את ההתנהגות שלו. רכיב ה'פאנל' הסופי עם הprops 'isActive' נשלט על ידי רכיב ה'אקורדיון'.
-Uncontrolled components are easier to use within their parents because they require less configuration. But they're less flexible when you want to coordinate them together. Controlled components are maximally flexible, but they require the parent components to fully configure them with props.
+רכיבים לא מבוקרים קלים יותר לשימוש בתוך הוריהם מכיוון שהם דורשים פחות תצורה. אבל הם פחות גמישים כשרוצים לתאם אותם יחד. רכיבים מבוקרים הם גמישים בצורה מקסימלית, אך הם דורשים מרכיבי האב להגדיר אותם במלואם עם props.
-In practice, "controlled" and "uncontrolled" aren't strict technical terms--each component usually has some mix of both local state and props. However, this is a useful way to talk about how components are designed and what capabilities they offer.
+בפועל, "נשלט" ו"בלתי מבוקר" אינם מונחים טכניים קפדניים - לכל רכיב יש בדרך כלל שילוב מסוים של state מקומית ושל props. עם זאת, זוהי דרך שימושית לדבר על האופן שבו רכיבים מתוכננים ומה היכולות שהם מציעים.
-When writing a component, consider which information in it should be controlled (via props), and which information should be uncontrolled (via state). But you can always change your mind and refactor later.
+בעת כתיבת רכיב, שקול איזה מידע בו יש לשלוט (באמצעות props), ואיזה מידע צריך להיות בלתי מבוקר (דרך הstate). אבל אתה תמיד יכול לשנות את דעתך ולהתחיל מחדש מאוחר יותר.
</DeepDive>
-## A single source of truth for each state {/*a-single-source-of-truth-for-each-state*/}
+## מקור אמת יחיד לכל state {/*מקור-יחיד-של-אמת-לכל-state*/}
-In a React application, many components will have their own state. Some state may "live" close to the leaf components (components at the bottom of the tree) like inputs. Other state may "live" closer to the top of the app. For example, even client-side routing libraries are usually implemented by storing the current route in the React state, and passing it down by props!
+ביישום React, לרכיבים רבים יהיה מצב משלהם. מצב מסוים עשוי "לחיות" קרוב לרכיבי העלים (רכיבים בתחתית העץ) כמו תשומות. מצב אחר עשוי "לגור" קרוב יותר לחלק העליון של האפליקציה. לדוגמה, אפילו ספריות ניתוב בצד הלקוח מיושמות בדרך כלל על ידי אחסון המסלול הנוכחי בstate React והעברתו על ידי props!
-**For each unique piece of state, you will choose the component that "owns" it.** This principle is also known as having a ["single source of truth".](https://en.wikipedia.org/wiki/Single_source_of_truth) It doesn't mean that all state lives in one place--but that for _each_ piece of state, there is a _specific_ component that holds that piece of information. Instead of duplicating shared state between components, *lift it up* to their common shared parent, and *pass it down* to the children that need it.
+**עבור כל פיסת state ייחודית, תבחר את הרכיב ש"הבעלים" שלו.** עיקרון זה ידוע גם כבעל ["מקור אחד של אמת".](https://en.wikipedia.org/wiki/Single_source_of_truth) זה לא אומר שכל הstate חיה במקום אחד - אבל שלכל רכיב זה ישנה נתח מידע ספציפי. במקום לשכפל מצב משותף בין רכיבים, *להרים אותו* להורה המשותף שלהם, ו*להעביר אותו* לילדים שזקוקים לו.
-Your app will change as you work on it. It is common that you will move state down or back up while you're still figuring out where each piece of the state "lives". This is all part of the process!
+האפליקציה שלך תשתנה תוך כדי עבודה עליה. זה נפוץ שתזוז את הstate למטה או בחזרה למעלה בזמן שאתה עדיין מגלה היכן כל חלק של הstate "חי". כל זה חלק מהתהליך!
-To see what this feels like in practice with a few more components, read [Thinking in React.](/learn/thinking-in-react)
+כדי לראות איך זה מרגיש בפועל עם עוד כמה רכיבים, קרא את [Thinking in React.](/learn/thinking-in-react)
<Recap>
-* When you want to coordinate two components, move their state to their common parent.
-* Then pass the information down through props from their common parent.
-* Finally, pass the event handlers down so that the children can change the parent's state.
-* It's useful to consider components as "controlled" (driven by props) or "uncontrolled" (driven by state).
+* כאשר אתה רוצה לתאם שני מרכיבים, העבר את מצבם להורה המשותף שלהם.
+* לאחר מכן העבירו את המידע דרך props מההורה המשותף שלהם.
+* לבסוף, העבירו את מטפלי האירועים כדי שהילדים יוכלו לשנות את מצב ההורה.
+* כדאי להתייחס לרכיבים כ"מבוקרים" (מונעים על ידי props) או "בלתי נשלטים" (מונעים על ידי state).
</Recap>
<Challenges>
-#### Synced inputs {/*synced-inputs*/}
+#### כניסות מסונכרנות {/*כניסות-מסונכרנות*/}
-These two inputs are independent. Make them stay in sync: editing one input should update the other input with the same text, and vice versa.
+שתי כניסות אלו אינן תלויות. לגרום להם להישאר מסונכרנים: עריכת קלט אחד אמורה לעדכן את הקלט השני באותו טקסט, ולהיפך.
<Hint>
-You'll need to lift their state up into the parent component.
+תצטרך להעלות את הstate שלהם לתוך רכיב האב.
</Hint>
@@ -374,7 +374,7 @@ label { display: block; }
<Solution>
-Move the `text` state variable into the parent component along with the `handleChange` handler. Then pass them down as props to both of the `Input` components. This will keep them in sync.
+העבר את משתנה הstate 'טקסט' לתוך רכיב האב יחד עם המטפל 'handleChange'. לאחר מכן העבירו אותם כprops לשני רכיבי ה'קלט'. זה ישמור אותם מסונכרנים.
<Sandpack>
@@ -427,17 +427,17 @@ label { display: block; }
</Solution>
-#### Filtering a list {/*filtering-a-list*/}
+#### סינון רשימה {/*filtering-a-list*/}
-In this example, the `SearchBar` has its own `query` state that controls the text input. Its parent `FilterableList` component displays a `List` of items, but it doesn't take the search query into account.
+בדוגמה זו, ל-SearchBar יש מצב 'שאילתה' משלו השולט בקלט הטקסט. רכיב האב 'FilterableList' שלו מציג 'רשימה' של פריטים, אבל הוא לא לוקח בחשבון את שאילתת החיפוש.
-Use the `filterItems(foods, query)` function to filter the list according to the search query. To test your changes, verify that typing "s" into the input filters down the list to "Sushi", "Shish kebab", and "Dim sum".
+השתמש בפונקציה 'filterItems(foods, query)' כדי לסנן את הרשימה לפי שאילתת החיפוש. כדי לבדוק את השינויים שלך, ודא שהקלדת "s" במסנני הקלט מסננת למטה ברשימה "סושי", "שיש קבב" ו"דים סאם".
-Note that `filterItems` is already implemented and imported so you don't need to write it yourself!
+שים לב ש-'filterItems' כבר מיושם ומיובא כך שאתה לא צריך לכתוב את זה בעצמך!
<Hint>
-You will want to remove the `query` state and the `handleChange` handler from the `SearchBar`, and move them to the `FilterableList`. Then pass them down to `SearchBar` as `query` and `onChange` props.
+תרצה להסיר את מצב ה-'שאילתה' ואת המטפל 'handleChange' מ'סרגל החיפוש', ולהעביר אותם ל-'FilterableList'. לאחר מכן העבירו אותם אל 'סרגל החיפוש' בתור props 'שאילתה' ו-'onChange'.
</Hint>
@@ -528,7 +528,7 @@ export const foods = [{
<Solution>
-Lift the `query` state up into the `FilterableList` component. Call `filterItems(foods, query)` to get the filtered list and pass it down to the `List`. Now changing the query input is reflected in the list:
+הרם את מצב ה-'שאילתה' למעלה לתוך הרכיב 'FilterableList'. התקשר ל'filterItems(foods, query)' כדי לקבל את הרשימה המסוננת ולהעביר אותה אל ה'רשימה'. כעת שינוי קלט השאילתה בא לידי ביטוי ברשימה:
<Sandpack>
@@ -622,3 +622,4 @@ export const foods = [{
</Solution>
</Challenges>
+
diff --git a/src/content/learn/start-a-new-react-project.md b/src/content/learn/start-a-new-react-project.md
index bd5ba6c50..4f551ced5 100644
--- a/src/content/learn/start-a-new-react-project.md
+++ b/src/content/learn/start-a-new-react-project.md
@@ -1,107 +1,107 @@
---
-title: Start a New React Project
+title: "התחלת פרויקט React חדש"
---
<Intro>
-If you want to build a new app or a new website fully with React, we recommend picking one of the React-powered frameworks popular in the community.
+אם אתם רוצים לבנות אפליקציה חדשה או אתר חדש שמבוססים על React, אנחנו ממליצים לבחור אחד מה-frameworks הפופולריים שמונעים על ידי React.
</Intro>
-You can use React without a framework, however we’ve found that most apps and sites eventually build solutions to common problems such as code-splitting, routing, data fetching, and generating HTML. These problems are common to all UI libraries, not just React.
+אפשר להשתמש ב-React גם בלי מסגרת, אבל ראינו שרוב האפליקציות והאתרים בסוף בונים פתרונות לבעיות נפוצות כמו פיצול קוד, ניתוב, שליפת נתונים ויצירת HTML. אלה בעיות משותפות לכל ספריות ה-UI, לא רק ל-React.
-By starting with a framework, you can get started with React quickly, and avoid essentially building your own framework later.
+אם מתחילים עם מסגרת אפשר להתחיל לעבוד מהר עם React, ולהימנע מstate שבו אנו תבנו מסגרת משלכם בהמשך.
<DeepDive>
-#### Can I use React without a framework? {/*can-i-use-react-without-a-framework*/}
+#### האם אפשר להשתמש ב-React בלי framework? {/*אני-יכול-להשתמש-להגיב-ללא-מסגרת*/}
-You can definitely use React without a framework--that's how you'd [use React for a part of your page.](/learn/add-react-to-an-existing-project#using-react-for-a-part-of-your-existing-page) **However, if you're building a new app or a site fully with React, we recommend using a framework.**
+אפשר להשתמש ב-React בלי framework, כך בדיוק [משתמשים ב-React רק עבור חלק מהעמוד.](/learn/add-react-to-an-existing-project#using-react-for-a-part-of-your-existing-page) **אבל אם אתם בונים אפליקציה חדשה או אתר חדש ב-React, בהחלט אנחנו ממליצים להשתמש ב-
-Here's why.
+הנה למה.
-Even if you don't need routing or data fetching at first, you'll likely want to add some libraries for them. As your JavaScript bundle grows with every new feature, you might have to figure out how to split code for every route individually. As your data fetching needs get more complex, you are likely to encounter server-client network waterfalls that make your app feel very slow. As your audience includes more users with poor network conditions and low-end devices, you might need to generate HTML from your components to display content early--either on the server, or during the build time. Changing your setup to run some of your code on the server or during the build can be very tricky.
+גם אם בהתחלה לא צריך ניתוב או שליפת נתונים, סביר שבהמשך תרצו להוסיף ספריות לכך. ככל שחבילת ה-JavaScript שלכם תגדל עם כל יכולת חדשה, אפשר שתצטרכו להבין איך לפצל קוד לכל מסלול בנפרד. שצורכי שליפת מסתכלים, סביר שתיתקלו ב-waterfalls של רשת בין שרת ללקוח שיגרמו לאפליקציה להרגיש איטית מאוד. ככל שהקהל יכלול יותר משתמשים עם חלשה ומכשירים חלשים, אפשר שתצטרכו רשת HTML מהקומפוננט כדי להציג תוכן מוקדם, בשרת או בזמן לבנות. שינוי ה-setup כך שחלק מהקוד ירוץ בשרת או בזמן לבנות יכול להיות מורכב מאוד.
-**These problems are not React-specific. This is why Svelte has SvelteKit, Vue has Nuxt, and so on.** To solve these problems on your own, you'll need to integrate your bundler with your router and with your data fetching library. It's not hard to get an initial setup working, but there are a lot of subtleties involved in making an app that loads quickly even as it grows over time. You'll want to send down the minimal amount of app code but do so in a single client–server roundtrip, in parallel with any data required for the page. You'll likely want the page to be interactive before your JavaScript code even runs, to support progressive enhancement. You may want to generate a folder of fully static HTML files for your marketing pages that can be hosted anywhere and still work with JavaScript disabled. Building these capabilities yourself takes real work.
+**הבעיות האלה לא ייחודיות ל-React. לכן ל-Svelte יש SvelteKit, ל-Vue יש Nuxt וכן הלאה.** כדי לפתור זאת לבד, תצטרכו לשלב בין הבאנדלר לראוטר ולספריית שליפת הארגון. לא קשה להגיע להתקנה ראשוני שעובד, אבל יש הרבה ניואנסים ביצירת אפליקציה שננתה מהר גם כשהיא גדלה לאורך זמן. תרצו לשלוח את הפעולות הנכנסות לקוד האפליקציה, אבל זאת בסבב לקוח-שרת אחד ובמקביל לכל הדרושים. כנראה תרצו שהעמוד יהיה אינטראקטיבי עוד לפני שה-JavaScript רץ בפועל, כדי לתמוך בשיפור מתקדם. אפשר לאחסן בכל מקום ועד יעבדו גם כש-JavaScript כבוי. בנייה עצמית של היכולות האלה דורשת עבודה אמיתית.
-**React frameworks on this page solve problems like these by default, with no extra work from your side.** They let you start very lean and then scale your app with your needs. Each React framework has a community, so finding answers to questions and upgrading tooling is easier. Frameworks also give structure to your code, helping you and others retain context and skills between different projects. Conversely, with a custom setup it's easier to get stuck on unsupported dependency versions, and you'll essentially end up creating your own framework—albeit one with no community or upgrade path (and if it's anything like the ones we've made in the past, more haphazardly designed).
+**ה-frameworks של React בעמוד הזה פותרים בעיות כאלה כברירת מחדל, בלי עבודה נוספת מצדכם.** הם יכולים להתחיל בצורה רזה מאוד ואז להגדיל את האפליקציה לפי הצורך. לכל מסגרת יש קהילה, יש קל יותר תשובות ולשדרג כלי עבודה. frameworks גם נותנים מבנה לקוד ועוזרים לכם לשמור על הקשר וידע בין פרויקטים שונים. לעומת זאת, ב-setup מותאם אישית קל יותר להיתקע על גרסאות תלויות לא נתמכות, ובפועל תמצאו את עצמכם בונים מסגרת משלכם, רק בלי קהילה ובלי נתיב שדרוג (ואם זה כמו הדברים שאנחנו בנינו בעבר, גם פחות מסודר).
-If your app has unusual constraints not served well by these frameworks, or you prefer to solve these problems yourself, you can roll your own custom setup with React. Grab `react` and `react-dom` from npm, set up your custom build process with a bundler like [Vite](https://vitejs.dev/) or [Parcel](https://parceljs.org/), and add other tools as you need them for routing, static generation or server-side rendering, and more.
+אם לאפליקציה שלכם יש אילוצים חריגים שה-frameworks האלה לא משרתים טוב, או שאתם מעדיפים לפתור את הכול בעצמכם, אפשר לבנות הגדרה אישית עם React. קחו `react` ו-`react-dom` מ-npm, הגדירו בתהליך לבנות עם bundler כמו [Vite](https://vitejs.dev/) או [Parcel](https://parceljs.org/), והוסיפו כלים נוספים עבור ניתוב, יצירה סטטית, רינדור צד שרת ועוד.
</DeepDive>
-## Production-grade React frameworks {/*production-grade-react-frameworks*/}
+## React frameworks ברמת פרודקשן {/*production-grade-react-frameworks*/}
-These frameworks support all the features you need to deploy and scale your app in production and are working towards supporting our [full-stack architecture vision](#which-features-make-up-the-react-teams-full-stack-architecture-vision). All of the frameworks we recommend are open source with active communities for support, and can be deployed to your own server or a hosting provider. If you’re a framework author interested in being included on this list, [please let us know](https://github.com/reactjs/react.dev/issues/new?assignees=&labels=type%3A+framework&projects=&template=3-framework.yml&title=%5BFramework%5D%3A+).
+ה-frameworks האלה תומכים בכל היכולות שצריך לפרוס ולהגדיל אפליקציה בפרודקשן, ופועלים לקראת תמיכה ב-[חזון ארכיטקטורת ה-full-stack שלנו](#which-features-make-up-the-react-teams-full-stack-architecture-vision). כל ה-frameworks הם ממליצים אותם הם קוד פתוח עם פעילות קהילות לתמיכה, אוניות לפריסה על השרת שלכם או אצל ספק אירוח. אם אתם מחברי framework ורוצים להיכלל ברשימה הזו, [ספרו לנו](https://github.com/reactjs/react.dev/issues/new?assignees=&labels=type%3A+framework&projects=&template=3-framework.yml&title=%5BFramework%5D%3A+).
### Next.js {/*nextjs-pages-router*/}
-**[Next.js' Pages Router](https://nextjs.org/) is a full-stack React framework.** It's versatile and lets you create React apps of any size--from a mostly static blog to a complex dynamic application. To create a new Next.js project, run in your terminal:
+**[נתב דפי Next.js](https://nextjs.org/) הוא React framework מלא.** הוא גמיש ומאפשר לבנות אפליקציות React בכל גודל, מבלוג סטטי ברובו ועד אפליקציה דינמית מורכבת. כדי ליצור פרויקט Next.js חדש, הריצו בטרמינל:
<TerminalBlock>
npx create-next-app@latest
</TerminalBlock>
-If you're new to Next.js, check out the [learn Next.js course.](https://nextjs.org/learn)
+אם אתם חדשים ב-Next.js, מומלץ לעבור על [קורס הלימוד של Next.js.](https://nextjs.org/learn)
-Next.js is maintained by [Vercel](https://vercel.com/). You can [deploy a Next.js app](https://nextjs.org/docs/app/building-your-application/deploying) to any Node.js or serverless hosting, or to your own server. Next.js also supports a [static export](https://nextjs.org/docs/pages/building-your-application/deploying/static-exports) which doesn't require a server.
+Next.js מתוחזק על ידי [Vercel](https://vercel.com/). אפשר [לפרוס אפליקציית Next.js](https://nextjs.org/docs/app/building-your-application/deploying) לכל אירוח Node.js או serverless, או לשרת משלכם. Next.js תומך גם ב-[ייצוא סטטי](https://nextjs.org/docs/pages/building-your-application/deploying/static-exports) שלא דורש שרת.
-### Remix {/*remix*/}
+### רמיקס {/*רמיקס*/}
-**[Remix](https://remix.run/) is a full-stack React framework with nested routing.** It lets you break your app into nested parts that can load data in parallel and refresh in response to the user actions. To create a new Remix project, run:
+**[Remix](https://remix.run/) הוא React framework מלא עם ניתוב מקונן.** הוא יכול לפרק את האפליקציה לחלקים מקוננים לטעון נתונים גובה תגובה ולהתרענן בת לפעולות משתמש. כדי ליצור פרויקט Remix חדש, הריצו:
<TerminalBlock>
-npx create-remix
+npx ליצור-רמיקס
</TerminalBlock>
-If you're new to Remix, check out the Remix [blog tutorial](https://remix.run/docs/en/main/tutorials/blog) (short) and [app tutorial](https://remix.run/docs/en/main/tutorials/jokes) (long).
+אם אתם חדשים ב-Remix, מומלץ לעבור על מדריך ה-[blog](https://remix.run/docs/en/main/tutorials/blog) (קצר) ועל מדריך ה-[app](https://remix.run/docs/en/main/tutorials/jokes) (ארוך).
-Remix is maintained by [Shopify](https://www.shopify.com/). When you create a Remix project, you need to [pick your deployment target](https://remix.run/docs/en/main/guides/deployment). You can deploy a Remix app to any Node.js or serverless hosting by using or writing an [adapter](https://remix.run/docs/en/main/other-api/adapter).
+רמיקס מתוחזק על ידי [Shopify](https://www.shopify.com/). כשיוצרים פרויקט Remix צריך [לבחור יעד פריסה](https://remix.run/docs/en/main/guides/deployment). אפשר לפרוס אפליקציית Remix לכל אירוח Node.js או serverless באמצעות [adapter](https://remix.run/docs/en/main/other-api/adapter) קיים או כזה שתכתבו בעצמכם.
-### Gatsby {/*gatsby*/}
+### גטסבי {/*גטסבי*/}
-**[Gatsby](https://www.gatsbyjs.com/) is a React framework for fast CMS-backed websites.** Its rich plugin ecosystem and its GraphQL data layer simplify integrating content, APIs, and services into one website. To create a new Gatsby project, run:
+**[Gatsby](https://www.gatsbyjs.com/) הוא React framework לאתרים מהירים שמבוססי CMS.** אקו-סיסטם התוספים העשיר ושכבת מבוסס GraphQL שלו מפשטים שילוב תוכן, APIs ושירותים שונים לאתר. כדי ליצור פרויקט Gatsby חדש, הריצו:
<TerminalBlock>
npx create-gatsby
</TerminalBlock>
-If you're new to Gatsby, check out the [Gatsby tutorial.](https://www.gatsbyjs.com/docs/tutorial/)
+אם אתם חדשים ב-Gatsby, בדקו את [מדריך גטסבי.](https://www.gatsbyjs.com/docs/tutorial/)
-Gatsby is maintained by [Netlify](https://www.netlify.com/). You can [deploy a fully static Gatsby site](https://www.gatsbyjs.com/docs/how-to/previews-deploys-hosting) to any static hosting. If you opt into using server-only features, make sure your hosting provider supports them for Gatsby.
+גטסבי מתוחזק על ידי [Netlify](https://www.netlify.com/). אפשר [לפרוס אתר Gatsby סטטי לחלוטין](https://www.gatsbyjs.com/docs/how-to/previews-deploys-hosting) לכל אירוח סטטי. אם אתם משתמשים ביכולות שמוגבלות לשרת, ודאו שספק תומך עבור גטסבי.
-### Expo (for native apps) {/*expo*/}
+### Expo (לאפליקציות native) {/*expo*/}
-**[Expo](https://expo.dev/) is a React framework that lets you create universal Android, iOS, and web apps with truly native UIs.** It provides an SDK for [React Native](https://reactnative.dev/) that makes the native parts easier to use. To create a new Expo project, run:
+**[Expo](https://expo.dev/) הוא React framework שמאפשר ליצור אפליקציות אוניברסליות ל-Android, iOS והווב עם ממשק משתמש מקורי אמיתי.** הוא מספק SDK עבור [React Native](https://reactnative.dev/) שמקל שימוש בחלקים ה-native. כדי ליצור פרויקט Expo חדש, הריצו:
<TerminalBlock>
npx create-expo-app
</TerminalBlock>
-If you're new to Expo, check out the [Expo tutorial](https://docs.expo.dev/tutorial/introduction/).
+אם אתם חדשים ב-Expo, בדקו את [מדריך Expo](https://docs.expo.dev/tutorial/introduction/).
-Expo is maintained by [Expo (the company)](https://expo.dev/about). Building apps with Expo is free, and you can submit them to the Google and Apple app stores without restrictions. Expo additionally provides opt-in paid cloud services.
+Expo מתוחזק על ידי [Expo (החברה)](https://expo.dev/about). בניית אפליקציות עם Expo היא ללא עלות, ואפשר לשלוח אותן לחנויות האפליקציות של Google ו-Apple ללא מגבלות. Expo מספקת גם שירותי ענן בתשלום כאפשרות להצטרף.
-## Bleeding-edge React frameworks {/*bleeding-edge-react-frameworks*/}
+## React frameworks בחזית הטכנולוגיה {/*bleeding-edge-react-frameworks*/}
-As we've explored how to continue improving React, we realized that integrating React more closely with frameworks (specifically, with routing, bundling, and server technologies) is our biggest opportunity to help React users build better apps. The Next.js team has agreed to collaborate with us in researching, developing, integrating, and testing framework-agnostic bleeding-edge React features like [React Server Components.](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components)
+כשהמשכנו לבחון איך לשפר את React, ההזדמנות שלנו להשפעה הגדולה ביותר היא אינטגרציה הדוקה יותר בין React ל-frameworks, במיוחד בניתוב, חיבור וטכנולוגיות שרת. צוות Next.js הסכים משתפים איתנו פעולה במחקר, פיתוח, אינטגרציה ובדיקות של יכולות React מתקדמות שאינן תלויות framework, כמו [React Server Components.](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023-component-server)
-These features are getting closer to being production-ready every day, and we've been in talks with other bundler and framework developers about integrating them. Our hope is that in a year or two, all frameworks listed on this page will have full support for these features. (If you're a framework author interested in partnering with us to experiment with these features, please let us know!)
+היכולות האלו מתקרבות כל יום למוכנות לפרודקשן, ואנחנו בשיחות גם עם מפתחי bundlers ו-frameworks נוספים כדי לשלב אותם. התקווה היא שלנו שבתוך שנה או שנתיים כל ה-frameworks שמופיעים בעמוד הזה יתמכו בצורה מלאה. (אם אתם מחברי מסגרת וסיוע איתנו פעולות בניסויים האלה, ספרו לנו.)
-### Next.js (App Router) {/*nextjs-app-router*/}
+### Next.js (נתב אפליקציות) {/*nextjs-app-router*/}
-**[Next.js's App Router](https://nextjs.org/docs) is a redesign of the Next.js APIs aiming to fulfill the React team’s full-stack architecture vision.** It lets you fetch data in asynchronous components that run on the server or even during the build.
+**[נתב האפליקציות של Next.js](https://nextjs.org/docs) הוא עיצוב מחדש של ממשקי API ב-Next.js שמטרתו לממש את חזון ארכיטקטורת ה-full-stack של צוות React.** הוא יכול לשלוט בנתונים בקומפוננטות אסינרוניות שרצות בשרת או אפילו בזמן לבנות.
-Next.js is maintained by [Vercel](https://vercel.com/). You can [deploy a Next.js app](https://nextjs.org/docs/app/building-your-application/deploying) to any Node.js or serverless hosting, or to your own server. Next.js also supports [static export](https://nextjs.org/docs/app/building-your-application/deploying/static-exports) which doesn't require a server.
+Next.js מתוחזק על ידי [Vercel](https://vercel.com/). אפשר [לפרוס אפליקציית Next.js](https://nextjs.org/docs/app/building-your-application/deploying) לכל אירוח Node.js או serverless, או לשרת משלכם. Next.js תומך גם ב-[ייצוא סטטי](https://nextjs.org/docs/app/building-your-application/deploying/static-exports) שלא דורש שרת.
<DeepDive>
-#### Which features make up the React team’s full-stack architecture vision? {/*which-features-make-up-the-react-teams-full-stack-architecture-vision*/}
+#### אולי ירצו את חזון ארכיטקטורת ה-full-stack של צוות להגיב? {/*אשר-התכונות-מרכיבות-ה-react-teams-full-stack-architecture-vision*/}
-Next.js's App Router bundler fully implements the official [React Server Components specification](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md). This lets you mix build-time, server-only, and interactive components in a single React tree.
+ה-bundler של Next.js App Router ממש ממש מלא את [מפרט React Server Components הרשמי](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md). זה יכול לשלב בעץ תגובה אחת קומפוננטות של זמן לבנות, קומפוננטות שרת בלבד וקומפוננטות אינטראקטיביות.
-For example, you can write a server-only React component as an `async` function that reads from a database or from a file. Then you can pass data down from it to your interactive components:
+לדוגמה, אפשר לכתוב קומפוננטת תגובה בצד שרת כפונקציית `async` שקוראת ממסד נתונים או מקובץ. אחר כך אפשר להעביר דרך נתונים לקומפוננטות אינטראקטיביות:
```js
// This component runs *only* on the server (or during the build).
@@ -117,7 +117,7 @@ async function Talks({ confId }) {
}
```
-Next.js's App Router also integrates [data fetching with Suspense](/blog/2022/03/29/react-v18#suspense-in-data-frameworks). This lets you specify a loading state (like a skeleton placeholder) for different parts of your user interface directly in your React tree:
+Next.js App Router משלב גם [משיפי נתונים עם מתח](/blog/2022/03/29/react-v18#suspense-in-data-frameworks). כך אפשר להגדיר מצב טעינה (כמו מציין מיקום שלד) עבור חלקים שונים ב-UI מבוסס בעץ תגובה:
```js
<Suspense fallback={<TalksLoading />}>
@@ -125,6 +125,6 @@ Next.js's App Router also integrates [data fetching with Suspense](/blog/2022/03
</Suspense>
```
-Server Components and Suspense are React features rather than Next.js features. However, adopting them at the framework level requires buy-in and non-trivial implementation work. At the moment, the Next.js App Router is the most complete implementation. The React team is working with bundler developers to make these features easier to implement in the next generation of frameworks.
+רכיבי שרת ו-Suspense יכולים להיות של React ולא של Next.js. עם זאת, אימוץ שלהן ברמת המסגרת דורשת מחויבות ועבודת מימוש לא טריאלית. כרגע Next.js App Router הוא המימוש השלם ביותר. צוות תגיב עובד עם מפתחי bundlers כדי להקל על מימוש היכולות האלה בדור הבא של מסגרות.
</DeepDive>
diff --git a/src/content/learn/state-a-components-memory.md b/src/content/learn/state-a-components-memory.md
index 75a1fd0b9..32a2dd402 100644
--- a/src/content/learn/state-a-components-memory.md
+++ b/src/content/learn/state-a-components-memory.md
@@ -1,25 +1,25 @@
---
-title: "State: A Component's Memory"
+title: "state: הזיכרון של קומפוננטה"
---
<Intro>
-Components often need to change what's on the screen as a result of an interaction. Typing into the form should update the input field, clicking "next" on an image carousel should change which image is displayed, clicking "buy" should put a product in the shopping cart. Components need to "remember" things: the current input value, the current image, the shopping cart. In React, this kind of component-specific memory is called *state*.
+רכיבים צריכים לעתים קרובות לשנות את מה שמופיע על המסך כתוצאה מאינטראקציה. הקלדה בטופס אמורה לעדכן את שדה הקלט, לחיצה על "הבא" בקרוסלת תמונה אמורה לשנות איזו תמונה מוצגת, לחיצה על "קנה" אמורה להכניס מוצר לעגלת הקניות. רכיבים צריכים "לזכור" דברים: ערך הקלט הנוכחי, התמונה הנוכחית, עגלת הקניות. ב-React, סוג זה של זיכרון ספציפי לרכיב נקרא *מצב*.
</Intro>
<YouWillLearn>
-* How to add a state variable with the [`useState`](/reference/react/useState) Hook
-* What pair of values the `useState` Hook returns
-* How to add more than one state variable
-* Why state is called local
+* כיצד להוסיף משתנה מצב עם ה- [`useState`](/reference/react/useState)
+* איזה צמד ערכים ה-'useState' מחזיר
+* כיצד להוסיף יותר ממשתנה מצב אחד
+* מדוע state נקראת מקומית
</YouWillLearn>
-## When a regular variable isn’t enough {/*when-a-regular-variable-isnt-enough*/}
+## כאשר משתנה רגיל אינו מספיק {/*when-a-regular-variable-isnt-enough*/}
-Here's a component that renders a sculpture image. Clicking the "Next" button should show the next sculpture by changing the `index` to `1`, then `2`, and so on. However, this **won't work** (you can try it!):
+הנה רכיב שמציג תמונה של פיסול. לחיצה על כפתור "הבא" אמורה להציג את הפסל הבא על ידי שינוי ה'אינדקס' ל'1', ואז '2', וכן הלאה. עם זאת, זה **לא יעבוד** (תוכל לנסות את זה!):
<Sandpack>
@@ -151,46 +151,46 @@ button {
</Sandpack>
-The `handleClick` event handler is updating a local variable, `index`. But two things prevent that change from being visible:
+המטפל באירוע `handleClick` מעדכן משתנה מקומי, `index`. אבל שני דברים מונעים מהשינוי הזה להיות גלוי:
-1. **Local variables don't persist between renders.** When React renders this component a second time, it renders it from scratch—it doesn't consider any changes to the local variables.
-2. **Changes to local variables won't trigger renders.** React doesn't realize it needs to render the component again with the new data.
+1. **משתנים מקומיים לא נמשכים בין רינדור.** כאשר React מעבד את הרכיב הזה פעם שנייה, הוא מעבד אותו מאפס - הוא לא מתחשב בשינויים במשתנים המקומיים.
+2. **שינויים במשתנים מקומיים לא יפעילו עיבודים.** React לא מבין שהיא צריכה לעבד את הרכיב שוב עם הנתונים החדשים.
-To update a component with new data, two things need to happen:
+כדי לעדכן רכיב בנתונים חדשים, צריכים לקרות שני דברים:
-1. **Retain** the data between renders.
-2. **Trigger** React to render the component with new data (re-rendering).
+1. **שמור** את הנתונים בין העיבודים.
+2. **טריגר** הגיבו לעיבוד הרכיב עם נתונים חדשים (עיבוד מחדש).
-The [`useState`](/reference/react/useState) Hook provides those two things:
+ה- [`useState`](/reference/react/useState) Hook מספק את שני הדברים האלה:
-1. A **state variable** to retain the data between renders.
-2. A **state setter function** to update the variable and trigger React to render the component again.
+1. **משתנה מצב** לשמירה על הנתונים בין העיבודים.
+2. **פונקציה קובעת מצב** לעדכון המשתנה ולהפעיל את React כדי לעבד שוב את הרכיב.
-## Adding a state variable {/*adding-a-state-variable*/}
+## הוספת משתנה מצב {/*הוספת-מצב-משתנה*/}
-To add a state variable, import `useState` from React at the top of the file:
+כדי להוסיף משתנה מצב, ייבא 'useState' מ-React בחלק העליון של הקובץ:
```js
import { useState } from 'react';
```
-Then, replace this line:
+לאחר מכן, החלף את השורה הזו:
```js
let index = 0;
```
-with
+עִם
```js
const [index, setIndex] = useState(0);
```
-`index` is a state variable and `setIndex` is the setter function.
+`index` הוא משתנה מצב ו-`setIndex` הוא פונקציית הקובע.
-> The `[` and `]` syntax here is called [array destructuring](https://javascript.info/destructuring-assignment) and it lets you read values from an array. The array returned by `useState` always has exactly two items.
+> התחביר `[` ו`]` כאן נקרא [destructuring array](https://javascript.info/destructuring-assignment) והוא מאפשר לקרוא ערכים ממערך. למערך המוחזר על ידי 'useState' יש תמיד בדיוק שני פריטים.
-This is how they work together in `handleClick`:
+כך הם עובדים יחד ב`handleClick`:
```js
function handleClick() {
@@ -198,7 +198,7 @@ function handleClick() {
}
```
-Now clicking the "Next" button switches the current sculpture:
+כעת לחיצה על כפתור "הבא" משנה את הפסל הנוכחי:
<Sandpack>
@@ -331,57 +331,57 @@ button {
</Sandpack>
-### Meet your first Hook {/*meet-your-first-hook*/}
+### פגוש את ה-Hook הראשון שלך {/*meet-your-first-hook*/}
-In React, `useState`, as well as any other function starting with "`use`", is called a Hook.
+ב-React, `useState`, כמו גם כל פונקציה אחרת שמתחילה ב-``use`", נקראת Hook.
-*Hooks* are special functions that are only available while React is [rendering](/learn/render-and-commit#step-1-trigger-a-render) (which we'll get into in more detail on the next page). They let you "hook into" different React features.
+*Hooks* הם פונקציות מיוחדות שזמינות רק בזמן ש-React הוא [rendering](/learn/render-and-commit#step-1-trigger-a-render) (עליהן ניכנס ביתר פירוט בעמוד הבא). הם מאפשרים לך "להתחבר" לתכונות שונות של React.
-State is just one of those features, but you will meet the other Hooks later.
+הstate היא רק אחת מהתכונות הללו, אבל תפגוש את הHooks האחרים מאוחר יותר.
<Pitfall>
-**Hooks—functions starting with `use`—can only be called at the top level of your components or [your own Hooks.](/learn/reusing-logic-with-custom-hooks)** You can't call Hooks inside conditions, loops, or other nested functions. Hooks are functions, but it's helpful to think of them as unconditional declarations about your component's needs. You "use" React features at the top of your component similar to how you "import" modules at the top of your file.
+**Hooks — פונקציות שמתחילות ב-'use' — ניתן לקרוא רק ברמה העליונה של הרכיבים שלך או [Hooks משלך.](/learn/reusing-logic-with-custom-hooks)** אתה לא יכול לקרוא ל-Hooks בתוך תנאים, לולאות או פונקציות מקוננות אחרות. ווים הם פונקציות, אבל כדאי לחשוב עליהם כעל הצהרות ללא תנאי לגבי הצרכים של הרכיב שלך. אתה "משתמש" בתכונות React בחלק העליון של הרכיב שלך בדומה לאופן שבו אתה "מייבא" מודולים בחלק העליון של הקובץ שלך.
</Pitfall>
### Anatomy of `useState` {/*anatomy-of-usestate*/}
-When you call [`useState`](/reference/react/useState), you are telling React that you want this component to remember something:
+כשאתה קורא ל-[`useState`](/reference/react/useState), אתה אומר ל-React שאתה רוצה שהרכיב הזה יזכור משהו:
```js
const [index, setIndex] = useState(0);
```
-In this case, you want React to remember `index`.
+במקרה זה, אתה רוצה ש-React תזכור את 'אינדקס'.
<Note>
-The convention is to name this pair like `const [something, setSomething]`. You could name it anything you like, but conventions make things easier to understand across projects.
+המוסכמה היא לתת שם לזוג הזה כמו `const [משהו, setSomething]`. אתה יכול לקרוא לזה כל מה שאתה אוהב, אבל מוסכמות מקלות על ההבנה של דברים בין פרויקטים.
</Note>
-The only argument to `useState` is the **initial value** of your state variable. In this example, the `index`'s initial value is set to `0` with `useState(0)`.
+הארגומנט היחיד ל-'useState' הוא **הערך ההתחלתי** של משתנה הstate שלך. בדוגמה זו, הערך ההתחלתי של `אינדקס` מוגדר ל-`0` עם `useState(0)`.
-Every time your component renders, `useState` gives you an array containing two values:
+בכל פעם שהרכיב שלך מעבד, 'useState' נותן לך מערך המכיל שני ערכים:
-1. The **state variable** (`index`) with the value you stored.
-2. The **state setter function** (`setIndex`) which can update the state variable and trigger React to render the component again.
+1. **משתנה הstate** (`אינדקס`) עם הערך ששמרת.
+2. פונקציית **מצב קובע** (`setIndex`) שיכולה לעדכן את משתנה הstate ולהפעיל את React לעיבוד הרכיב שוב.
-Here's how that happens in action:
+הנה איך זה קורה בפעולה:
```js
const [index, setIndex] = useState(0);
```
-1. **Your component renders the first time.** Because you passed `0` to `useState` as the initial value for `index`, it will return `[0, setIndex]`. React remembers `0` is the latest state value.
-2. **You update the state.** When a user clicks the button, it calls `setIndex(index + 1)`. `index` is `0`, so it's `setIndex(1)`. This tells React to remember `index` is `1` now and triggers another render.
-3. **Your component's second render.** React still sees `useState(0)`, but because React *remembers* that you set `index` to `1`, it returns `[1, setIndex]` instead.
-4. And so on!
+1. **הרכיב שלך מעבד בפעם הראשונה.** מכיוון שהעברת '0' ל'useState' כערך ההתחלתי של 'index', הוא יחזיר את '[0, setIndex]'. React זוכר ש'0' הוא ערך הstate האחרון.
+2. **אתה מעדכן את הstate.** כאשר משתמש לוחץ על הכפתור, הוא קורא `setIndex(index + 1)`. `index` הוא `0`, אז זה `setIndex(1)`. זה אומר ל-React לזכור ש'אינדקס' הוא '1' עכשיו ומפעיל רינדור נוסף.
+3. **הרינדור השני של הרכיב שלך.** React עדיין רואה את `useState(0)`, אך מכיוון ש-React *זוכר* שהגדרת `אינדקס` ל-`1`, הוא מחזיר במקום `[1, setIndex]`.
+4. וכן הלאה!
-## Giving a component multiple state variables {/*giving-a-component-multiple-state-variables*/}
+## מתן משתני מצב מרובים לרכיב {/*מתן-רכיב-משתני-מצב-מרובים*/}
-You can have as many state variables of as many types as you like in one component. This component has two state variables, a number `index` and a boolean `showMore` that's toggled when you click "Show details":
+אתה יכול לקבל כמה משתני מצב של כמה סוגים שאתה רוצה ברכיב אחד. לרכיב זה יש שני משתני מצב, 'אינדקס' מספר ו-'showMore' בוליאני שמופעל כאשר אתה לוחץ על "הצג פרטים":
<Sandpack>
@@ -520,19 +520,19 @@ button {
</Sandpack>
-It is a good idea to have multiple state variables if their state is unrelated, like `index` and `showMore` in this example. But if you find that you often change two state variables together, it might be easier to combine them into one. For example, if you have a form with many fields, it's more convenient to have a single state variable that holds an object than state variable per field. Read [Choosing the State Structure](/learn/choosing-the-state-structure) for more tips.
+זה רעיון טוב שיהיו משתני מצב מרובים אם הstate שלהם אינו קשור, כמו 'אינדקס' ו-'showMore' בדוגמה זו. אבל אם אתה מגלה שלעתים קרובות אתה משנה שני משתני מצב ביחד, אולי יהיה קל יותר לשלב אותם לאחד. לדוגמה, אם יש לך טופס עם שדות רבים, נוח יותר לקבל משתנה מצב יחיד שמכיל אובייקט מאשר משתנה מצב לכל שדה. קרא את [Choosing the State Structure](/learn/choosing-the-state-structure) לקבלת טיפים נוספים.
<DeepDive>
-#### How does React know which state to return? {/*how-does-react-know-which-state-to-return*/}
+#### איך React יודע לאיזה מצב לחזור? {/*איך-מגיב-יודע-איזה-state-להחזיר*/}
-You might have noticed that the `useState` call does not receive any information about *which* state variable it refers to. There is no "identifier" that is passed to `useState`, so how does it know which of the state variables to return? Does it rely on some magic like parsing your functions? The answer is no.
+אולי שמתם לב שהקריאה 'useState' לא מקבלת שום מידע לגבי *איזה* משתנה מצב היא מתייחסת. אין "מזהה" שמועבר ל`useState`, אז איך הוא יודע איזה ממשתני הstate להחזיר? האם זה מסתמך על קסם כמו ניתוח הפונקציות שלך? התשובה היא לא.
-Instead, to enable their concise syntax, Hooks **rely on a stable call order on every render of the same component.** This works well in practice because if you follow the rule above ("only call Hooks at the top level"), Hooks will always be called in the same order. Additionally, a [linter plugin](https://www.npmjs.com/package/eslint-plugin-react-hooks) catches most mistakes.
+במקום זאת, כדי לאפשר את התחביר התמציתי שלהם, Hooks **מסתמכים על סדר קריאה יציב על כל עיבוד של אותו רכיב.** זה עובד היטב בפועל מכיוון שאם תפעלו לפי הכלל שלמעלה ("התקשרו רק ל-Hooks ברמה העליונה"), Hooks תמיד ייקרא באותו סדר. בנוסף, [פלאגין linter](https://www.npmjs.com/package/eslint-plugin-react-hooks) תופס את רוב הטעויות.
-Internally, React holds an array of state pairs for every component. It also maintains the current pair index, which is set to `0` before rendering. Each time you call `useState`, React gives you the next state pair and increments the index. You can read more about this mechanism in [React Hooks: Not Magic, Just Arrays.](https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e)
+באופן פנימי, React מחזיקה מערך של זוגות מצבים עבור כל רכיב. זה גם שומר על אינדקס הזוגות הנוכחי, שמוגדר ל-'0' לפני העיבוד. בכל פעם שאתה קורא 'useState', React נותן לך את צמד הstates הבא ומגדיל את האינדקס. תוכל לקרוא עוד על המנגנון הזה ב-[React Hooks: Not Magic, Just Arrays.](https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e)
-This example **doesn't use React** but it gives you an idea of how `useState` works internally:
+הדוגמה הזו **לא משתמשת ב-React** אבל היא נותנת לך מושג איך 'useState' עובד באופן פנימי:
<Sandpack>
@@ -724,15 +724,15 @@ button { display: block; margin-bottom: 10px; }
</Sandpack>
-You don't have to understand it to use React, but you might find this a helpful mental model.
+אתה לא צריך להבין את זה כדי להשתמש ב-React, אבל אתה עשוי למצוא את זה מודל נפשי מועיל.
</DeepDive>
-## State is isolated and private {/*state-is-isolated-and-private*/}
+## הstate מבודדת ופרטית {/*state-מבודדת-ופרטית*/}
-State is local to a component instance on the screen. In other words, **if you render the same component twice, each copy will have completely isolated state!** Changing one of them will not affect the other.
+הstate הוא מקומי למופע רכיב על המסך. במילים אחרות, **אם תעבדו את אותו רכיב פעמיים, לכל עותק יהיה מצב מבודד לחלוטין!** שינוי אחד מהם לא ישפיע על השני.
-In this example, the `Gallery` component from earlier is rendered twice with no changes to its logic. Try clicking the buttons inside each of the galleries. Notice that their state is independent:
+בדוגמה זו, הרכיב 'גלריה' ממקודם מוצג פעמיים ללא שינויים בלוגיקה שלו. נסה ללחוץ על הכפתורים בתוך כל אחת מהגלריות. שימו לב שstate שלהם עצמאית:
<Sandpack>
@@ -891,21 +891,21 @@ button {
</Sandpack>
-This is what makes state different from regular variables that you might declare at the top of your module. State is not tied to a particular function call or a place in the code, but it's "local" to the specific place on the screen. You rendered two `<Gallery />` components, so their state is stored separately.
+זה מה שעושה מצב שונה ממשתנים רגילים שאתה עשוי להצהיר בראש המודול שלך. הstate לא קשורה לקריאת פונקציה מסוימת או למקום בקוד, אלא היא "מקומית" למקום הספציפי על המסך. הצגת שני רכיבי `<Gallery />`, כך שstate שלהם מאוחסן בנפרד.
-Also notice how the `Page` component doesn't "know" anything about the `Gallery` state or even whether it has any. Unlike props, **state is fully private to the component declaring it.** The parent component can't change it. This lets you add state to any component or remove it without impacting the rest of the components.
+שימו לב גם כיצד רכיב ה'דף' אינו "יודע" דבר על מצב ה'גלריה' או אפילו אם יש לו כזה. בניגוד לprops, **מצב פרטי לחלוטין לרכיב המצהיר עליו.** רכיב האב לא יכול לשנות אותו. זה מאפשר לך להוסיף מצב לכל רכיב או להסיר אותו מבלי להשפיע על שאר הרכיבים.
-What if you wanted both galleries to keep their states in sync? The right way to do it in React is to *remove* state from child components and add it to their closest shared parent. The next few pages will focus on organizing state of a single component, but we will return to this topic in [Sharing State Between Components.](/learn/sharing-state-between-components)
+מה אם היית רוצה ששתי הגלריות ישמרו על הstates שלהן מסונכרנים? הדרך הנכונה לעשות זאת ב-React היא *להסיר* מצב מרכיבי ילד ולהוסיף אותו להורה המשותף הקרוב ביותר שלהם. העמודים הבאים יתמקדו בארגון מצב של רכיב בודד, אך נחזור לנושא זה ב-[Sharing State Between Components.](/learn/sharing-state-between-components)
<Recap>
-* Use a state variable when a component needs to "remember" some information between renders.
-* State variables are declared by calling the `useState` Hook.
-* Hooks are special functions that start with `use`. They let you "hook into" React features like state.
-* Hooks might remind you of imports: they need to be called unconditionally. Calling Hooks, including `useState`, is only valid at the top level of a component or another Hook.
-* The `useState` Hook returns a pair of values: the current state and the function to update it.
-* You can have more than one state variable. Internally, React matches them up by their order.
-* State is private to the component. If you render it in two places, each copy gets its own state.
+* השתמש במשתנה מצב כאשר רכיב צריך "לזכור" מידע מסוים בין עיבודים.
+* משתני מצב מוכרזים על ידי קריאה ל-`useState` Hook.
+* ווים הם פונקציות מיוחדות שמתחילות ב'שימוש'. הם מאפשרים לך "להתחבר" לתכונות של React כמו מצב.
+* הHooks עשויים להזכיר לך יבוא: צריך לקרוא להם ללא תנאי. Calling Hooks, כולל 'useState', תקף רק ברמה העליונה של רכיב או Hook אחר.
+* ה-`useState` Hook מחזיר זוג ערכים: הstate הנוכחי והפונקציה לעדכן אותו.
+* אתה יכול לקבל יותר ממשתנה מצב אחד. באופן פנימי, React מתאים אותם לפי ההזמנה שלהם.
+* הstate היא פרטית לרכיב. אם תעבדו אותו בשני מקומות, כל עותק יקבל מצב משלו.
</Recap>
@@ -913,11 +913,11 @@ What if you wanted both galleries to keep their states in sync? The right way to
<Challenges>
-#### Complete the gallery {/*complete-the-gallery*/}
+#### השלם את הגלריה {/*השלם-הגלריה*/}
-When you press "Next" on the last sculpture, the code crashes. Fix the logic to prevent the crash. You may do this by adding extra logic to event handler or by disabling the button when the action is not possible.
+כאשר אתה לוחץ על "הבא" על הפסל האחרון, הקוד קורס. תקן את ההיגיון כדי למנוע את ההתרסקות. אתה יכול לעשות זאת על ידי הוספת היגיון נוסף למטפל באירועים או על ידי השבתת הכפתור כאשר הפעולה אינה אפשרית.
-After fixing the crash, add a "Previous" button that shows the previous sculpture. It shouldn't crash on the first sculpture.
+לאחר תיקון ההתרסקות, הוסף כפתור "קודם" המציג את הפסל הקודם. זה לא אמור להתרסק על הפסל הראשון.
<Sandpack>
@@ -1059,7 +1059,7 @@ img { width: 120px; height: 120px; }
<Solution>
-This adds a guarding condition inside both event handlers and disables the buttons when needed:
+זה מוסיף מצב שמירה בשני מטפלי האירועים ומשבית את הכפתורים בעת הצורך:
<Sandpack>
@@ -1219,13 +1219,13 @@ img { width: 120px; height: 120px; }
</Sandpack>
-Notice how `hasPrev` and `hasNext` are used *both* for the returned JSX and inside the event handlers! This handy pattern works because event handler functions ["close over"](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures) any variables declared while rendering.
+שימו לב איך `hasPrev` ו-`hasNext` משמשים *גם* עבור ה-JSX המוחזר וגם בתוך מטפלי האירועים! הדפוס השימושי הזה עובד מכיוון שמטפל באירועים מתפקד ["סגור מעל"](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures) כל משתנים שהוכרזו בזמן העיבוד.
</Solution>
-#### Fix stuck form inputs {/*fix-stuck-form-inputs*/}
+#### תקן כניסות טפסים תקועים {/*fix-stuck-form-inputs*/}
-When you type into the input fields, nothing appears. It's like the input values are "stuck" with empty strings. The `value` of the first `<input>` is set to always match the `firstName` variable, and the `value` for the second `<input>` is set to always match the `lastName` variable. This is correct. Both inputs have `onChange` event handlers, which try to update the variables based on the latest user input (`e.target.value`). However, the variables don't seem to "remember" their values between re-renders. Fix this by using state variables instead.
+כאשר אתה מקליד בשדות הקלט, שום דבר לא מופיע. זה כאילו ערכי הקלט "תקועים" עם מחרוזות ריקות. ה-'value' של ה-`<input>` הראשון מוגדר כך שיתאים תמיד למשתנה 'firstName', וה-'value' עבור ה-`<input>` השני מוגדר כך שיתאים תמיד למשתנה 'lastName'. זה נכון. לשני הקלטים יש מטפלי אירועים 'onChange', שמנסים לעדכן את המשתנים על סמך הקלט האחרון של המשתמש ('e.target.value'). עם זאת, נראה שהמשתנים לא "זוכרים" את הערכים שלהם בין עיבוד מחדש. תקן זאת על ידי שימוש במשתני מצב במקום זאת.
<Sandpack>
@@ -1274,7 +1274,7 @@ h1 { margin-top: 10px; }
<Solution>
-First, import `useState` from React. Then replace `firstName` and `lastName` with state variables declared by calling `useState`. Finally, replace every `firstName = ...` assignment with `setFirstName(...)`, and do the same for `lastName`. Don't forget to update `handleReset` too so that the reset button works.
+ראשית, ייבא 'useState' מ-React. לאחר מכן החלף את `firstName` ו`lastName` במשתני מצב שהוכרזו על ידי קריאה ל-`useState`. לבסוף, החלף כל הקצאת `firstName = ...` ב-`setFirstName(...)`, ועשה את אותו הדבר עבור `lastName`. אל תשכח לעדכן גם את `handleReset` כדי שכפתור האיפוס יפעל.
<Sandpack>
@@ -1325,13 +1325,13 @@ h1 { margin-top: 10px; }
</Solution>
-#### Fix a crash {/*fix-a-crash*/}
+#### תיקון קריסה {/*תיקון-התרסקות*/}
-Here is a small form that is supposed to let the user leave some feedback. When the feedback is submitted, it's supposed to display a thank-you message. However, it crashes with an error message saying "Rendered fewer hooks than expected". Can you spot the mistake and fix it?
+הנה טופס קטן שאמור לאפשר למשתמש להשאיר קצת משוב. כאשר המשוב נשלח, הוא אמור להציג הודעת תודה. עם זאת, הוא קורס עם הודעת שגיאה האומרת "נתן פחות ווים מהצפוי". האם תוכל לזהות את הטעות ולתקן אותה?
<Hint>
-Are there any limitations on _where_ Hooks may be called? Does this component break any rules? Check if there are any comments disabling the linter checks--this is where the bugs often hide!
+האם יש מגבלות על _היכן_ ניתן לקרוא לHooks? האם הרכיב הזה מפר כללים? בדוק אם יש הערות כלשהן שמבטלות את בדיקות ה-linter--זה המקום שבו הבאגים מתחבאים לעתים קרובות!
</Hint>
@@ -1370,9 +1370,9 @@ export default function FeedbackForm() {
<Solution>
-Hooks can only be called at the top level of the component function. Here, the first `isSent` definition follows this rule, but the `message` definition is nested in a condition.
+ניתן לקרוא לHooks רק ברמה העליונה של פונקציית הרכיב. כאן, ההגדרה 'isSent' הראשונה עוקבת אחר הכלל הזה, אבל ההגדרה 'הודעה' מקוננת בתנאי.
-Move it out of the condition to fix the issue:
+הזז אותו מstate כדי לתקן את הבעיה:
<Sandpack>
@@ -1407,9 +1407,9 @@ export default function FeedbackForm() {
</Sandpack>
-Remember, Hooks must be called unconditionally and always in the same order!
+זכור, הHooks חייב להיקרא ללא תנאי ותמיד באותו סדר!
-You could also remove the unnecessary `else` branch to reduce the nesting. However, it's still important that all calls to Hooks happen *before* the first `return`.
+אתה יכול גם להסיר את הענף 'אחר' המיותר כדי להפחית את הקינון. עם זאת, עדיין חשוב שכל הקריאות לHooks יתרחשו *לפני* ה'חזרה' הראשונה.
<Sandpack>
@@ -1444,19 +1444,19 @@ export default function FeedbackForm() {
</Sandpack>
-Try moving the second `useState` call after the `if` condition and notice how this breaks it again.
+נסה להעביר את הקריאה 'useState' השנייה אחרי תנאי ה-'if' ושם לב איך זה שובר אותה.
-If your linter is [configured for React](/learn/editor-setup#linting), you should see a lint error when you make a mistake like this. If you don't see an error when you try the faulty code locally, you need to set up linting for your project.
+אם ה-linter שלך הוא [מוגדר עבור React](/learn/editor-setup#linting), אתה אמור לראות שגיאת מוך כשאתה עושה טעות כזו. אם אינך רואה שגיאה כאשר אתה מנסה את הקוד הפגום באופן מקומי, עליך להגדיר מוך עבור הפרויקט שלך.
</Solution>
-#### Remove unnecessary state {/*remove-unnecessary-state*/}
+#### הסר מצב מיותר {/*remove-unecessary-state*/}
-When the button is clicked, this example should ask for the user's name and then display an alert greeting them. You tried to use state to keep the name, but for some reason it always shows "Hello, !".
+כאשר לוחצים על הכפתור, דוגמה זו צריכה לבקש את שם המשתמש ולאחר מכן להציג התראה המברכת אותו. ניסית להשתמש ב-state כדי לשמור על השם, אבל מסיבה כלשהי הוא תמיד מראה "Hello, !".
-To fix this code, remove the unnecessary state variable. (We will discuss about [why this didn't work](/learn/state-as-a-snapshot) later.)
+כדי לתקן את הקוד הזה, הסר את משתנה הstate המיותר. (נדבר על [למה זה לא עבד](/learn/state-as-a-snapshot) מאוחר יותר.)
-Can you explain why this state variable was unnecessary?
+האם תוכל להסביר מדוע משתנה הstate הזה היה מיותר?
<Sandpack>
@@ -1483,7 +1483,7 @@ export default function FeedbackForm() {
<Solution>
-Here is a fixed version that uses a regular `name` variable declared in the function that needs it:
+הנה גרסה קבועה שמשתמשת במשתנה `שם` רגיל המוצהר בפונקציה שצריכה אותו:
<Sandpack>
@@ -1504,8 +1504,9 @@ export default function FeedbackForm() {
</Sandpack>
-A state variable is only necessary to keep information between re-renders of a component. Within a single event handler, a regular variable will do fine. Don't introduce state variables when a regular variable works well.
+משתנה מצב נחוץ רק כדי לשמור מידע בין עיבודים חוזרים של רכיב. בתוך מטפל באירוע בודד, משתנה רגיל יצליח. אל תציג משתני מצב כאשר משתנה רגיל עובד היטב.
</Solution>
</Challenges>
+
diff --git a/src/content/learn/state-as-a-snapshot.md b/src/content/learn/state-as-a-snapshot.md
index df4eddbd6..c791ad7f2 100644
--- a/src/content/learn/state-as-a-snapshot.md
+++ b/src/content/learn/state-as-a-snapshot.md
@@ -1,27 +1,27 @@
---
-title: State as a Snapshot
+title: "state כ-Snapshot"
---
<Intro>
-State variables might look like regular JavaScript variables that you can read and write to. However, state behaves more like a snapshot. Setting it does not change the state variable you already have, but instead triggers a re-render.
+משתני מצב עשויים להיראות כמו משתני JavaScript רגילים שאתה יכול לקרוא ולכתוב אליהם. עם זאת, הstate מתנהגת יותר כמו תמונת מצב. הגדרת זה לא משנה את משתנה הstate שכבר יש לך, אלא מפעילה עיבוד מחדש.
</Intro>
<YouWillLearn>
-* How setting state triggers re-renders
-* When and how state updates
-* Why state does not update immediately after you set it
-* How event handlers access a "snapshot" of the state
+* איך הגדרת מצב מפעילה עיבוד מחדש
+* מתי וכיצד עדכוני הstate
+* מדוע הstate לא מתעדכנת מיד לאחר הגדרתו
+* איך מטפלי אירועים ניגשים ל"תמונת מצב" של הstate
</YouWillLearn>
-## Setting state triggers renders {/*setting-state-triggers-renders*/}
+## הגדרת מצב מפעילים מעבד {/*setting-state-triggers-renders*/}
-You might think of your user interface as changing directly in response to the user event like a click. In React, it works a little differently from this mental model. On the previous page, you saw that [setting state requests a re-render](/learn/render-and-commit#step-1-trigger-a-render) from React. This means that for an interface to react to the event, you need to *update the state*.
+אתה עשוי לחשוב על ממשק המשתמש שלך כמשתנה ישירות בתגובה לאירוע המשתמש כמו קליק. ב-React, זה עובד קצת אחרת מהמודל המנטלי הזה. בעמוד הקודם, ראית ש[הגדרת מצב מבקש עיבוד מחדש](/learn/render-and-commit#step-1-trigger-a-render) מ-React. זה אומר שכדי שממשק יגיב לאירוע, צריך *לעדכן את הstate*.
-In this example, when you press "send", `setIsSent(true)` tells React to re-render the UI:
+בדוגמה זו, כאשר אתה לוחץ על "שלח", `setIsSent(true)` אומר ל-React לעבד מחדש את ממשק המשתמש:
<Sandpack>
@@ -61,25 +61,25 @@ label, textarea { margin-bottom: 10px; display: block; }
</Sandpack>
-Here's what happens when you click the button:
+זה מה שקורה כשאתה לוחץ על הכפתור:
-1. The `onSubmit` event handler executes.
-2. `setIsSent(true)` sets `isSent` to `true` and queues a new render.
-3. React re-renders the component according to the new `isSent` value.
+1. המטפל באירוע 'onSubmit' מבצע.
+2. `setIsSent(true)` מגדיר את `isSent` ל-`true` ומעמיד בתור עיבוד חדש.
+3. React מעבד מחדש את הרכיב בהתאם לערך 'isSent' החדש.
-Let's take a closer look at the relationship between state and rendering.
+בואו נסתכל מקרוב על הקשר בין מצב לעיבוד.
-## Rendering takes a snapshot in time {/*rendering-takes-a-snapshot-in-time*/}
+## העיבוד מצלם תמונת מצב בזמן {/*העיבוד-לוקח-תמונת-מצב-בזמן*/}
-["Rendering"](/learn/render-and-commit#step-2-react-renders-your-components) means that React is calling your component, which is a function. The JSX you return from that function is like a snapshot of the UI in time. Its props, event handlers, and local variables were all calculated **using its state at the time of the render.**
+["עיבוד"](/learn/render-and-commit#step-2-react-renders-your-components) פירושו ש-React קורא לרכיב שלך, שהוא פונקציה. ה-JSX שאתה מחזיר מהפונקציה הזו הוא כמו תמונת מצב של ממשק המשתמש בזמן. הprops, מטפלי האירועים והמשתנים המקומיים חושבו כולם **באמצעות מצבו בזמן העיבוד.**
-Unlike a photograph or a movie frame, the UI "snapshot" you return is interactive. It includes logic like event handlers that specify what happens in response to inputs. React updates the screen to match this snapshot and connects the event handlers. As a result, pressing a button will trigger the click handler from your JSX.
+שלא כמו תמונה או פריים של סרט, "תמונת הstate" של ממשק המשתמש שאתה מחזיר הוא אינטראקטיבי. זה כולל לוגיקה כמו מטפלי אירועים שמציינים מה קורה בתגובה לקלט. React מעדכנת את המסך כך שיתאים לתמונת מצב זו ומחברת את מטפלי האירועים. כתוצאה מכך, לחיצה על כפתור תפעיל את מטפל הקליקים מה-JSX שלך.
-When React re-renders a component:
+כאשר React מעבד מחדש רכיב:
-1. React calls your function again.
-2. Your function returns a new JSX snapshot.
-3. React then updates the screen to match the snapshot your function returned.
+1. React קורא לפונקציה שלך שוב.
+2. הפונקציה שלך מחזירה תמונת מצב חדשה של JSX.
+3. React מעדכן את המסך כך שיתאים לתמונת הstate שהפונקציה שלך החזירה.
<IllustrationBlock sequential>
<Illustration caption="React executing the function" src="/images/docs/illustrations/i_render1.png" />
@@ -87,7 +87,7 @@ When React re-renders a component:
<Illustration caption="Updating the DOM tree" src="/images/docs/illustrations/i_render3.png" />
</IllustrationBlock>
-As a component's memory, state is not like a regular variable that disappears after your function returns. State actually "lives" in React itself--as if on a shelf!--outside of your function. When React calls your component, it gives you a snapshot of the state for that particular render. Your component returns a snapshot of the UI with a fresh set of props and event handlers in its JSX, all calculated **using the state values from that render!**
+כזיכרון של רכיב, מצב אינו כמו משתנה רגיל שנעלם לאחר החזרה של הפונקציה שלך. הstate למעשה "חיה" ב-React עצמה - כאילו על מדף! - מחוץ לתפקידך. כאשר React קורא לרכיב שלך, הוא נותן לך תמונת מצב של העיבוד המסוים הזה. הרכיב שלך מחזיר תמונת מצב של ממשק המשתמש עם קבוצה חדשה של props ומטפלי אירועים ב-JSX שלו, כולם מחושבים **באמצעות ערכי הstate מהעיבוד הזה!**
<IllustrationBlock sequential>
<Illustration caption="You tell React to update the state" src="/images/docs/illustrations/i_state-snapshot1.png" />
@@ -95,9 +95,9 @@ As a component's memory, state is not like a regular variable that disappears af
<Illustration caption="React passes a snapshot of the state value into the component" src="/images/docs/illustrations/i_state-snapshot3.png" />
</IllustrationBlock>
-Here's a little experiment to show you how this works. In this example, you might expect that clicking the "+3" button would increment the counter three times because it calls `setNumber(number + 1)` three times.
+הנה ניסוי קטן כדי להראות לך איך זה עובד. בדוגמה זו, אתה עשוי לצפות שלחיצה על כפתור "+3" תגדיל את המונה שלוש פעמים מכיוון שהוא קורא ל'setNumber(מספר + 1)' שלוש פעמים.
-See what happens when you click the "+3" button:
+ראה מה קורה כשאתה לוחץ על כפתור "+3":
<Sandpack>
@@ -127,9 +127,9 @@ h1 { display: inline-block; margin: 10px; width: 30px; text-align: center; }
</Sandpack>
-Notice that `number` only increments once per click!
+שימו לב ש'מספר' עולה רק פעם אחת בכל קליק!
-**Setting state only changes it for the *next* render.** During the first render, `number` was `0`. This is why, in *that render's* `onClick` handler, the value of `number` is still `0` even after `setNumber(number + 1)` was called:
+**מצב ההגדרה משנה את זה רק עבור העיבוד *הבא*.** במהלך העיבוד הראשון, 'מספר' היה '0'. זו הסיבה, במטפל `onClick` של *הרינדור הזה, הערך של `number` עדיין `0` גם לאחר שנקרא `setNumber(number + 1)`:
```js
<button onClick={() => {
@@ -139,18 +139,18 @@ Notice that `number` only increments once per click!
}}>+3</button>
```
-Here is what this button's click handler tells React to do:
+הנה מה שמטפל הלחיצה של הכפתור הזה אומר ל-React לעשות:
-1. `setNumber(number + 1)`: `number` is `0` so `setNumber(0 + 1)`.
- - React prepares to change `number` to `1` on the next render.
-2. `setNumber(number + 1)`: `number` is `0` so `setNumber(0 + 1)`.
- - React prepares to change `number` to `1` on the next render.
-3. `setNumber(number + 1)`: `number` is `0` so `setNumber(0 + 1)`.
- - React prepares to change `number` to `1` on the next render.
+1. `setNumber(number + 1)`: `number` הוא `0` ולכן `setNumber(0 + 1)`.
+ - React מתכונן לשנות את 'מספר' ל-'1' בעיבוד הבא.
+2. `setNumber(number + 1)`: `number` הוא `0` ולכן `setNumber(0 + 1)`.
+ - React מתכונן לשנות את 'מספר' ל-'1' בעיבוד הבא.
+3. `setNumber(number + 1)`: `number` הוא `0` ולכן `setNumber(0 + 1)`.
+ - React מתכונן לשנות את 'מספר' ל-'1' בעיבוד הבא.
-Even though you called `setNumber(number + 1)` three times, in *this render's* event handler `number` is always `0`, so you set the state to `1` three times. This is why, after your event handler finishes, React re-renders the component with `number` equal to `1` rather than `3`.
+למרות שקראת 'setNumber(number + 1)' שלוש פעמים, במטפל האירועים של *העיבוד הזה* הוא תמיד '0', אז אתה מגדיר את הstate ל-'1' שלוש פעמים. זו הסיבה שאחרי שהמטפל באירועים שלך מסיים, React מעבד מחדש את הרכיב עם 'מספר' שווה ל-'1' במקום '3'.
-You can also visualize this by mentally substituting state variables with their values in your code. Since the `number` state variable is `0` for *this render*, its event handler looks like this:
+אתה יכול גם לדמיין זאת על ידי החלפה מנטלית של משתני מצב עם הערכים שלהם בקוד שלך. מכיוון שמשתנה הstate 'מספר' הוא '0' עבור *העיבוד הזה*, מטפל האירועים שלו נראה כך:
```js
<button onClick={() => {
@@ -160,7 +160,7 @@ You can also visualize this by mentally substituting state variables with their
}}>+3</button>
```
-For the next render, `number` is `1`, so *that render's* click handler looks like this:
+עבור העיבוד הבא, `מספר` הוא `1`, כך שמטפל הקליקים של *העיבוד* הזה נראה כך:
```js
<button onClick={() => {
@@ -170,11 +170,11 @@ For the next render, `number` is `1`, so *that render's* click handler looks lik
}}>+3</button>
```
-This is why clicking the button again will set the counter to `2`, then to `3` on the next click, and so on.
+זו הסיבה שלחיצה נוספת על הכפתור תגדיר את המונה ל-'2', ואז ל-'3' בלחיצה הבאה, וכן הלאה.
-## State over time {/*state-over-time*/}
+## מצב לאורך זמן {/*מצב-על-זמן*/}
-Well, that was fun. Try to guess what clicking this button will alert:
+ובכן, זה היה כיף. נסה לנחש מה תתריע לחיצה על הכפתור הזה:
<Sandpack>
@@ -203,14 +203,14 @@ h1 { display: inline-block; margin: 10px; width: 30px; text-align: center; }
</Sandpack>
-If you use the substitution method from before, you can guess that the alert shows "0":
+אם אתה משתמש בשיטת ההחלפה מקודם, אתה יכול לנחש שההתראה מציגה "0":
```js
setNumber(0 + 5);
alert(0);
```
-But what if you put a timer on the alert, so it only fires _after_ the component re-rendered? Would it say "0" or "5"? Have a guess!
+אבל מה אם תכניס טיימר להתראה, אז הוא יופעל רק _לאחר_ שהרכיב יוצג מחדש? האם יהיה כתוב "0" או "5"? יש לנחש!
<Sandpack>
@@ -241,7 +241,7 @@ h1 { display: inline-block; margin: 10px; width: 30px; text-align: center; }
</Sandpack>
-Surprised? If you use the substitution method, you can see the "snapshot" of the state passed to the alert.
+מוּפתָע? אם אתה משתמש בשיטת ההחלפה, אתה יכול לראות את "תמונת הstate" של הstate שהועברה להתראה.
```js
setNumber(0 + 5);
@@ -250,16 +250,16 @@ setTimeout(() => {
}, 3000);
```
-The state stored in React may have changed by the time the alert runs, but it was scheduled using a snapshot of the state at the time the user interacted with it!
+ייתכן שstate המאוחסן ב-React השתנה עד למועד הפעלת ההתראה, אבל זה תוכנן באמצעות תמונת מצב של הstate בזמן שהמשתמש קיים איתו אינטראקציה!
-**A state variable's value never changes within a render,** even if its event handler's code is asynchronous. Inside *that render's* `onClick`, the value of `number` continues to be `0` even after `setNumber(number + 5)` was called. Its value was "fixed" when React "took the snapshot" of the UI by calling your component.
+**ערך של משתנה מצב לעולם לא משתנה בתוך רינדור,** גם אם הקוד של מטפל האירועים שלו הוא אסינכרוני. בתוך `onClick` של *העיבוד*, הערך של `number` ממשיך להיות `0` גם לאחר שנקרא `setNumber(number + 5)`. הערך שלו "תוקן" כאשר React "לקח את תמונת הstate" של ממשק המשתמש על ידי קריאה לרכיב שלך.
-Here is an example of how that makes your event handlers less prone to timing mistakes. Below is a form that sends a message with a five-second delay. Imagine this scenario:
+הנה דוגמה לאופן שבו זה גורם למטפלי האירועים שלך להיות פחות מועדים לטעויות תזמון. להלן טופס ששולח הודעה באיחור של חמש שניות. דמיינו את התרחיש הזה:
-1. You press the "Send" button, sending "Hello" to Alice.
-2. Before the five-second delay ends, you change the value of the "To" field to "Bob".
+1. אתה לוחץ על כפתור "שלח", שולח "שלום" לאליס.
+2. לפני שההשהייה של חמש שניות מסתיימת, אתה משנה את הערך של השדה "To" ל-"Bob".
-What do you expect the `alert` to display? Would it display, "You said Hello to Alice"? Or would it display, "You said Hello to Bob"? Make a guess based on what you know, and then try it:
+מה אתה מצפה שה'התראה' תציג? האם זה יציג, "אמרת שלום לאליס"? או שהוא יציג, "אמרת שלום לבוב"? עשה ניחוש על סמך מה שאתה יודע, ואז נסה את זה:
<Sandpack>
@@ -305,19 +305,19 @@ label, textarea { margin-bottom: 10px; display: block; }
</Sandpack>
-**React keeps the state values "fixed" within one render's event handlers.** You don't need to worry whether the state has changed while the code is running.
+**React שומר על ערכי הstate "קבועים" בתוך מטפלי האירועים של רינדור אחד.** אינך צריך לדאוג אם הstate השתנה בזמן שהקוד פועל.
-But what if you wanted to read the latest state before a re-render? You'll want to use a [state updater function](/learn/queueing-a-series-of-state-updates), covered on the next page!
+אבל מה אם תרצה לקרוא את הstate האחרון לפני עיבוד מחדש? תרצה להשתמש ב[פונקציית עדכון מצב](/learn/queueing-a-series-of-state-updates), המכוסה בעמוד הבא!
<Recap>
-* Setting state requests a new render.
-* React stores state outside of your component, as if on a shelf.
-* When you call `useState`, React gives you a snapshot of the state *for that render*.
-* Variables and event handlers don't "survive" re-renders. Every render has its own event handlers.
-* Every render (and functions inside it) will always "see" the snapshot of the state that React gave to *that* render.
-* You can mentally substitute state in event handlers, similarly to how you think about the rendered JSX.
-* Event handlers created in the past have the state values from the render in which they were created.
+* הגדרת מצב מבקשת עיבוד חדש.
+* מצב חנויות React מחוץ לרכיב שלך, כאילו על מדף.
+* כאשר אתה קורא 'useState', React נותן לך תמונת מצב של הstate *עבור העיבוד הזה*.
+* משתנים ומטפלי אירועים אינם "שורדים" עיבוד מחדש. לכל עיבוד יש מטפלי אירועים משלו.
+* כל עיבוד (ומתפקד בתוכו) תמיד "יראה" את תמונת הstate של React נתנה לעיבוד *זה*.
+* אתה יכול להחליף מצב נפשית במטפלי אירועים, בדומה לאופן שבו אתה חושב על ה-JSX המעובד.
+* למטפלי אירועים שנוצרו בעבר יש את ערכי הstate מהעיבוד שבו הם נוצרו.
</Recap>
@@ -325,9 +325,9 @@ But what if you wanted to read the latest state before a re-render? You'll want
<Challenges>
-#### Implement a traffic light {/*implement-a-traffic-light*/}
+#### יישם רמזור {/*יישם-רמזור*/}
-Here is a crosswalk light component that toggles when the button is pressed:
+להלן רכיב תאורה של מעבר חציה שמתחלף בעת לחיצה על הכפתור:
<Sandpack>
@@ -362,13 +362,13 @@ h1 { margin-top: 20px; }
</Sandpack>
-Add an `alert` to the click handler. When the light is green and says "Walk", clicking the button should say "Stop is next". When the light is red and says "Stop", clicking the button should say "Walk is next".
+הוסף 'התראה' למטפל בלחיצה. כאשר האור ירוק ואומר "הליכה", לחיצה על הכפתור אמורה לומר "עצירה היא הבאה". כאשר האור אדום ואומר "עצור", לחיצה על הכפתור אמורה לומר "הליכה היא הבאה".
-Does it make a difference whether you put the `alert` before or after the `setWalk` call?
+האם זה משנה אם אתה שם את 'התראה' לפני או אחרי שיחת 'setWalk'?
<Solution>
-Your `alert` should look like this:
+ה'התראה' שלך צריכה להיראות כך:
<Sandpack>
@@ -404,17 +404,17 @@ h1 { margin-top: 20px; }
</Sandpack>
-Whether you put it before or after the `setWalk` call makes no difference. That render's value of `walk` is fixed. Calling `setWalk` will only change it for the *next* render, but will not affect the event handler from the previous render.
+אם אתה שם את זה לפני או אחרי שיחת `setWalk` לא משנה. הערך 'הליכה' של העיבוד הזה קבוע. קריאה ל-'setWalk' תשנה אותו רק עבור העיבוד *הבא*, אבל לא תשפיע על מטפל האירועים מהעיבוד הקודם.
-This line might seem counter-intuitive at first:
+השורה הזו עשויה להיראות מנוגדת לאינטואיציה בהתחלה:
```js
alert(walk ? 'Stop is next' : 'Walk is next');
```
-But it makes sense if you read it as: "If the traffic light shows 'Walk now', the message should say 'Stop is next.'" The `walk` variable inside your event handler matches that render's value of `walk` and does not change.
+אבל זה הגיוני אם אתה קורא את זה כך: "אם הרמזור מראה 'ללכת עכשיו', ההודעה אמורה לומר 'העצור זה הבא'." המשתנה 'הליכה' בתוך מטפל האירועים שלך תואם את הערך של העיבוד הזה של 'הליכה' ואינו משתנה.
-You can verify that this is correct by applying the substitution method. When `walk` is `true`, you get:
+אתה יכול לוודא שזה נכון על ידי יישום שיטת ההחלפה. כאשר 'הליכה' הוא 'נכון', אתה מקבל:
```js
<button onClick={() => {
@@ -428,8 +428,9 @@ You can verify that this is correct by applying the substitution method. When `w
</h1>
```
-So clicking "Change to Stop" queues a render with `walk` set to `false`, and alerts "Stop is next".
+אז לחיצה על "שנה לעצירה" מעמידה בתור עיבוד עם 'הליכה' מוגדרת ל'שקר', ומתריעה על "העצירה היא הבאה".
</Solution>
</Challenges>
+
diff --git a/src/content/learn/thinking-in-react.md b/src/content/learn/thinking-in-react.md
index 0f05a0569..6e04c24b6 100644
--- a/src/content/learn/thinking-in-react.md
+++ b/src/content/learn/thinking-in-react.md
@@ -1,18 +1,18 @@
---
-title: Thinking in React
+title: "חשיבה ב-React"
---
<Intro>
-React can change how you think about the designs you look at and the apps you build. When you build a user interface with React, you will first break it apart into pieces called *components*. Then, you will describe the different visual states for each of your components. Finally, you will connect your components together so that the data flows through them. In this tutorial, we’ll guide you through the thought process of building a searchable product data table with React.
+React יכול לשנות את האופן שבו אתה חושב על העיצובים שאתה מסתכל עליהם ועל האפליקציות שאתה בונה. כאשר אתה בונה ממשק משתמש עם React, תחילה תפרק אותו לחתיכות שנקראות *רכיבים*. לאחר מכן, תתאר את הstates החזותיים השונים עבור כל אחד מהרכיבים שלך. לבסוף, תחבר את הרכיבים שלך יחד כך שהנתונים יזרמו דרכם. במדריך זה, נדריך אותך בתהליך החשיבה של בניית טבלת נתוני מוצרים הניתנת לחיפוש עם React.
</Intro>
-## Start with the mockup {/*start-with-the-mockup*/}
+## התחל עם הדגם {/*התחל-עם-הדגם*/}
-Imagine that you already have a JSON API and a mockup from a designer.
+תאר לעצמך שכבר יש לך JSON API ודגם ממעצב.
-The JSON API returns some data that looks like this:
+ה-API של JSON מחזיר כמה נתונים שנראים כך:
```json
[
@@ -25,25 +25,25 @@ The JSON API returns some data that looks like this:
]
```
-The mockup looks like this:
+הדגם נראה כך:
<img src="/images/docs/s_thinking-in-react_ui.png" width="300" style={{margin: '0 auto'}} />
-To implement a UI in React, you will usually follow the same five steps.
+כדי ליישם ממשק משתמש ב-React, בדרך כלל תבצע את אותם חמשת שלבים.
-## Step 1: Break the UI into a component hierarchy {/*step-1-break-the-ui-into-a-component-hierarchy*/}
+## שלב 1: חלק את ממשק המשתמש להיררכיית רכיבים {/*step-1-break-the-ui-to-a-component-hierarchy*/}
-Start by drawing boxes around every component and subcomponent in the mockup and naming them. If you work with a designer, they may have already named these components in their design tool. Ask them!
+התחל על ידי ציור תיבות סביב כל רכיב ותת רכיב בדגם ותן להם שם. אם אתה עובד עם מעצב, ייתכן שהוא כבר קרא לרכיבים האלה בכלי העיצוב שלהם. תשאל אותם!
-Depending on your background, you can think about splitting up a design into components in different ways:
+בהתאם לרקע שלך, אתה יכול לחשוב על פיצול עיצוב לרכיבים בדרכים שונות:
-* **Programming**--use the same techniques for deciding if you should create a new function or object. One such technique is the [single responsibility principle](https://en.wikipedia.org/wiki/Single_responsibility_principle), that is, a component should ideally only do one thing. If it ends up growing, it should be decomposed into smaller subcomponents.
-* **CSS**--consider what you would make class selectors for. (However, components are a bit less granular.)
-* **Design**--consider how you would organize the design's layers.
+* **תכנות**--השתמש באותן טכניקות כדי להחליט אם עליך ליצור פונקציה או אובייקט חדש. טכניקה אחת כזו היא [עקרון האחריות היחידה](https://en.wikipedia.org/wiki/Single_responsibility_principle), כלומר, רכיב צריך לעשות רק דבר אחד. אם בסופו של דבר הוא גדל, יש לפרק אותו לתת-רכיבים קטנים יותר.
+* **CSS**--שקול בשביל מה היית עושה בוררי כיתות. (עם זאת, הרכיבים קצת פחות גרגירים.)
+* **עיצוב**--שקול כיצד היית מארגן את שכבות העיצוב.
-If your JSON is well-structured, you'll often find that it naturally maps to the component structure of your UI. That's because UI and data models often have the same information architecture--that is, the same shape. Separate your UI into components, where each component matches one piece of your data model.
+אם ה-JSON שלך מובנה היטב, לעתים קרובות תגלה שהוא ממפה באופן טבעי למבנה הרכיבים של ממשק המשתמש שלך. הסיבה לכך היא כי למודלים של ממשק משתמש ולנתונים יש לעתים קרובות את אותה ארכיטקטורת מידע - כלומר, אותה צורה. הפרד את ממשק המשתמש שלך לרכיבים, כאשר כל רכיב תואם חלק אחד של מודל הנתונים שלך.
-There are five components on this screen:
+ישנם חמישה רכיבים במסך זה:
<FullWidth>
@@ -51,33 +51,33 @@ There are five components on this screen:
<img src="/images/docs/s_thinking-in-react_ui_outline.png" width="500" style={{margin: '0 auto'}} />
-1. `FilterableProductTable` (grey) contains the entire app.
-2. `SearchBar` (blue) receives the user input.
-3. `ProductTable` (lavender) displays and filters the list according to the user input.
-4. `ProductCategoryRow` (green) displays a heading for each category.
-5. `ProductRow` (yellow) displays a row for each product.
+1. `FilterableProductTable` (אפור) מכיל את כל האפליקציה.
+2. 'סרגל החיפוש' (כחול) מקבל את קלט המשתמש.
+3. `ProductTable` (לבנדר) מציג ומסנן את הרשימה בהתאם לקלט המשתמש.
+4. `ProductCategoryRow` (ירוק) מציג כותרת עבור כל קטגוריה.
+5. `ProductRow` (צהוב) מציג שורה עבור כל מוצר.
</CodeDiagram>
</FullWidth>
-If you look at `ProductTable` (lavender), you'll see that the table header (containing the "Name" and "Price" labels) isn't its own component. This is a matter of preference, and you could go either way. For this example, it is a part of `ProductTable` because it appears inside the `ProductTable`'s list. However, if this header grows to be complex (e.g., if you add sorting), you can move it into its own `ProductTableHeader` component.
+אם תסתכל על `ProductTable` (לבנדר), תראה שכותרת הטבלה (המכילה את התוויות "שם" ו"מחיר") אינה רכיב משלה. זה עניין של העדפה, ואתה יכול ללכת לכל כיוון. עבור דוגמה זו, הוא חלק מ'ProductTable' מכיוון שהוא מופיע בתוך הרשימה של 'ProductTable'. עם זאת, אם הכותרת הזו גדלה להיות מורכבת (למשל, אם תוסיף מיון), תוכל להעביר אותה לרכיב 'ProductTableHeader' משלה.
-Now that you've identified the components in the mockup, arrange them into a hierarchy. Components that appear within another component in the mockup should appear as a child in the hierarchy:
+כעת לאחר שזיהית את הרכיבים בדגם, סדר אותם בהיררכיה. רכיבים המופיעים בתוך רכיב אחר בדגם צריכים להופיע בתור ילד בהיררכיה:
-* `FilterableProductTable`
- * `SearchBar`
+* 'TableProductTable'
+ * 'סרגל החיפוש'
* `ProductTable`
* `ProductCategoryRow`
* `ProductRow`
-## Step 2: Build a static version in React {/*step-2-build-a-static-version-in-react*/}
+## שלב 2: בנה גרסה סטטית ב-React {/*step-2-build-a-static-version-in-react*/}
-Now that you have your component hierarchy, it's time to implement your app. The most straightforward approach is to build a version that renders the UI from your data model without adding any interactivity... yet! It's often easier to build the static version first and add interactivity later. Building a static version requires a lot of typing and no thinking, but adding interactivity requires a lot of thinking and not a lot of typing.
+עכשיו כשיש לך את היררכיית הרכיבים שלך, הגיע הזמן ליישם את האפליקציה שלך. הגישה הפשוטה ביותר היא לבנות גרסה שמציגה את ממשק המשתמש ממודל הנתונים שלך מבלי להוסיף שום אינטראקטיביות... עדיין! לעתים קרובות קל יותר לבנות תחילה את הגרסה הסטטית ולהוסיף אינטראקטיביות מאוחר יותר. בניית גרסה סטטית דורשת הרבה הקלדה וללא חשיבה, אבל הוספת אינטראקטיביות דורשת הרבה חשיבה ולא הרבה הקלדה.
-To build a static version of your app that renders your data model, you'll want to build [components](/learn/your-first-component) that reuse other components and pass data using [props.](/learn/passing-props-to-a-component) Props are a way of passing data from parent to child. (If you're familiar with the concept of [state](/learn/state-a-components-memory), don't use state at all to build this static version. State is reserved only for interactivity, that is, data that changes over time. Since this is a static version of the app, you don't need it.)
+כדי לבנות גרסה סטטית של האפליקציה שלך שמציגה את מודל הנתונים שלך, תרצה לבנות [components](/learn/your-first-component) שעושים שימוש חוזר ברכיבים אחרים ומעבירים נתונים באמצעות [props.](/learn/passing-props-to-a-component) props הם דרך להעביר נתונים מהורה לילד. (אם אתה מכיר את המושג [state](/learn/state-a-components-memory), אל תשתמש כלל ב-state כדי לבנות את הגרסה הסטטית הזו. מצב שמור רק לאינטראקטיביות, כלומר, נתונים המשתנים עם הזמן. מכיוון שזו גרסה סטטית של האפליקציה, אינך צריך אותה.)
-You can either build "top down" by starting with building the components higher up in the hierarchy (like `FilterableProductTable`) or "bottom up" by working from components lower down (like `ProductRow`). In simpler examples, it’s usually easier to go top-down, and on larger projects, it’s easier to go bottom-up.
+אתה יכול לבנות "מלמעלה למטה" על ידי התחלת בבניית הרכיבים גבוה יותר בהיררכיה (כמו `FilterableProductTable`) או "מלמטה למעלה" על ידי עבודה מרכיבים למטה (כמו `ProductRow`). בדוגמאות פשוטות יותר, בדרך כלל קל יותר ללכת מלמעלה למטה, ובפרויקטים גדולים יותר, קל יותר ללכת מלמטה למעלה.
<Sandpack>
@@ -195,85 +195,85 @@ td {
</Sandpack>
-(If this code looks intimidating, go through the [Quick Start](/learn/) first!)
+(אם הקוד הזה נראה מאיים, עברו תחילה על [ההתחלה מהירה](/learn/)!)
-After building your components, you'll have a library of reusable components that render your data model. Because this is a static app, the components will only return JSX. The component at the top of the hierarchy (`FilterableProductTable`) will take your data model as a prop. This is called _one-way data flow_ because the data flows down from the top-level component to the ones at the bottom of the tree.
+לאחר בניית הרכיבים שלך, תהיה לך ספרייה של רכיבים לשימוש חוזר המציגים את מודל הנתונים שלך. מכיוון שמדובר באפליקציה סטטית, הרכיבים יחזירו רק JSX. הרכיב בראש ההיררכיה (`FilterableProductTable`) ייקח את מודל הנתונים שלך כprops. זה נקרא _זרימת נתונים חד כיוונית_ מכיוון שהנתונים זורמים למטה מהרכיב ברמה העליונה לאלה שבתחתית העץ.
<Pitfall>
-At this point, you should not be using any state values. That’s for the next step!
+בשלב זה, אינך אמור להשתמש בשום ערכי מצב. זה לשלב הבא!
</Pitfall>
-## Step 3: Find the minimal but complete representation of UI state {/*step-3-find-the-minimal-but-complete-representation-of-ui-state*/}
+## שלב 3: מצא את הייצוג המינימלי אך המלא של מצב ממשק המשתמש {/*step-3-find-the-minimal-but-complete-representation-of-ui-state*/}
-To make the UI interactive, you need to let users change your underlying data model. You will use *state* for this.
+כדי להפוך את ממשק המשתמש לאינטראקטיבי, עליך לאפשר למשתמשים לשנות את מודל הנתונים הבסיסי שלך. אתה תשתמש ב-*state* בשביל זה.
-Think of state as the minimal set of changing data that your app needs to remember. The most important principle for structuring state is to keep it [DRY (Don't Repeat Yourself).](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) Figure out the absolute minimal representation of the state your application needs and compute everything else on-demand. For example, if you're building a shopping list, you can store the items as an array in state. If you want to also display the number of items in the list, don't store the number of items as another state value--instead, read the length of your array.
+חשבו על הstate כעל קבוצת הנתונים המשתנים המינימלית שהאפליקציה שלכם צריכה לזכור. העיקרון החשוב ביותר למבנה מצב הוא לשמור אותו [יבש (אל תחזור על עצמך).](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) גלה את הייצוג המינימלי המוחלט של הstate שהיישום שלך צריך וחשב את כל השאר לפי דרישה. לדוגמה, אם אתה בונה רשימת קניות, אתה יכול לאחסן את הפריטים כמערך בstate. אם ברצונך להציג גם את מספר הפריטים ברשימה, אל תשמור את מספר הפריטים כערך מצב אחר - במקום זאת, קרא את אורך המערך שלך.
-Now think of all of the pieces of data in this example application:
+עכשיו תחשוב על כל פיסות הנתונים ביישום לדוגמה זה:
-1. The original list of products
-2. The search text the user has entered
-3. The value of the checkbox
-4. The filtered list of products
+1. רשימת המוצרים המקורית
+2. טקסט החיפוש שהמשתמש הזין
+3. הערך של תיבת הסימון
+4. רשימת המוצרים המסוננת
-Which of these are state? Identify the ones that are not:
+אילו מאלה הם state? זהה את אלה שאינם:
-* Does it **remain unchanged** over time? If so, it isn't state.
-* Is it **passed in from a parent** via props? If so, it isn't state.
-* **Can you compute it** based on existing state or props in your component? If so, it *definitely* isn't state!
+* האם זה **נשאר ללא שינוי** לאורך זמן? אם כן, זה לא state.
+* האם זה **מועבר מהורה** באמצעות props? אם כן, זה לא state.
+* **האם אתה יכול לחשב את זה** על סמך הstate הקיים או הprops ברכיב שלך? אם כן, זה *בהחלט* לא state!
-What's left is probably state.
+מה שנשאר זה כנראה הstate.
-Let's go through them one by one again:
+בואו נעבור עליהם אחד אחד שוב:
-1. The original list of products is **passed in as props, so it's not state.**
-2. The search text seems to be state since it changes over time and can't be computed from anything.
-3. The value of the checkbox seems to be state since it changes over time and can't be computed from anything.
-4. The filtered list of products **isn't state because it can be computed** by taking the original list of products and filtering it according to the search text and value of the checkbox.
+1. רשימת המוצרים המקורית **מועברת כprops, כך שהיא לא רשומה.**
+2. נראה שטקסט החיפוש הוא מצב מכיוון שהוא משתנה עם הזמן ולא ניתן לחשב אותו מכלום.
+3. נראה שהערך של תיבת הסימון הוא מצב מכיוון שהיא משתנה עם הזמן ואי אפשר לחשב אותה מכלום.
+4. רשימת המוצרים המסוננת **לא מוגדרת כי ניתן לחשב אותה** על ידי נטילת רשימת המוצרים המקורית וסינונה בהתאם לטקסט החיפוש ולערך של תיבת הסימון.
-This means only the search text and the value of the checkbox are state! Nicely done!
+זה אומר שרק טקסט החיפוש והערך של תיבת הסימון הם מצב! יפה!
<DeepDive>
-#### Props vs State {/*props-vs-state*/}
+#### props נגד state {/*props-vs-state*/}
-There are two types of "model" data in React: props and state. The two are very different:
+ישנם שני סוגים של נתוני "מודל" ב-React: props וstate. השניים מאוד שונים:
-* [**Props** are like arguments you pass](/learn/passing-props-to-a-component) to a function. They let a parent component pass data to a child component and customize its appearance. For example, a `Form` can pass a `color` prop to a `Button`.
-* [**State** is like a component’s memory.](/learn/state-a-components-memory) It lets a component keep track of some information and change it in response to interactions. For example, a `Button` might keep track of `isHovered` state.
+* [**props** הם כמו ארגומנטים שאתה מעביר](/learn/sending-props-to-a-component) לפונקציה. הם מאפשרים לרכיב אב להעביר נתונים לרכיב צאצא ולהתאים אישית את המראה שלו. לדוגמה, 'טופס' יכול להעביר props 'צבע' ל'כפתור'.
+* [**מצב** הוא כמו זיכרון של רכיב.](/learn/state-a-components-memory) הוא מאפשר לרכיב לעקוב אחר מידע מסוים ולשנות אותו בתגובה לאינטראקציות. לדוגמה, `לחצן` עשוי לעקוב אחר מצב `isHovered`.
-Props and state are different, but they work together. A parent component will often keep some information in state (so that it can change it), and *pass it down* to child components as their props. It's okay if the difference still feels fuzzy on the first read. It takes a bit of practice for it to really stick!
+props וstate שונים, אבל הם עובדים יחד. רכיב הורה ישמור לעתים קרובות מידע מסויים בstate (כדי שיוכל לשנות אותו), ו*יעביר אותו* לרכיבי ילדים בתור הprops שלו. זה בסדר אם ההבדל עדיין מרגיש מעורפל בקריאה הראשונה. צריך קצת תרגול כדי שזה באמת יידבק!
</DeepDive>
-## Step 4: Identify where your state should live {/*step-4-identify-where-your-state-should-live*/}
+## שלב 4: זהה היכן הstate שלך צריכה לגור {/*step-4-identify-where-your-state-should-live*/}
-After identifying your app’s minimal state data, you need to identify which component is responsible for changing this state, or *owns* the state. Remember: React uses one-way data flow, passing data down the component hierarchy from parent to child component. It may not be immediately clear which component should own what state. This can be challenging if you’re new to this concept, but you can figure it out by following these steps!
+לאחר זיהוי נתוני הstate המינימלי של האפליקציה שלך, עליך לזהות איזה רכיב אחראי לשינוי הstate הזה, או *הבעלים* של הstate. זכור: React משתמשת בזרימת נתונים חד-כיוונית, ומעבירה נתונים במורד היררכיית הרכיבים מהורה לרכיב צאצא. ייתכן שלא ברור מיידית איזה רכיב צריך להיות הבעלים של איזו state. זה יכול להיות מאתגר אם אתה חדש בקונספט הזה, אבל אתה יכול להבין את זה על ידי ביצוע השלבים הבאים!
-For each piece of state in your application:
+עבור כל פיסת state בבקשה שלך:
-1. Identify *every* component that renders something based on that state.
-2. Find their closest common parent component--a component above them all in the hierarchy.
-3. Decide where the state should live:
- 1. Often, you can put the state directly into their common parent.
- 2. You can also put the state into some component above their common parent.
- 3. If you can't find a component where it makes sense to own the state, create a new component solely for holding the state and add it somewhere in the hierarchy above the common parent component.
+1. זהה *כל* רכיב שמציג משהו על סמך הstate הזה.
+2. מצא את רכיב האב המשותף הקרוב ביותר שלהם - רכיב מעל כולם בהיררכיה.
+3. להחליט היכן הstate צריכה לגור:
+ 1. לעתים קרובות, אתה יכול להכניס את הstate ישירות להורה המשותף שלהם.
+ 2. אתה יכול גם להכניס את הstate לרכיב כלשהו מעל ההורה המשותף שלהם.
+ 3. אם אינך מוצא רכיב שבו הגיוני להחזיק בstate, צור רכיב חדש אך ורק עבור החזקת הstate והוסף אותו איפשהו בהיררכיה מעל רכיב האב המשותף.
-In the previous step, you found two pieces of state in this application: the search input text, and the value of the checkbox. In this example, they always appear together, so it makes sense to put them into the same place.
+בשלב הקודם, מצאת שני חלקי state ביישום זה: טקסט קלט החיפוש והערך של תיבת הסימון. בדוגמה זו, הם תמיד מופיעים יחד, אז זה הגיוני לשים אותם באותו מקום.
-Now let's run through our strategy for them:
+עכשיו בואו נעבור על האסטרטגיה שלנו עבורם:
-1. **Identify components that use state:**
- * `ProductTable` needs to filter the product list based on that state (search text and checkbox value).
- * `SearchBar` needs to display that state (search text and checkbox value).
-1. **Find their common parent:** The first parent component both components share is `FilterableProductTable`.
-2. **Decide where the state lives**: We'll keep the filter text and checked state values in `FilterableProductTable`.
+1. **זהה רכיבים שמשתמשים בstate:**
+ * `ProductTable` צריך לסנן את רשימת המוצרים על סמך הstate הזה (טקסט חיפוש וערך תיבת סימון).
+ * 'סרגל החיפוש' צריך להציג את הstate הזה (טקסט חיפוש וערך תיבת סימון).
+1. **מצא את האב המשותף שלהם:** רכיב האב הראשון ששני הרכיבים חולקים הוא `FilterableProductTable`.
+2. **החלט היכן הstate גרה**: נשמור את טקסט המסנן ואת ערכי הstate המסומנים ב-'FilterableProductTable'.
-So the state values will live in `FilterableProductTable`.
+אז ערכי הstate יחיו ב-'FilterableProductTable'.
-Add state to the component with the [`useState()` Hook.](/reference/react/useState) Hooks are special functions that let you "hook into" React. Add two state variables at the top of `FilterableProductTable` and specify their initial state:
+הוסף מצב לרכיב עם [`useState()` Hook.](/reference/react/useState) Hooks הם פונקציות מיוחדות המאפשרות לך "להתחבר" ל-React. הוסף שני משתני מצב בחלק העליון של 'FilterableProductTable' וציין את הstate ההתחלתי שלהם:
```js
function FilterableProductTable({ products }) {
@@ -281,7 +281,7 @@ function FilterableProductTable({ products }) {
const [inStockOnly, setInStockOnly] = useState(false);
```
-Then, pass `filterText` and `inStockOnly` to `ProductTable` and `SearchBar` as props:
+לאחר מכן, העבר את 'filterText' ו-'inStockOnly' אל 'ProductTable' ו-'SearchBar' בתור props:
```js
<div>
@@ -295,7 +295,7 @@ Then, pass `filterText` and `inStockOnly` to `ProductTable` and `SearchBar` as p
</div>
```
-You can start seeing how your application will behave. Edit the `filterText` initial value from `useState('')` to `useState('fruit')` in the sandbox code below. You'll see both the search input text and the table update:
+אתה יכול להתחיל לראות איך האפליקציה שלך תתנהג. ערוך את הערך ההתחלתי של `filterText` מ`useState('')` ל`useState('fruit')` בקוד ארגז החול למטה. תראה גם את טקסט קלט החיפוש וגם את עדכון הטבלה:
<Sandpack>
@@ -437,15 +437,15 @@ td {
</Sandpack>
-Notice that editing the form doesn't work yet. There is a console error in the sandbox above explaining why:
+שימו לב שעריכת הטופס עדיין לא עובדת. יש שגיאת קונסולה בארגז החול למעלה שמסבירה מדוע:
<ConsoleBlock level="error">
-You provided a \`value\` prop to a form field without an \`onChange\` handler. This will render a read-only field.
+סיפקת props \`value\` לשדה טופס ללא מטפל \`onChange\`. זה יציג שדה לקריאה בלבד.
</ConsoleBlock>
-In the sandbox above, `ProductTable` and `SearchBar` read the `filterText` and `inStockOnly` props to render the table, the input, and the checkbox. For example, here is how `SearchBar` populates the input value:
+בארגז החול שלמעלה, `ProductTable` ו`SearchBar` קראו את props `filterText` ו-`inStockOnly` כדי להציג את הטבלה, הקלט ותיבה. לדוגמה, כך 'סרגל החיפוש' מאכלס את ערך הקלט:
```js {1,6}
function SearchBar({ filterText, inStockOnly }) {
@@ -457,16 +457,16 @@ function SearchBar({ filterText, inStockOnly }) {
placeholder="Search..."/>
```
-However, you haven't added any code to respond to the user actions like typing yet. This will be your final step.
+עם זאת, עדיין לא הוספת קוד כדי להגיב לפעולות המשתמש כמו הקלדה. זה יהיה הצעד האחרון שלך.
-## Step 5: Add inverse data flow {/*step-5-add-inverse-data-flow*/}
+## שלב 5: הוסף זרימת נתונים הפוכה {/*step-5-add-inverse-data-flow*/}
-Currently your app renders correctly with props and state flowing down the hierarchy. But to change the state according to user input, you will need to support data flowing the other way: the form components deep in the hierarchy need to update the state in `FilterableProductTable`.
+נכון לעכשיו, האפליקציה שלך מוצגת בצורה נכונה עם props וstate זורמים במורד ההיררכיה. אבל כדי לשנות את הstate בהתאם לקלט המשתמש, תצטרך לתמוך בנתונים הזורמים לכיוון השני: רכיבי הטופס עמוק בהיררכיה צריכים לעדכן את הstate ב-'FilterableProductTable'.
-React makes this data flow explicit, but it requires a little more typing than two-way data binding. If you try to type or check the box in the example above, you'll see that React ignores your input. This is intentional. By writing `<input value={filterText} />`, you've set the `value` prop of the `input` to always be equal to the `filterText` state passed in from `FilterableProductTable`. Since `filterText` state is never set, the input never changes.
+React הופך את זרימת הנתונים הזו למפורשת, אבל היא דורשת קצת יותר הקלדה מאשר איגוד נתונים דו-כיווני. אם תנסה להקליד או לסמן את התיבה בדוגמה למעלה, תראה ש-React מתעלם מהקלט שלך. זה מכוון. על ידי כתיבת `<input value={filterText} />`, הגדרת את הפרופס של `value` של `input` להיות תמיד שווה לstate `filterText` המועבר מ`FilterableProductTable`. מכיוון שstate 'filterText' לעולם אינו מוגדר, הקלט לעולם לא משתנה.
-You want to make it so whenever the user changes the form inputs, the state updates to reflect those changes. The state is owned by `FilterableProductTable`, so only it can call `setFilterText` and `setInStockOnly`. To let `SearchBar` update the `FilterableProductTable`'s state, you need to pass these functions down to `SearchBar`:
+אתה רוצה להפוך את זה כך שבכל פעם שהמשתמש משנה את קלט הטופס, הstate מתעדכן כדי לשקף את השינויים האלה. הstate נמצאת בבעלות `FilterableProductTable`, כך שרק היא יכולה לקרוא ל`setFilterText` ו-`setInStockOnly`. כדי לאפשר ל-SearchBar לעדכן את מצב ה-FilterableProductTable, עליך להעביר את הפונקציות האלה ל-SearchBar:
```js {2,3,10,11}
function FilterableProductTable({ products }) {
@@ -482,7 +482,7 @@ function FilterableProductTable({ products }) {
onInStockOnlyChange={setInStockOnly} />
```
-Inside the `SearchBar`, you will add the `onChange` event handlers and set the parent state from them:
+בתוך 'סרגל החיפוש', תוסיף את מטפלי האירועים 'onChange' ותגדיר מהם את מצב האב:
```js {4,5,13,19}
function SearchBar({
@@ -506,7 +506,7 @@ function SearchBar({
onChange={(e) => onInStockOnlyChange(e.target.checked)}
```
-Now the application fully works!
+עכשיו האפליקציה עובדת במלואה!
<Sandpack>
@@ -656,8 +656,9 @@ td {
</Sandpack>
-You can learn all about handling events and updating state in the [Adding Interactivity](/learn/adding-interactivity) section.
+תוכל ללמוד הכל על טיפול באירועים וstate עדכון בקטע [הוספת אינטראקטיביות](/learn/adding-interactivity).
-## Where to go from here {/*where-to-go-from-here*/}
+## לאן ללכת מכאן {/*לאן-ללכת-מכאן*/}
+
+זה היה הקדמה קצרה מאוד כיצד לחשוב על בניית רכיבים ויישומים עם React. אתה יכול [להתחיל פרויקט React](/learn/installation) עכשיו או [לצלול עמוק יותר על כל התחביר](/learn/describing-the-ui) בשימוש במדריך זה.
-This was a very brief introduction to how to think about building components and applications with React. You can [start a React project](/learn/installation) right now or [dive deeper on all the syntax](/learn/describing-the-ui) used in this tutorial.
diff --git a/src/content/learn/typescript.md b/src/content/learn/typescript.md
index 034ac0d46..5d0020d81 100644
--- a/src/content/learn/typescript.md
+++ b/src/content/learn/typescript.md
@@ -1,57 +1,57 @@
---
-title: Using TypeScript
+title: "שימוש ב-TypeScript"
re: https://github.com/reactjs/react.dev/issues/5960
---
<Intro>
-TypeScript is a popular way to add type definitions to JavaScript codebases. Out of the box, TypeScript [supports JSX](/learn/writing-markup-with-jsx) and you can get full React Web support by adding [`@types/react`](https://www.npmjs.com/package/@types/react) and [`@types/react-dom`](https://www.npmjs.com/package/@types/react-dom) to your project.
+TypeScript היא דרך פופולרית להוסיף הגדרות סוג לבסיסי קוד של JavaScript. מהקופסה, TypeScript [תומך ב-JSX](/learn/writing-markup-with-jsx) ותוכל לקבל תמיכה מלאה באינטרנט של React על ידי הוספת [`@types/react`](https://www.npmjs.com/package/@types/react) ו-[`@types/react-dom`](j/https://www.com/pm) your pack פרויקט.
</Intro>
<YouWillLearn>
-* [TypeScript with React Components](/learn/typescript#typescript-with-react-components)
-* [Examples of typing with Hooks](/learn/typescript#example-hooks)
-* [Common types from `@types/react`](/learn/typescript/#useful-types)
-* [Further learning locations](/learn/typescript/#further-learning)
+* [TypeScript עם רכיבי React](/learn/typescript#typescript-with-react-components)
+* [דוגמאות של הקלדה עם Hooks](/learn/typescript#example-hooks)
+* [סוגים נפוצים מ-`@types/react`](/learn/typescript/#useful-types)
+* [מיקומי למידה נוספים](/learn/typescript/#further-learning)
</YouWillLearn>
-## Installation {/*installation*/}
+## התקנה {/*התקנה*/}
-All [production-grade React frameworks](/learn/start-a-new-react-project#production-grade-react-frameworks) offer support for using TypeScript. Follow the framework specific guide for installation:
+כל [מסגרות React בדרגת יצירה](/learn/start-a-new-react-project#production-grade-react-frameworks) מציעות תמיכה לשימוש ב-TypeScript. עקוב אחר המדריך הספציפי למסגרת להתקנה:
- [Next.js](https://nextjs.org/docs/pages/building-your-application/configuring/typescript)
-- [Remix](https://remix.run/docs/en/1.19.2/guides/typescript)
-- [Gatsby](https://www.gatsbyjs.com/docs/how-to/custom-configuration/typescript/)
-- [Expo](https://docs.expo.dev/guides/typescript/)
+- [רמיקס](https://remix.run/docs/en/1.19.2/guides/typescript)
+- [גטסבי](https://www.gatsbyjs.com/docs/how-to/custom-configuration/typescript/)
+- [אקספו](https://docs.expo.dev/guides/typescript/)
-### Adding TypeScript to an existing React project {/*adding-typescript-to-an-existing-react-project*/}
+### הוספת TypeScript לפרויקט React קיים {/*adding-typescript-to-an-existing-react-project*/}
-To install the latest version of React's type definitions:
+כדי להתקין את הגרסה העדכנית ביותר של הגדרות הסוג של React:
<TerminalBlock>
-npm install @types/react @types/react-dom
+npm להתקין את @types/react @types/react-dom
</TerminalBlock>
-The following compiler options need to be set in your `tsconfig.json`:
+יש להגדיר את אפשרויות המהדר הבאות ב-`tsconfig.json` שלך:
-1. `dom` must be included in [`lib`](https://www.typescriptlang.org/tsconfig/#lib) (Note: If no `lib` option is specified, `dom` is included by default).
-1. [`jsx`](https://www.typescriptlang.org/tsconfig/#jsx) must be set to one of the valid options. `preserve` should suffice for most applications.
- If you're publishing a library, consult the [`jsx` documentation](https://www.typescriptlang.org/tsconfig/#jsx) on what value to choose.
+1. יש לכלול `dom` ב-[`lib`](https://www.typescriptlang.org/tsconfig/#lib) (הערה: אם לא צוינה אפשרות `lib`, `dom` נכלל כברירת מחדל).
+1. יש להגדיר את [`jsx`](https://www.typescriptlang.org/tsconfig/#jsx) לאחת מהאפשרויות החוקיות. `שמר` אמור להספיק לרוב היישומים.
+ אם אתה מפרסם ספריה, עיין בתיעוד [`jsx`](https://www.typescriptlang.org/tsconfig/#jsx) על איזה ערך לבחור.
-## TypeScript with React Components {/*typescript-with-react-components*/}
+## TypeScript עם רכיבי React {/*typescript-with-react-components*/}
<Note>
-Every file containing JSX must use the `.tsx` file extension. This is a TypeScript-specific extension that tells TypeScript that this file contains JSX.
+כל קובץ המכיל JSX חייב להשתמש בסיומת הקובץ `.tsx`. זוהי הרחבה ספציפית ל-TypeScript שאומרת ל-TypeScript שהקובץ הזה מכיל JSX.
</Note>
-Writing TypeScript with React is very similar to writing JavaScript with React. The key difference when working with a component is that you can provide types for your component's props. These types can be used for correctness checking and providing inline documentation in editors.
+כתיבת TypeScript עם React דומה מאוד לכתיבת JavaScript עם React. ההבדל העיקרי בעבודה עם רכיב הוא שאתה יכול לספק סוגים עבור הprops של הרכיב שלך. ניתן להשתמש בסוגים אלה לבדיקת נכונות ולמתן תיעוד מוטבע בעורכים.
-Taking the [`MyButton` component](/learn#components) from the [Quick Start](/learn) guide, we can add a type describing the `title` for the button:
+אם ניקח את הרכיב [`MyButton`](/learn#components) מהמדריך [התחלה מהירה](/learn), נוכל להוסיף סוג המתאר את ה`כותרת` עבור הכפתור:
<Sandpack>
@@ -80,11 +80,11 @@ export default App = AppTSX;
<Note>
-These sandboxes can handle TypeScript code, but they do not run the type-checker. This means you can amend the TypeScript sandboxes to learn, but you won't get any type errors or warnings. To get type-checking, you can use the [TypeScript Playground](https://www.typescriptlang.org/play) or use a more fully-featured online sandbox.
+ארגזי חול אלו יכולים להתמודד עם קוד TypeScript, אך הם לא מריצים את בודק הסוג. זה אומר שאתה יכול לשנות את ארגזי החול של TypeScript כדי ללמוד, אבל לא תקבל שגיאות סוג או אזהרות. כדי לבצע בדיקת סוגים, אתה יכול להשתמש ב-[TypeScript Playground](https://www.typescriptlang.org/play) או להשתמש בארגז חול מקוון מלא יותר.
</Note>
-This inline syntax is the simplest way to provide types for a component, though once you start to have a few fields to describe it can become unwieldy. Instead, you can use an `interface` or `type` to describe the component's props:
+תחביר מוטבע זה הוא הדרך הפשוטה ביותר לספק טיפוסים עבור רכיב, אם כי ברגע שמתחילים לקבל כמה שדות לתאר, זה יכול להפוך למסורבל. במקום זאת, אתה יכול להשתמש ב'ממשק' או 'סוג' כדי לתאר את הprops של הרכיב:
<Sandpack>
@@ -119,32 +119,32 @@ export default App = AppTSX;
</Sandpack>
-The type describing your component's props can be as simple or as complex as you need, though they should be an object type described with either a `type` or `interface`. You can learn about how TypeScript describes objects in [Object Types](https://www.typescriptlang.org/docs/handbook/2/objects.html) but you may also be interested in using [Union Types](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#union-types) to describe a prop that can be one of a few different types and the [Creating Types from Types](https://www.typescriptlang.org/docs/handbook/2/types-from-types.html) guide for more advanced use cases.
+הסוג המתאר את הprops של הרכיב שלך יכול להיות פשוט או מורכב ככל שאתה צריך, אם כי הם צריכים להיות סוג אובייקט המתואר עם 'סוג' או 'ממשק'. אתה יכול ללמוד כיצד TypeScript מתאר אובייקטים ב-[Object Types](https://www.typescriptlang.org/docs/handbook/2/objects.html), אך ייתכן שתהיה מעוניין גם בשימוש ב-[Union Types](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#union-types) כדי לתאר סוג אחד של [סוגים שונים וסוגים שונים] סוגים](https://www.typescriptlang.org/docs/handbook/2/types-from-types.html) מדריך למקרי שימוש מתקדמים יותר.
-## Example Hooks {/*example-hooks*/}
+## ווים לדוגמה {/*example-hooks*/}
-The type definitions from `@types/react` include types for the built-in Hooks, so you can use them in your components without any additional setup. They are built to take into account the code you write in your component, so you will get [inferred types](https://www.typescriptlang.org/docs/handbook/type-inference.html) a lot of the time and ideally do not need to handle the minutiae of providing the types.
+הגדרות הסוג מ- `@types/react` כוללות טיפוסים עבור ה-Hooks המובנים, כך שתוכל להשתמש בהם ברכיבים שלך ללא כל הגדרה נוספת. הם בנויים כדי לקחת בחשבון את הקוד שאתה כותב ברכיב שלך, כך שתקבל [טיפוסים משוערים](https://www.typescriptlang.org/docs/handbook/type-inference.html) הרבה מהזמן ובאופן אידיאלי לא תצטרך להתמודד עם הפרטים הקטנים של אספקת הסוגים.
-However, we can look at a few examples of how to provide types for Hooks.
+עם זאת, אנו יכולים להסתכל על כמה דוגמאות כיצד לספק סוגים עבור Hooks.
### `useState` {/*typing-usestate*/}
-The [`useState` Hook](/reference/react/useState) will re-use the value passed in as the initial state to determine what the type of the value should be. For example:
+ה-[`useState` Hook](/reference/react/useState) יעשה שימוש חוזר בערך המועבר כstate ההתחלתי כדי לקבוע מה סוג הערך צריך להיות. לְדוּגמָה:
```ts
// Infer the type as "boolean"
const [enabled, setEnabled] = useState(false);
```
-Will assign the type of `boolean` to `enabled`, and `setEnabled` will be a function accepting either a `boolean` argument, or a function that returns a `boolean`. If you want to explicitly provide a type for the state, you can do so by providing a type argument to the `useState` call:
+יקצה את הסוג 'בוליאני' ל-'enabled', ו-'setEnabled' תהיה פונקציה שמקבלת ארגומנט 'בוליאני', או פונקציה שמחזירה 'בוליאני'. אם אתה רוצה לספק במפורש סוג עבור הstate, אתה יכול לעשות זאת על ידי מתן ארגומנט סוג לקריאה 'useState':
```ts
// Explicitly set the type to "boolean"
const [enabled, setEnabled] = useState<boolean>(false);
```
-This isn't very useful in this case, but a common case where you may want to provide a type is when you have a union type. For example, `status` here can be one of a few different strings:
+זה לא מאוד שימושי במקרה זה, אבל מקרה נפוץ שבו אולי תרצה לספק סוג הוא כאשר יש לך סוג איגוד. לדוגמה, 'סטטוס' כאן יכול להיות אחת מכמה מחרוזות שונות:
```ts
type Status = "idle" | "loading" | "success" | "error";
@@ -152,7 +152,7 @@ type Status = "idle" | "loading" | "success" | "error";
const [status, setStatus] = useState<Status>("idle");
```
-Or, as recommended in [Principles for structuring state](/learn/choosing-the-state-structure#principles-for-structuring-state), you can group related state as an object and describe the different possibilities via object types:
+לחלופין, כפי שהומלץ ב-[עקרונות לstate מבנה](/למד/בחירת-ה-מצב-מבנה#עקרונות-ל-מצב-מבנה), אתה יכול לקבץ מצב קשור כאובייקט ולתאר את האפשרויות השונות באמצעות סוגי אובייקטים:
```ts
type RequestState =
@@ -164,9 +164,9 @@ type RequestState =
const [requestState, setRequestState] = useState<RequestState>({ status: 'idle' });
```
-### `useReducer` {/*typing-usereducer*/}
+### `useReducer` {/*הקלדה-usereducer*/}
-The [`useReducer` Hook](/reference/react/useReducer) is a more complex Hook that takes a reducer function and an initial state. The types for the reducer function are inferred from the initial state. You can optionally provide a type argument to the `useReducer` call to provide a type for the state, but it is often better to set the type on the initial state instead:
+ה-[`useReducer` Hook](/reference/react/useReducer) הוא Hook מורכב יותר שלוקח פונקציית reducer וstate התחלתי. הסוגים של פונקציית הreducer נגזרים מstate ההתחלתי. באפשרותך לספק ארגומנט סוג לקריאה 'useReducer' כדי לספק סוג עבור הstate, אך לרוב עדיף להגדיר את הסוג בstate ההתחלתי במקום זאת:
<Sandpack>
@@ -221,14 +221,14 @@ export default App = AppTSX;
</Sandpack>
-We are using TypeScript in a few key places:
+אנו משתמשים ב-TypeScript בכמה מקומות מרכזיים:
- - `interface State` describes the shape of the reducer's state.
- - `type CounterAction` describes the different actions which can be dispatched to the reducer.
- - `const initialState: State` provides a type for the initial state, and also the type which is used by `useReducer` by default.
- - `stateReducer(state: State, action: CounterAction): State` sets the types for the reducer function's arguments and return value.
+ - `מצב ממשק` מתאר את צורת מצב הreducer.
+ - `סוג CounterAction` מתאר את הפעולות השונות שניתן לשלוח לreducer.
+ - `const initialState: State` מספק סוג עבור הstate ההתחלתי, וגם את הסוג שבו משתמשים `useReducer` כברירת מחדל.
+ - `stateReducer(state: State, action: CounterAction): State` מגדיר את סוגי הארגומנטים וערך ההחזרה של פונקציית הreducer.
-A more explicit alternative to setting the type on `initialState` is to provide a type argument to `useReducer`:
+חלופה מפורשת יותר להגדרת הסוג ב-'initialState' היא לספק ארגומנט סוג ל-'useReducer':
```ts
import { stateReducer, State } from './your-reducer-implementation';
@@ -240,11 +240,11 @@ export default function App() {
}
```
-### `useContext` {/*typing-usecontext*/}
+### `useContext` {/*הקלדה-usecontext*/}
-The [`useContext` Hook](/reference/react/useContext) is a technique for passing data down the component tree without having to pass props through components. It is used by creating a provider component and often by creating a Hook to consume the value in a child component.
+ה-[`useContext` Hook](/reference/react/useContext) היא טכניקה להעברת נתונים בעץ הרכיבים ללא צורך להעביר props דרך רכיבים. הוא משמש על ידי יצירת רכיב ספק ולעתים קרובות על ידי יצירת Hook כדי לצרוך את הערך ברכיב צאצא.
-The type of the value provided by the context is inferred from the value passed to the `createContext` call:
+סוג הערך שסופק על ידי ההקשר מוסק מהערך המועבר לקריאה 'createContext':
<Sandpack>
@@ -284,9 +284,9 @@ export default App = AppTSX;
</Sandpack>
-This technique works when you have a default value which makes sense - but there are occasionally cases when you do not, and in those cases `null` can feel reasonable as a default value. However, to allow the type-system to understand your code, you need to explicitly set `ContextShape | null` on the `createContext`.
+הטכניקה הזו עובדת כשיש לך ערך ברירת מחדל שזה הגיוני - אבל לפעמים יש מקרים שבהם אין לך, ובמקרים האלה `null` יכול להרגיש הגיוני כערך ברירת מחדל. עם זאת, כדי לאפשר למערכת הטיפוסים להבין את הקוד שלך, עליך להגדיר במפורש `ContextShape | null' ב-'createContext'.
-This causes the issue that you need to eliminate the `| null` in the type for context consumers. Our recommendation is to have the Hook do a runtime check for it's existence and throw an error when not present:
+זה גורם לבעיה שאתה צריך כדי לבטל את ה- `| null` בסוג עבור צרכני הקשר. ההמלצה שלנו היא לבקש מה-Hook לבצע בדיקת זמן ריצה לקיומו ולזרוק שגיאה כאשר אינו קיים:
```js {5, 16-20}
import { createContext, useContext, useState, useMemo } from 'react';
@@ -327,9 +327,9 @@ function MyComponent() {
}
```
-### `useMemo` {/*typing-usememo*/}
+### `useMemo` {/*הקלדה-usememo*/}
-The [`useMemo`](/reference/react/useMemo) Hooks will create/re-access a memorized value from a function call, re-running the function only when dependencies passed as the 2nd parameter are changed. The result of calling the Hook is inferred from the return value from the function in the first parameter. You can be more explicit by providing a type argument to the Hook.
+ה-[`useMemo`](/reference/react/useMemo) Hooks ייצרו/ייגשו מחדש לערך שנשנן מקריאה לפונקציה, ויפעילו מחדש את הפונקציה רק כאשר התלות שעברו כפרמטר השני משתנות. התוצאה של קריאת ה-Hook מוסקת מערך ההחזרה מהפונקציה בפרמטר הראשון. אתה יכול להיות מפורש יותר על ידי מתן ארגומנט סוג ל-Hook.
```ts
// The type of visibleTodos is inferred from the return value of filterTodos
@@ -337,9 +337,9 @@ const visibleTodos = useMemo(() => filterTodos(todos, tab), [todos, tab]);
```
-### `useCallback` {/*typing-usecallback*/}
+### `useCallback` {/*הקלדה-usecallback*/}
-The [`useCallback`](/reference/react/useCallback) provide a stable reference to a function as long as the dependencies passed into the second parameter are the same. Like `useMemo`, the function's type is inferred from the return value of the function in the first parameter, and you can be more explicit by providing a type argument to the Hook.
+ה-[`useCallback`](/reference/react/useCallback) מספק הפניה יציבה לפונקציה כל עוד התלות שהועברו לפרמטר השני זהות. כמו `useMemo`, סוג הפונקציה נגזר מערך ההחזרה של הפונקציה בפרמטר הראשון, ותוכל להיות מפורש יותר על ידי מתן ארגומנט type ל-Hook.
```ts
@@ -348,9 +348,9 @@ const handleClick = useCallback(() => {
}, [todos]);
```
-When working in TypeScript strict mode `useCallback` requires adding types for the parameters in your callback. This is because the type of the callback is inferred from the return value of the function, and without parameters the type cannot be fully understood.
+כשעובדים ב-TypeScript מצב קפדני `useCallback` דורש הוספת סוגים עבור הפרמטרים בהתקשרות חזרה. הסיבה לכך היא שסוג ההתקשרות חוזרת מוסק מערך ההחזרה של הפונקציה, וללא פרמטרים לא ניתן להבין את הסוג במלואו.
-Depending on your code-style preferences, you could use the `*EventHandler` functions from the React types to provide the type for the event handler at the same time as defining the callback:
+בהתאם להעדפות סגנון הקוד שלך, תוכל להשתמש בפונקציות `*EventHandler` מסוגי React כדי לספק את הסוג למטפל באירועים במקביל להגדרת ההתקשרות חזרה:
```ts
import { useState, useCallback } from 'react';
@@ -371,13 +371,13 @@ export default function Form() {
}
```
-## Useful Types {/*useful-types*/}
+## סוגים שימושיים {/*סוגים-שימושיים*/}
-There is quite an expansive set of types which come from the `@types/react` package, it is worth a read when you feel comfortable with how React and TypeScript interact. You can find them [in React's folder in DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts). We will cover a few of the more common types here.
+יש קבוצה די נרחבת של טיפוסים שמגיעים מחבילת `@types/react`, כדאי לקרוא כאשר אתה מרגיש בנוח עם האופן שבו React ו-TypeScript מתקשרים. אתה יכול למצוא אותם [בתיקיה של React ב-DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts). נסקור כאן כמה מהסוגים הנפוצים יותר.
-### DOM Events {/*typing-dom-events*/}
+### אירועי DOM {/*טיינג-דום-אירועים*/}
-When working with DOM events in React, the type of the event can often be inferred from the event handler. However, when you want to extract a function to be passed to an event handler, you will need to explicitly set the type of the event.
+כאשר עובדים עם אירועי DOM ב-React, לעתים קרובות ניתן להסיק מהמטפל באירוע את סוג האירוע. עם זאת, כאשר אתה רוצה לחלץ פונקציה שתועבר למטפל באירועים, תצטרך להגדיר במפורש את סוג האירוע.
<Sandpack>
@@ -407,15 +407,15 @@ export default App = AppTSX;
</Sandpack>
-There are many types of events provided in the React types - the full list can be found [here](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/b580df54c0819ec9df62b0835a315dd48b8594a9/types/react/index.d.ts#L1247C1-L1373) which is based on the [most popular events from the DOM](https://developer.mozilla.org/en-US/docs/Web/Events).
+ישנם סוגים רבים של אירועים מסופקים בסוגי React - ניתן למצוא את הרשימה המלאה [כאן](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/b580df54c0819ec9df62b0835a315dd48b8594a9/types/react.4C31/index) שמבוססת על [האירועים הפופולריים ביותר מה-DOM](https://developer.mozilla.org/en-US/docs/Web/Events).
-When determining the type you are looking for you can first look at the hover information for the event handler you are using, which will show the type of the event.
+בעת קביעת הסוג שאתה מחפש אתה יכול קודם כל להסתכל על מידע הרחף עבור מטפל האירוע שבו אתה משתמש, אשר יציג את סוג האירוע.
-If you need to use an event that is not included in this list, you can use the `React.SyntheticEvent` type, which is the base type for all events.
+אם אתה צריך להשתמש באירוע שאינו כלול ברשימה זו, אתה יכול להשתמש בסוג `React.SyntheticEvent`, שהוא סוג הבסיס לכל האירועים.
-### Children {/*typing-children*/}
+### ילדים {/*הקלדה-ילדים*/}
-There are two common paths to describing the children of a component. The first is to use the `React.ReactNode` type, which is a union of all the possible types that can be passed as children in JSX:
+ישנם שני נתיבים נפוצים לתיאור הילדים של רכיב. הראשון הוא להשתמש בסוג `React.ReactNode`, שהוא איחוד של כל הסוגים האפשריים שניתן להעביר כילדים ב-JSX:
```ts
interface ModalRendererProps {
@@ -424,7 +424,7 @@ interface ModalRendererProps {
}
```
-This is a very broad definition of children. The second is to use the `React.ReactElement` type, which is only JSX elements and not JavaScript primitives like strings or numbers:
+זוהי הגדרה מאוד רחבה של ילדים. השני הוא להשתמש בסוג 'React.ReactElement', שהוא רק רכיבי JSX ולא פרימיטיביים של JavaScript כמו מחרוזות או מספרים:
```ts
interface ModalRendererProps {
@@ -433,13 +433,13 @@ interface ModalRendererProps {
}
```
-Note, that you cannot use TypeScript to describe that the children are a certain type of JSX elements, so you cannot use the type-system to describe a component which only accepts `<li>` children.
+שימו לב, אינכם יכולים להשתמש ב-TypeScript כדי לתאר שהילדים הם סוג מסוים של רכיבי JSX, ולכן אינכם יכולים להשתמש במערכת-type כדי לתאר רכיב שמקבל רק ילדים ``<li>``.
-You can see all an example of both `React.ReactNode` and `React.ReactElement` with the type-checker in [this TypeScript playground](https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgIilQ3wChSB6CxYmAOmXRgDkIATJOdNJMGAZzgwAFpxAR+8YADswAVwGkZMJFEzpOjDKw4AFHGEEBvUnDhphwADZsi0gFw0mDWjqQBuUgF9yaCNMlENzgAXjgACjADfkctFnYkfQhDAEpQgD44AB42YAA3dKMo5P46C2tbJGkvLIpcgt9-QLi3AEEwMFCItJDMrPTTbIQ3dKywdIB5aU4kKyQQKpha8drhhIGzLLWODbNs3b3s8YAxKBQAcwXpAThMaGWDvbH0gFloGbmrgQfBzYpd1YjQZbEYARkB6zMwO2SHSAAlZlYIBCdtCRkZpHIrFYahQYQD8UYYFA5EhcfjyGYqHAXnJAsIUHlOOUbHYhMIIHJzsI0Qk4P9SLUBuRqXEXEwAKKfRZcNA8PiCfxWACecAAUgBlAAacFm80W-CU11U6h4TgwUv11yShjgJjMLMqDnN9Dilq+nh8pD8AXgCHdMrCkWisVoAet0R6fXqhWKhjKllZVVxMcavpd4Zg7U6Qaj+2hmdG4zeRF10uu-Aeq0LBfLMEe-V+T2L7zLVu+FBWLdLeq+lc7DYFf39deFVOotMCACNOCh1dq219a+30uC8YWoZsRyuEdjkevR8uvoVMdjyTWt4WiSSydXD4NqZP4AymeZE072ZzuUeZQKheQgA).
+אתה יכול לראות את כל הדוגמאות של 'React.ReactNode' וגם של 'React.ReactElement' עם בודק הסוג ב-[This TypeScript מגרש משחקים](https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgIilQ3wChSB 6CxYmAOmXRgDkIATJOdNJMGAZzgwAFpxAR+8YADswAVwGkZMJFEzpOjDKw4AFHGEEBvUnDhphwADZsi0gFw0mDWjqQBuUg F9yaCNMlENzgAXjgACjADfkctFnYkfQhDAEpQgD44AB42YAA3dKMo5P46C2tbJGkvLIpcgt9-QLi3AEEwMFCItJDMrPTTb IQ3dKywdIB5aU4kKyQQKpha8drhhIGzLLWODbNs3b3s8YAxKBQAcwXpAThMaGWDvbH0gFloGbmrgQfBzYpd1YjQZbEYARk B6zMwO2SHSAAlZlYIBCdtCRkZpHIrFYahQYQD8UYYFA5EhcfjyGYqHAXnJAsIUHlOOUbHYhMIIHJzsI0Qk4P9SLUBuRqXE XEwAKKfRZcNA8PiCfxWACEcAAUgBlAAacFm80W-CU11U6h4TgwUv11yShjgJjMLMqDnN9Dilq+nh8pD8AXgCHdMrCkWisV oAet0R6fXqhWKhjKllZVVxMcavpd4Zg7U6Qaj+2hmdG4zeRF10uu-Aeq0LBfLMEe-V+T2L7zLVu+FBWLdLeq+lc7DYFf39 deFVOotMCACNOCh1dq219a+30uC8YWoZsRyuEdjkevR8uvoVMdjyTWt4WiSSydXD4NqZP4AymeZE072ZzuUeZQKheQgA).
-### Style Props {/*typing-style-props*/}
+### props סגנון {/*הקלדה-סגנון-props*/}
-When using inline styles in React, you can use `React.CSSProperties` to describe the object passed to the `style` prop. This type is a union of all the possible CSS properties, and is a good way to ensure you are passing valid CSS properties to the `style` prop, and to get auto-complete in your editor.
+בעת שימוש בסגנונות מוטבעים ב-React, אתה יכול להשתמש ב-'React.CSSProperties' כדי לתאר את האובייקט המועבר ל-'סגנון'. סוג זה הוא איחוד של כל מאפייני ה-CSS האפשריים, ומהווה דרך טובה להבטיח שאתה מעביר מאפייני CSS חוקיים ל-'סגנון', ולהשלמת השלמה אוטומטית בעורך שלך.
```ts
interface MyComponentProps {
@@ -447,17 +447,18 @@ interface MyComponentProps {
}
```
-## Further learning {/*further-learning*/}
+## למידה נוספת {/*למידה-נוספת*/}
-This guide has covered the basics of using TypeScript with React, but there is a lot more to learn.
-Individual API pages on the docs may contain more in-depth documentation on how to use them with TypeScript.
+מדריך זה כיסה את היסודות של השימוש ב-TypeScript עם React, אבל יש עוד הרבה מה ללמוד.
+דפי API בודדים במסמכים עשויים להכיל תיעוד מעמיק יותר כיצד להשתמש בהם עם TypeScript.
-We recommend the following resources:
+אנו ממליצים על המשאבים הבאים:
- - [The TypeScript handbook](https://www.typescriptlang.org/docs/handbook/) is the official documentation for TypeScript, and covers most key language features.
+ - [המדריך של TypeScript](https://www.typescriptlang.org/docs/handbook/) הוא התיעוד הרשמי של TypeScript, ומכסה את רוב תכונות השפה העיקריות.
- - [The TypeScript release notes](https://devblogs.microsoft.com/typescript/) covers a each new features in-depth.
+ - [הערות השחרור של TypeScript](https://devblogs.microsoft.com/typescript/) מכסים כל תכונות חדשות לעומק.
- - [React TypeScript Cheatsheet](https://react-typescript-cheatsheet.netlify.app/) is a community-maintained cheatsheet for using TypeScript with React, covering a lot of useful edge cases and providing more breadth than this document.
+ - [React TypeScript Cheatsheet](https://react-typescript-cheatsheet.netlify.app/) הוא דף צ'יטים המתוחזק על ידי קהילה לשימוש ב-TypeScript עם React, המכסה הרבה מקרי קצה שימושיים ומספק רוחב רחבה יותר מהמסמך הזה.
+
+ - [TypeScript Community Discord](https://discord.com/invite/typescript) הוא מקום מצוין לשאול שאלות ולקבל עזרה עם בעיות TypeScript ו-React.
- - [TypeScript Community Discord](https://discord.com/invite/typescript) is a great place to ask questions and get help with TypeScript and React issues.
diff --git a/src/content/learn/understanding-your-ui-as-a-tree.md b/src/content/learn/understanding-your-ui-as-a-tree.md
index 2abf7affc..e56ceb0ca 100644
--- a/src/content/learn/understanding-your-ui-as-a-tree.md
+++ b/src/content/learn/understanding-your-ui-as-a-tree.md
@@ -1,41 +1,41 @@
---
-title: Understanding Your UI as a Tree
+title: "ה-UI שלכם כעץ"
---
<Intro>
-Your React app is taking shape with many components being nested within each other. How does React keep track of your app's component structure?
+אפליקציית React שלך מתעצבת כאשר רכיבים רבים מקוננים זה בזה. איך React עוקב אחר מבנה הרכיבים של האפליקציה שלך?
-React, and many other UI libraries, model UI as a tree. Thinking of your app as a tree is useful for understanding the relationship between components. This understanding will help you debug future concepts like performance and state management.
+React, וספריות UI רבות אחרות, מדגמים את UI כעץ. חשיבה על האפליקציה שלך כעל עץ שימושית להבנת הקשר בין רכיבים. הבנה זו תעזור לך לנפות באגים במושגים עתידיים כמו ביצועים וניהול state.
</Intro>
<YouWillLearn>
-* How React "sees" component structures
-* What a render tree is and what it is useful for
-* What a module dependency tree is and what it is useful for
+* How React "רואה" מבנים של רכיבים
+* מהו עץ טיוח ולמה הוא שימושי
+* מהו עץ תלות מודול ולמה הוא שימושי
</YouWillLearn>
-## Your UI as a tree {/*your-ui-as-a-tree*/}
+## ממשק המשתמש שלך כעץ {/*הממשק-שלך-כעץ*/}
-Trees are a relationship model between items and UI is often represented using tree structures. For example, browsers use tree structures to model HTML ([DOM](https://developer.mozilla.org/docs/Web/API/Document_Object_Model/Introduction)) and CSS ([CSSOM](https://developer.mozilla.org/docs/Web/API/CSS_Object_Model)). Mobile platforms also use trees to represent their view hierarchy.
+עצים הם מודל קשר בין פריטים וממשק המשתמש מיוצג לרוב באמצעות מבני עצים. לדוגמה, דפדפנים משתמשים במבני עץ למודל HTML ([DOM](https://developer.mozilla.org/docs/Web/API/Document_Object_Model/Introduction)) ו-CSS ([CSSOM](https://developer.mozilla.org/docs/Web/API/CSS_Object_Model)). פלטפורמות ניידות משתמשות גם בעצים כדי לייצג את היררכיית התצוגה שלהן.
<Diagram name="preserving_state_dom_tree" height={193} width={864} alt="Diagram with three sections arranged horizontally. In the first section, there are three rectangles stacked vertically, with labels 'Component A', 'Component B', and 'Component C'. Transitioning to the next pane is an arrow with the React logo on top labeled 'React'. The middle section contains a tree of components, with the root labeled 'A' and two children labeled 'B' and 'C'. The next section is again transitioned using an arrow with the React logo on top labeled 'React DOM'. The third and final section is a wireframe of a browser, containing a tree of 8 nodes, which has only a subset highlighted (indicating the subtree from the middle section).">
-React creates a UI tree from your components. In this example, the UI tree is then used to render to the DOM.
+React יוצר עץ ממשק משתמש מהרכיבים שלך. בדוגמה זו, עץ ה-UI משמש לאחר מכן לעיבוד ל-DOM.
</Diagram>
-Like browsers and mobile platforms, React also uses tree structures to manage and model the relationship between components in a React app. These trees are useful tools to understand how data flows through a React app and how to optimize rendering and app size.
+כמו דפדפנים ופלטפורמות ניידות, גם React משתמשת במבני עצים כדי לנהל ולדגמן את הקשר בין רכיבים באפליקציית React. עצים אלו הם כלים שימושיים כדי להבין כיצד נתונים זורמים דרך אפליקציית React וכיצד לייעל את העיבוד ואת גודל האפליקציה.
## The Render Tree {/*the-render-tree*/}
-A major feature of components is the ability to compose components of other components. As we [nest components](/learn/your-first-component#nesting-and-organizing-components), we have the concept of parent and child components, where each parent component may itself be a child of another component.
+תכונה עיקרית של רכיבים היא היכולת להרכיב רכיבים של רכיבים אחרים. כפי שאנו [רכיבי הקן](/learn/your-first-component#nesting-and-organizing-components), יש לנו את הרעיון של רכיבי אב וילד, שבו כל רכיב הורה עשוי להיות בעצמו ילד של רכיב אחר.
-When we render a React app, we can model this relationship in a tree, known as the render tree.
+כאשר אנו מעבדים אפליקציית React, אנו יכולים לדגמן את הקשר הזה בעץ, המכונה עץ העיבוד.
-Here is a React app that renders inspirational quotes.
+הנה אפליקציית React שמציגה ציטוטים מעוררי השראה.
<Sandpack>
@@ -120,32 +120,32 @@ export default [
<Diagram name="render_tree" height={250} width={500} alt="Tree graph with five nodes. Each node represents a component. The root of the tree is App, with two arrows extending from it to 'InspirationGenerator' and 'FancyText'. The arrows are labelled with the word 'renders'. 'InspirationGenerator' node also has two arrows pointing to nodes 'FancyText' and 'Copyright'.">
-React creates a *render tree*, a UI tree, composed of the rendered components.
+React יוצר *עץ רינדור*, עץ ממשק משתמש, המורכב מהרכיבים המעובדים.
</Diagram>
-From the example app, we can construct the above render tree.
+מהאפליקציה לדוגמה, נוכל לבנות את עץ הרינדור לעיל.
-The tree is composed of nodes, each of which represents a component. `App`, `FancyText`, `Copyright`, to name a few, are all nodes in our tree.
+העץ מורכב מצמתים, שכל אחד מהם מייצג רכיב. `אפליקציה`, `FancyText`, `זכויות יוצרים`, אם להזכיר כמה, הם כולם צמתים בעץ שלנו.
-The root node in a React render tree is the [root component](/learn/importing-and-exporting-components#the-root-component-file) of the app. In this case, the root component is `App` and it is the first component React renders. Each arrow in the tree points from a parent component to a child component.
+צומת השורש בעץ רינדור React הוא [רכיב השורש](/learn/importing-and-exporting-components#the-root-component-file) של האפליקציה. במקרה זה, רכיב השורש הוא 'אפליקציה' וזהו הרכיב הראשון ש-React מעבד. כל חץ בעץ מצביע מרכיב אב לרכיב צאצא.
<DeepDive>
-#### Where are the HTML tags in the render tree? {/*where-are-the-html-elements-in-the-render-tree*/}
+#### היכן נמצאים תגי ה-HTML בעץ הרינדור? {/*היכן-ה-html-elements-in-the-render-tree*/}
-You'll notice in the above render tree, there is no mention of the HTML tags that each component renders. This is because the render tree is only composed of React [components](learn/your-first-component#components-ui-building-blocks).
+תבחין בעץ הרינדור לעיל, אין אזכור לתגיות HTML שכל רכיב מעבד. הסיבה לכך היא שעץ הרינדור מורכב רק מ-React [רכיבים](למד/הרכיב-הראשון שלך#רכיבי-UI-אבני-בניין).
-React, as a UI framework, is platform agnostic. On react.dev, we showcase examples that render to the web, which uses HTML markup as its UI primitives. But a React app could just as likely render to a mobile or desktop platform, which may use different UI primitives like [UIView](https://developer.apple.com/documentation/uikit/uiview) or [FrameworkElement](https://learn.microsoft.com/en-us/dotnet/api/system.windows.frameworkelement?view=windowsdesktop-7.0).
+React, כמסגרת ממשק משתמש, היא אגנוסטית לפלטפורמה. ב-react.dev, אנו מציגים דוגמאות לעיבוד לאינטרנט, המשתמש בסימון HTML כפרימיטיביות ממשק המשתמש שלו. אבל אפליקציית React יכולה באותה מידה להיות עיבוד לפלטפורמה ניידת או שולחנית, שעשויה להשתמש בפרימיטיבים שונים של ממשק משתמש כמו [UIView](https://developer.apple.com/documentation/uikit/uiview) או [FrameworkElement](https://learn.microsoft.com/en-us/dotnet/api/system.windows.windows-element.desktop=windows.frameworkelement.de?hl=iw).
-These platform UI primitives are not a part of React. React render trees can provide insight to our React app regardless of what platform your app renders to.
+הפרימיטיבים האלה של ממשק המשתמש של הפלטפורמה אינם חלק מ-React. עצי רינדור React יכולים לספק תובנות לאפליקציית React שלנו ללא קשר לאיזו פלטפורמה האפליקציה שלך מעבדת.
</DeepDive>
-A render tree represents a single render pass of a React application. With [conditional rendering](/learn/conditional-rendering), a parent component may render different children depending on the data passed.
+עץ רינדור מייצג מעבר רינדור בודד של יישום React. עם [עיבוד מותנה](/learn/conditional-rendering), רכיב אב עשוי לעבד ילדים שונים בהתאם לנתונים המועברים.
-We can update the app to conditionally render either an inspirational quote or color.
+אנחנו יכולים לעדכן את האפליקציה כדי להציג ציטוט או צבע בצורה מותנית.
<Sandpack>
@@ -247,54 +247,55 @@ export default [
<Diagram name="conditional_render_tree" height={250} width={561} alt="Tree graph with six nodes. The top node of the tree is labelled 'App' with two arrows extending to nodes labelled 'InspirationGenerator' and 'FancyText'. The arrows are solid lines and are labelled with the word 'renders'. 'InspirationGenerator' node also has three arrows. The arrows to nodes 'FancyText' and 'Color' are dashed and labelled with 'renders?'. The last arrow points to the node labelled 'Copyright' and is solid and labelled with 'renders'.">
-With conditional rendering, across different renders, the render tree may render different components.
+עם עיבוד מותנה, על פני עיבודים שונים, עץ העיבוד עשוי לעבד רכיבים שונים.
</Diagram>
-In this example, depending on what `inspiration.type` is, we may render `<FancyText>` or `<Color>`. The render tree may be different for each render pass.
+בדוגמה זו, בהתאם למה זה `inspiration.type`, אנו עשויים לעבד `<FancyText>` או `<Color>`. עץ העיבוד עשוי להיות שונה עבור כל מעבר עיבוד.
-Although render trees may differ across render passes, these trees are generally helpful for identifying what the *top-level* and *leaf components* are in a React app. Top-level components are the components nearest to the root component and affect the rendering performance of all the components beneath them and often contain the most complexity. Leaf components are near the bottom of the tree and have no child components and are often frequently re-rendered.
+למרות שעצי רינדור עשויים להיות שונים בין מעברי רינדור, עצים אלה מועילים בדרך כלל לזיהוי מה הם *הרמה העליונה* ורכיבי *העלים* באפליקציית React. רכיבים ברמה העליונה הם הרכיבים הקרובים ביותר לרכיב השורש ומשפיעים על ביצועי הרינדור של כל הרכיבים שמתחתיהם ולעיתים מכילים את המורכבות ביותר. רכיבי העלים נמצאים קרוב לתחתית העץ ואין להם רכיבי צאצא ולעתים קרובות הם מעובדים מחדש.
-Identifying these categories of components are useful for understanding data flow and performance of your app.
+זיהוי קטגוריות אלו של רכיבים שימושי להבנת זרימת הנתונים והביצועים של האפליקציה שלך.
## The Module Dependency Tree {/*the-module-dependency-tree*/}
-Another relationship in a React app that can be modeled with a tree are an app's module dependencies. As we [break up our components](/learn/importing-and-exporting-components#exporting-and-importing-a-component) and logic into separate files, we create [JS modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) where we may export components, functions, or constants.
+מערכת יחסים נוספת באפליקציית React שניתן לעצב עם עץ היא התלות במודול של אפליקציה. כאשר אנו [מפרקים את הרכיבים שלנו](/learn/importing-and-exporting-components#exporting-and-importing-a-component) והלוגיקה לקבצים נפרדים, אנו יוצרים [מודולי JS](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) שבהם אנו עשויים, או לייצא רכיבים קבועים, פונקציות.
-Each node in a module dependency tree is a module and each branch represents an `import` statement in that module.
+כל צומת בעץ התלות של מודול הוא מודול וכל ענף מייצג הצהרת 'ייבוא' במודול זה.
-If we take the previous Inspirations app, we can build a module dependency tree, or dependency tree for short.
+אם ניקח את אפליקציית Inspirations הקודמת, נוכל לבנות עץ תלות של מודול, או בקיצור עץ תלות.
<Diagram name="module_dependency_tree" height={250} width={658} alt="A tree graph with seven nodes. Each node is labelled with a module name. The top level node of the tree is labelled 'App.js'. There are three arrows pointing to the modules 'InspirationGenerator.js', 'FancyText.js' and 'Copyright.js' and the arrows are labelled with 'imports'. From the 'InspirationGenerator.js' node, there are three arrows that extend to three modules: 'FancyText.js', 'Color.js', and 'inspirations.js'. The arrows are labelled with 'imports'.">
-The module dependency tree for the Inspirations app.
+עץ התלות במודול עבור אפליקציית Inspirations.
</Diagram>
-The root node of the tree is the root module, also known as the entrypoint file. It often is the module that contains the root component.
+צומת השורש של העץ הוא מודול השורש, הידוע גם כקובץ נקודת הכניסה. לעתים קרובות זה המודול שמכיל את רכיב השורש.
-Comparing to the render tree of the same app, there are similar structures but some notable differences:
+בהשוואה לעץ הרינדור של אותה אפליקציה, ישנם מבנים דומים אך כמה הבדלים בולטים:
-* The nodes that make-up the tree represent modules, not components.
-* Non-component modules, like `inspirations.js`, are also represented in this tree. The render tree only encapsulates components.
-* `Copyright.js` appears under `App.js` but in the render tree, `Copyright`, the component, appears as a child of `InspirationGenerator`. This is because `InspirationGenerator` accepts JSX as [children props](/learn/passing-props-to-a-component#passing-jsx-as-children), so it renders `Copyright` as a child component but does not import the module.
+* הצמתים המרכיבים את העץ מייצגים מודולים, לא רכיבים.
+* מודולים שאינם רכיבים, כמו `inspirations.js`, מיוצגים גם הם בעץ זה. עץ העיבוד מקפל רק רכיבים.
+* `Copyright.js` מופיע תחת `App.js` אך בעץ הרינדור, `Copyright`, הרכיב, מופיע כצאצא של `InspirationGenerator`. הסיבה לכך היא ש-'InspirationGenerator' מקבל את JSX כ-[children props](/learn/passing-props-to-a-component#passing-jsx-as-children), אז הוא הופך את 'זכויות יוצרים' כרכיב צאצא אך אינו מייבא את המודול.
-Dependency trees are useful to determine what modules are necessary to run your React app. When building a React app for production, there is typically a build step that will bundle all the necessary JavaScript to ship to the client. The tool responsible for this is called a [bundler](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview#the_modern_tooling_ecosystem), and bundlers will use the dependency tree to determine what modules should be included.
+עצי תלות שימושיים כדי לקבוע אילו מודולים נחוצים להפעלת אפליקציית React שלך. כאשר בונים אפליקציית React לייצור, יש בדרך כלל שלב בנייה שיצרף את כל ה-JavaScript הדרוש למשלוח ללקוח. הכלי שאחראי לכך נקרא [bundler](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview#the_modern_tooling_ecosystem), ו-bunlers ישתמשו בעץ התלות כדי לקבוע אילו מודולים יש לכלול.
-As your app grows, often the bundle size does too. Large bundle sizes are expensive for a client to download and run. Large bundle sizes can delay the time for your UI to get drawn. Getting a sense of your app's dependency tree may help with debugging these issues.
+ככל שהאפליקציה שלך גדלה, לעתים קרובות גם גודל החבילה עושה זאת. גדלי חבילות גדולים יקרים ללקוח להוריד ולהפעיל. גדלים גדולים של חבילות יכולים לעכב את זמן הציור של ממשק המשתמש שלך. קבלת תחושה של עץ התלות של האפליקציה שלך עשויה לעזור באיתור בעיות אלו.
-[comment]: <> (perhaps we should also deep dive on conditional imports)
+[הערה]: <> (אולי עלינו לצלול לעומק גם ביבוא מותנה)
<Recap>
-* Trees are a common way to represent the relationship between entities. They are often used to model UI.
-* Render trees represent the nested relationship between React components across a single render.
-* With conditional rendering, the render tree may change across different renders. With different prop values, components may render different children components.
-* Render trees help identify what the top-level and leaf components are. Top-level components affect the rendering performance of all components beneath them and leaf components are often re-rendered frequently. Identifying them is useful for understanding and debugging rendering performance.
-* Dependency trees represent the module dependencies in a React app.
-* Dependency trees are used by build tools to bundle the necessary code to ship an app.
-* Dependency trees are useful for debugging large bundle sizes that slow time to paint and expose opportunities for optimizing what code is bundled.
+* עצים הם דרך נפוצה לייצג את היחסים בין ישויות. הם משמשים לעתים קרובות למודל ממשק משתמש.
+* עצי רינדור מייצגים את הקשר המקנן בין רכיבי React על פני רינדור בודד.
+* עם עיבוד מותנה, עץ העיבוד עשוי להשתנות בין עיבודים שונים. עם ערכי אב שונים, רכיבים עשויים להציג רכיבי ילדים שונים.
+* עצי עיבוד עוזרים לזהות מהם הרכיבים ברמה העליונה והעלים. רכיבים ברמה העליונה משפיעים על ביצועי הרינדור של כל הרכיבים שמתחתיהם ורכיבי עלים מעובדים לעתים קרובות מחדש. זיהוים שימושי להבנת ביצועי רינדור וניפוי באגים.
+* עצי תלות מייצגים את התלות במודול באפליקציית React.
+* עצי תלות משמשים כלי בנייה כדי לאגד את הקוד הדרוש למשלוח אפליקציה.
+* עצי תלות שימושיים לאיתור באגים בגדלים גדולים של חבילות שמאטות את זמן הצביעה וחושפים הזדמנויות לאופטימיזציה של הקוד שמצורף.
</Recap>
-[TODO]: <> (Add challenges)
+[TODO]: <> (הוסף אתגרים)
+
diff --git a/src/content/learn/updating-arrays-in-state.md b/src/content/learn/updating-arrays-in-state.md
index 61e4f4e2d..e188fb3ca 100644
--- a/src/content/learn/updating-arrays-in-state.md
+++ b/src/content/learn/updating-arrays-in-state.md
@@ -1,5 +1,5 @@
---
-title: Updating Arrays in State
+title: עדכון מערכים ב-State
---
<Intro>
@@ -1970,3 +1970,4 @@ With Immer, you can pick the style that feels the most natural for each separate
</Solution>
</Challenges>
+
diff --git a/src/content/learn/updating-objects-in-state.md b/src/content/learn/updating-objects-in-state.md
index 923e4e181..ce4d3ef56 100644
--- a/src/content/learn/updating-objects-in-state.md
+++ b/src/content/learn/updating-objects-in-state.md
@@ -1,5 +1,5 @@
---
-title: Updating Objects in State
+title: עדכון אובייקטים ב-State
---
<Intro>
@@ -441,7 +441,7 @@ input { margin-left: 5px; margin-bottom: 5px; }
</Sandpack>
-Here, `e.target.name` refers to the `name` property given to the `<input>` DOM element.
+Here, `e.target.name` refers to the `name` property given to the ``<input>`` DOM element.
</DeepDive>
@@ -1622,3 +1622,4 @@ select { margin-bottom: 10px; }
</Solution>
</Challenges>
+
diff --git a/src/content/learn/writing-markup-with-jsx.md b/src/content/learn/writing-markup-with-jsx.md
index 62670150a..3a8cb7b2c 100644
--- a/src/content/learn/writing-markup-with-jsx.md
+++ b/src/content/learn/writing-markup-with-jsx.md
@@ -1,5 +1,5 @@
---
-title: Writing Markup with JSX
+title: כתיבת Markup עם JSX
---
<Intro>
@@ -136,7 +136,7 @@ Most of the time, React's on-screen error messages will help you find where the
To return multiple elements from a component, **wrap them with a single parent tag.**
-For example, you can use a `<div>`:
+For example, you can use a ``<div>``:
```js {1,11}
<div>
@@ -153,7 +153,7 @@ For example, you can use a `<div>`:
```
-If you don't want to add an extra `<div>` to your markup, you can write `<>` and `</>` instead:
+If you don't want to add an extra ``<div>`` to your markup, you can write `<>` and `</>` instead:
```js {1,11}
<>
@@ -181,7 +181,7 @@ JSX looks like HTML, but under the hood it is transformed into plain JavaScript
### 2. Close all the tags {/*2-close-all-the-tags*/}
-JSX requires tags to be explicitly closed: self-closing tags like `<img>` must become `<img />`, and wrapping tags like `<li>oranges` must be written as `<li>oranges</li>`.
+JSX requires tags to be explicitly closed: self-closing tags like ``<img>`` must become `<img />`, and wrapping tags like ``<li>`oranges` must be written as ``<li>`oranges`</li>``.
This is how Hedy Lamarr's image and list items look closed:
@@ -351,3 +351,4 @@ export default function Bio() {
</Solution>
</Challenges>
+
diff --git a/src/content/learn/you-might-not-need-an-effect.md b/src/content/learn/you-might-not-need-an-effect.md
index 66cdc3117..64396c1f2 100644
--- a/src/content/learn/you-might-not-need-an-effect.md
+++ b/src/content/learn/you-might-not-need-an-effect.md
@@ -1,5 +1,5 @@
---
-title: 'You Might Not Need an Effect'
+title: אולי לא צריך Effect
---
<Intro>
@@ -1736,3 +1736,4 @@ Notice how in this version, only _submitting the form_ (which is an event) cause
</Solution>
</Challenges>
+
diff --git a/src/content/learn/your-first-component.md b/src/content/learn/your-first-component.md
index 17fa01e98..e4e9deda2 100644
--- a/src/content/learn/your-first-component.md
+++ b/src/content/learn/your-first-component.md
@@ -1,5 +1,5 @@
---
-title: Your First Component
+title: הקומפוננטה הראשונה שלכם
---
<Intro>
@@ -18,7 +18,7 @@ title: Your First Component
## Components: UI building blocks {/*components-ui-building-blocks*/}
-On the Web, HTML lets us create rich structured documents with its built-in set of tags like `<h1>` and `<li>`:
+On the Web, HTML lets us create rich structured documents with its built-in set of tags like ``<h1>`` and ``<li>``:
```html
<article>
@@ -31,9 +31,9 @@ On the Web, HTML lets us create rich structured documents with its built-in set
</article>
```
-This markup represents this article `<article>`, its heading `<h1>`, and an (abbreviated) table of contents as an ordered list `<ol>`. Markup like this, combined with CSS for style, and JavaScript for interactivity, lies behind every sidebar, avatar, modal, dropdown—every piece of UI you see on the Web.
+This markup represents this article `<article>`, its heading ``<h1>``, and an (abbreviated) table of contents as an ordered list ``<ol>``. Markup like this, combined with CSS for style, and JavaScript for interactivity, lies behind every sidebar, avatar, modal, dropdown—every piece of UI you see on the Web.
-React lets you combine your markup, CSS, and JavaScript into custom "components", **reusable UI elements for your app.** The table of contents code you saw above could be turned into a `<TableOfContents />` component you could render on every page. Under the hood, it still uses the same HTML tags like `<article>`, `<h1>`, etc.
+React lets you combine your markup, CSS, and JavaScript into custom "components", **reusable UI elements for your app.** The table of contents code you saw above could be turned into a `<TableOfContents />` component you could render on every page. Under the hood, it still uses the same HTML tags like `<article>`, ``<h1>``, etc.
Just like with HTML tags, you can compose, order and nest components to design whole pages. For example, the documentation page you're reading is made out of React components:
@@ -156,7 +156,7 @@ img { margin: 0 10px 10px 0; height: 90px; }
Notice the difference in casing:
-* `<section>` is lowercase, so React knows we refer to an HTML tag.
+* ``<section>`` is lowercase, so React knows we refer to an HTML tag.
* `<Profile />` starts with a capital `P`, so React knows that we want to use our component called `Profile`.
And `Profile` contains even more HTML: `<img />`. In the end, this is what the browser sees:
@@ -431,7 +431,7 @@ img { margin: 0 10px 10px 0; }
#### Your own component {/*your-own-component*/}
-Write a component from scratch. You can give it any valid name and return any markup. If you're out of ideas, you can write a `Congratulations` component that shows `<h1>Good job!</h1>`. Don't forget to export it!
+Write a component from scratch. You can give it any valid name and return any markup. If you're out of ideas, you can write a `Congratulations` component that shows ``<h1>`Good job!`</h1>``. Don't forget to export it!
<Sandpack>
@@ -459,3 +459,4 @@ export default function Congratulations() {
</Solution>
</Challenges>
+
diff --git a/src/content/reference/react-dom/client/index.md b/src/content/reference/react-dom/client/index.md
index 89f48212f..1a33e253b 100644
--- a/src/content/reference/react-dom/client/index.md
+++ b/src/content/reference/react-dom/client/index.md
@@ -4,7 +4,7 @@ title: Client React DOM APIs
<Intro>
-The `react-dom/client` APIs let you render React components on the client (in the browser). These APIs are typically used at the top level of your app to initialize your React tree. A [framework](/learn/start-a-new-react-project#production-grade-react-frameworks) may call them for you. Most of your components don't need to import or use them.
+ה-APIs של `react-dom/client` מאפשרים לרנדר קומפוננטות React בצד לקוח (בדפדפן). בדרך כלל משתמשים ב-APIs האלה ברמה העליונה של האפליקציה כדי לאתחל את עץ ה-React. [Framework](/learn/start-a-new-react-project#production-grade-react-frameworks) יכול לקרוא להם עבורכם. רוב הקומפוננטות שלכם לא צריכות לייבא או להשתמש בהם.
</Intro>
@@ -12,11 +12,11 @@ The `react-dom/client` APIs let you render React components on the client (in th
## Client APIs {/*client-apis*/}
-* [`createRoot`](/reference/react-dom/client/createRoot) lets you create a root to display React components inside a browser DOM node.
-* [`hydrateRoot`](/reference/react-dom/client/hydrateRoot) lets you display React components inside a browser DOM node whose HTML content was previously generated by [`react-dom/server`.](/reference/react-dom/server)
+* [`createRoot`](/reference/react-dom/client/createRoot) מאפשר ליצור root להצגת קומפוננטות React בתוך DOM node בדפדפן.
+* [`hydrateRoot`](/reference/react-dom/client/hydrateRoot) מאפשר להציג קומפוננטות React בתוך DOM node בדפדפן, כאשר תוכן ה-HTML שלו נוצר קודם על ידי [`react-dom/server`.](/reference/react-dom/server)
---
-## Browser support {/*browser-support*/}
+## תמיכה בדפדפנים {/*browser-support*/}
-React supports all popular browsers, including Internet Explorer 9 and above. Some polyfills are required for older browsers such as IE 9 and IE 10.
\ No newline at end of file
+React תומכת בכל הדפדפנים הנפוצים, כולל Internet Explorer 9 ומעלה. עבור דפדפנים ישנים יותר כמו IE 9 ו-IE 10 נדרשים polyfills מסוימים.
diff --git a/src/content/reference/react-dom/components/index.md b/src/content/reference/react-dom/components/index.md
index c9b355c84..f949f0cf3 100644
--- a/src/content/reference/react-dom/components/index.md
+++ b/src/content/reference/react-dom/components/index.md
@@ -4,37 +4,37 @@ title: "React DOM Components"
<Intro>
-React supports all of the browser built-in [HTML](https://developer.mozilla.org/en-US/docs/Web/HTML/Element) and [SVG](https://developer.mozilla.org/en-US/docs/Web/SVG/Element) components.
+React תומכת בכל רכיבי הדפדפן המובנים של [HTML](https://developer.mozilla.org/en-US/docs/Web/HTML/Element) ושל [SVG](https://developer.mozilla.org/en-US/docs/Web/SVG/Element).
</Intro>
---
-## Common components {/*common-components*/}
+## רכיבים נפוצים {/*common-components*/}
-All of the built-in browser components support some props and events.
+כל רכיבי הדפדפן המובנים תומכים בחלק מה-props ובאירועים.
-* [Common components (e.g. `<div>`)](/reference/react-dom/components/common)
+* [רכיבים נפוצים (למשל `<div>`)](/reference/react-dom/components/common)
-This includes React-specific props like `ref` and `dangerouslySetInnerHTML`.
+זה כולל גם props ייחודיים ל-React כמו `ref` ו-`dangerouslySetInnerHTML`.
---
-## Form components {/*form-components*/}
+## רכיבי טפסים {/*form-components*/}
-These built-in browser components accept user input:
+רכיבי הדפדפן המובנים הבאים מקבלים קלט מהמשתמש:
* [`<input>`](/reference/react-dom/components/input)
* [`<select>`](/reference/react-dom/components/select)
* [`<textarea>`](/reference/react-dom/components/textarea)
-They are special in React because passing the `value` prop to them makes them *[controlled.](/reference/react-dom/components/input#controlling-an-input-with-a-state-variable)*
+הם מיוחדים ב-React כי העברת prop בשם `value` אליהם הופכת אותם ל-* [controlled.](/reference/react-dom/components/input#controlling-an-input-with-a-state-variable)*
---
-## Resource and Metadata Components {/*resource-and-metadata-components*/}
+## רכיבי משאבים ומטא-דאטה {/*resource-and-metadata-components*/}
-These bulit-in browser components let you load external resources or annotate the document with metadata:
+רכיבי הדפדפן המובנים האלה מאפשרים לטעון משאבים חיצוניים או להוסיף מטא-דאטה למסמך:
* [`<link>`](/reference/react-dom/components/link)
* [`<meta>`](/reference/react-dom/components/meta)
@@ -42,13 +42,13 @@ These bulit-in browser components let you load external resources or annotate th
* [`<style>`](/reference/react-dom/components/style)
* [`<title>`](/reference/react-dom/components/title)
-They are special in React because React can render them into the document head, suspend while resources are loading, and enact other behaviors that are described on the reference page for each specific component.
+הם מיוחדים ב-React כי React יכולה לרנדר אותם ל-head של המסמך, לבצע suspend בזמן טעינת משאבים, ולהפעיל התנהגויות נוספות שמתוארות בדף ה-reference של כל רכיב.
---
-## All HTML components {/*all-html-components*/}
+## כל רכיבי ה-HTML {/*all-html-components*/}
-React supports all built-in browser HTML components. This includes:
+React תומכת בכל רכיבי ה-HTML המובנים של הדפדפן. הרשימה כוללת:
* [`<aside>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/aside)
* [`<audio>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio)
@@ -154,38 +154,38 @@ React supports all built-in browser HTML components. This includes:
<Note>
-Similar to the [DOM standard,](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) React uses a `camelCase` convention for prop names. For example, you'll write `tabIndex` instead of `tabindex`. You can convert existing HTML to JSX with an [online converter.](https://transform.tools/html-to-jsx)
+בדומה ל-[תקן DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model), ב-React משתמשים בקונבנציה של `camelCase` לשמות props. לדוגמה, תכתבו `tabIndex` במקום `tabindex`. אפשר להמיר HTML קיים ל-JSX באמצעות [ממיר אונליין](https://transform.tools/html-to-jsx).
</Note>
---
-### Custom HTML elements {/*custom-html-elements*/}
+### אלמנטים מותאמים אישית של HTML {/*custom-html-elements*/}
-If you render a tag with a dash, like `<my-element>`, React will assume you want to render a [custom HTML element.](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements) In React, rendering custom elements works differently from rendering built-in browser tags:
+אם תרנדרו תגית עם מקף, כמו `<my-element>`, React תניח שאתם רוצים לרנדר [custom HTML element](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements). ב-React רינדור אלמנטים מותאמים אישית עובד אחרת מרינדור תגיות דפדפן מובנות:
-- All custom element props are serialized to strings and are always set using attributes.
-- Custom elements accept `class` rather than `className`, and `for` rather than `htmlFor`.
+- כל props של custom elements עוברים serialization למחרוזות ותמיד נקבעים באמצעות attributes.
+- custom elements מקבלים `class` במקום `className`, ו-`for` במקום `htmlFor`.
-If you render a built-in browser HTML element with an [`is`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/is) attribute, it will also be treated as a custom element.
+אם תרנדרו אלמנט HTML מובנה עם attribute בשם [`is`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/is), הוא יטופל גם הוא כ-custom element.
<Note>
-[A future version of React will include more comprehensive support for custom elements.](https://github.com/facebook/react/issues/11347#issuecomment-1122275286)
+[גרסה עתידית של React תכלול תמיכה רחבה יותר ב-custom elements.](https://github.com/facebook/react/issues/11347#issuecomment-1122275286)
-You can try it by upgrading React packages to the most recent experimental version:
+אפשר לנסות זאת על ידי שדרוג חבילות React לגרסה הניסיונית האחרונה:
- `react@experimental`
- `react-dom@experimental`
-Experimental versions of React may contain bugs. Don't use them in production.
+גרסאות ניסיוניות של React עשויות להכיל באגים. אל תשתמשו בהן בפרודקשן.
</Note>
---
-## All SVG components {/*all-svg-components*/}
+## כל רכיבי ה-SVG {/*all-svg-components*/}
-React supports all built-in browser SVG components. This includes:
+React תומכת בכל רכיבי ה-SVG המובנים של הדפדפן. הרשימה כוללת:
* [`<a>`](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/a)
* [`<animate>`](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/animate)
@@ -256,20 +256,20 @@ React supports all built-in browser SVG components. This includes:
<Note>
-Similar to the [DOM standard,](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) React uses a `camelCase` convention for prop names. For example, you'll write `tabIndex` instead of `tabindex`. You can convert existing SVG to JSX with an [online converter.](https://transform.tools/)
-
-Namespaced attributes also have to be written without the colon:
-
-* `xlink:actuate` becomes `xlinkActuate`.
-* `xlink:arcrole` becomes `xlinkArcrole`.
-* `xlink:href` becomes `xlinkHref`.
-* `xlink:role` becomes `xlinkRole`.
-* `xlink:show` becomes `xlinkShow`.
-* `xlink:title` becomes `xlinkTitle`.
-* `xlink:type` becomes `xlinkType`.
-* `xml:base` becomes `xmlBase`.
-* `xml:lang` becomes `xmlLang`.
-* `xml:space` becomes `xmlSpace`.
-* `xmlns:xlink` becomes `xmlnsXlink`.
+בדומה ל-[תקן DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model), ב-React משתמשים בקונבנציה של `camelCase` לשמות props. לדוגמה, תכתבו `tabIndex` במקום `tabindex`. אפשר להמיר SVG קיים ל-JSX בעזרת [ממיר אונליין](https://transform.tools/).
+
+attributes עם namespace גם חייבים להיכתב בלי נקודתיים:
+
+* `xlink:actuate` הופך ל-`xlinkActuate`.
+* `xlink:arcrole` הופך ל-`xlinkArcrole`.
+* `xlink:href` הופך ל-`xlinkHref`.
+* `xlink:role` הופך ל-`xlinkRole`.
+* `xlink:show` הופך ל-`xlinkShow`.
+* `xlink:title` הופך ל-`xlinkTitle`.
+* `xlink:type` הופך ל-`xlinkType`.
+* `xml:base` הופך ל-`xmlBase`.
+* `xml:lang` הופך ל-`xmlLang`.
+* `xml:space` הופך ל-`xmlSpace`.
+* `xmlns:xlink` הופך ל-`xmlnsXlink`.
</Note>
diff --git a/src/content/reference/react-dom/components/meta.md b/src/content/reference/react-dom/components/meta.md
index 801ca2af1..24f649338 100644
--- a/src/content/reference/react-dom/components/meta.md
+++ b/src/content/reference/react-dom/components/meta.md
@@ -5,14 +5,14 @@ canary: true
<Canary>
-React's extensions to `<meta>` are currently only available in React's canary and experimental channels. In stable releases of React `<meta>` works only as a [built-in browser HTML component](https://react.dev/reference/react-dom/components#all-html-components). Learn more about [React's release channels here](/community/versioning-policy#all-release-channels).
+ההרחבות של React ל-`<meta>` זמינות כרגע רק בערוצי canary ו-experimental של React. בגרסאות יציבות של React, `<meta>` פועל רק כ-[רכיב HTML מובנה של הדפדפן](https://react.dev/reference/react-dom/components#all-html-components). מידע נוסף ב-[ערוצי השחרור של React](/community/versioning-policy#all-release-channels).
</Canary>
<Intro>
-The [built-in browser `<meta>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta) lets you add metadata to the document.
+רכיב הדפדפן המובנה [`<meta>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta) מאפשר להוסיף metadata למסמך.
```js
<meta name="keywords" content="React, JavaScript, semantic markup, html" />
@@ -28,39 +28,39 @@ The [built-in browser `<meta>` component](https://developer.mozilla.org/en-US/do
### `<meta>` {/*meta*/}
-To add document metadata, render the [built-in browser `<meta>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta). You can render `<meta>` from any component and React will always place the corresponding DOM element in the document head.
+כדי להוסיף metadata למסמך, רנדרו את רכיב הדפדפן המובנה [`<meta>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta). אפשר לרנדר `<meta>` מכל קומפוננטה ו-React תמיד תמקם את אלמנט ה-DOM המתאים בתוך ה-document head.
```js
<meta name="keywords" content="React, JavaScript, semantic markup, html" />
```
-[See more examples below.](#usage)
+[ראו דוגמאות נוספות בהמשך.](#usage)
#### Props {/*props*/}
-`<meta>` supports all [common element props.](/reference/react-dom/components/common#props)
+`<meta>` תומך בכל [מאפייני האלמנט הנפוצים.](/reference/react-dom/components/common#props)
-It should have *exactly one* of the following props: `name`, `httpEquiv`, `charset`, `itemProp`. The `<meta>` component does something different depending on which of these props is specified.
+הוא צריך לקבל *בדיוק אחד* מה-props הבאים: `name`, `httpEquiv`, `charset`, `itemProp`. רכיב `<meta>` פועל אחרת בהתאם ל-prop שמצוין.
-* `name`: a string. Specifies the [kind of metadata](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name) to be attached to the document.
-* `charset`: a string. Specifies the character set used by the document. The only valid value is `"utf-8"`.
-* `httpEquiv`: a string. Specifies a directive for processing the document.
-* `itemProp`: a string. Specifies metadata about a particular item within the document rather than the document as a whole.
-* `content`: a string. Specifies the metadata to be attached when used with the `name` or `itemProp` props or the behavior of the directive when used with the `httpEquiv` prop.
+* `name`: מחרוזת. מציינת את [סוג ה-metadata](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name) שיצורף למסמך.
+* `charset`: מחרוזת. מציינת את קידוד התווים של המסמך. הערך התקין היחיד הוא `"utf-8"`.
+* `httpEquiv`: מחרוזת. מציינת directive לעיבוד המסמך.
+* `itemProp`: מחרוזת. מציינת metadata על פריט מסוים בתוך המסמך, ולא על המסמך כולו.
+* `content`: מחרוזת. מציינת את ה-metadata לצירוף כשמשתמשים ב-`name` או `itemProp`, או את התנהגות ה-directive כשמשתמשים ב-`httpEquiv`.
-#### Special rendering behavior {/*special-rendering-behavior*/}
+#### התנהגות רינדור מיוחדת {/*special-rendering-behavior*/}
-React will always place the DOM element corresponding to the `<meta>` component within the document’s `<head>`, regardless of where in the React tree it is rendered. The `<head>` is the only valid place for `<meta>` to exist within the DOM, yet it’s convenient and keeps things composable if a component representing a specific page can render `<meta>` components itself.
+React תמיד תמקם את אלמנט ה-DOM המתאים ל-`<meta>` בתוך `<head>` של המסמך, בלי קשר למקום שבו הוא מרונדר בעץ React. `<head>` הוא המקום החוקי היחיד ל-`<meta>` בתוך ה-DOM, ובכל זאת זה נוח ושומר על קומפוזביליות אם קומפוננטה שמייצגת עמוד מסוים יכולה לרנדר בעצמה רכיבי `<meta>`.
-There is one exception to this: if `<meta>` has an [`itemProp`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemprop) prop, there is no special behavior, because in this case it doesn’t represent metadata about the document but rather metadata about a specific part of the page.
+יש חריג אחד לכך: אם ל-`<meta>` יש prop מסוג [`itemProp`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemprop), אין התנהגות מיוחדת, כי במקרה הזה הוא לא מייצג metadata על המסמך אלא metadata על חלק מסוים של העמוד.
---
-## Usage {/*usage*/}
+## שימוש {/*usage*/}
-### Annotating the document with metadata {/*annotating-the-document-with-metadata*/}
+### הוספת metadata למסמך {/*annotating-the-document-with-metadata*/}
-You can annotate the document with metadata such as keywords, a summary, or the author’s name. React will place this metadata within the document `<head>` regardless of where in the React tree it is rendered.
+אפשר להוסיף למסמך metadata כמו מילות מפתח, תקציר או שם המחבר. React תמקם את ה-metadata הזו בתוך `<head>` של המסמך, בלי קשר למקום שבו הוא מרונדר בעץ React.
```html
<meta name="author" content="John Smith" />
@@ -68,7 +68,7 @@ You can annotate the document with metadata such as keywords, a summary, or the
<meta name="description" content="API reference for the <meta> component in React DOM" />
```
-You can render the `<meta>` component from any component. React will put a `<meta>` DOM node in the document `<head>`.
+אפשר לרנדר את רכיב `<meta>` מכל קומפוננטה. React תשים DOM node של `<meta>` בתוך `<head>` של המסמך.
<SandpackWithHTMLOutput>
@@ -89,9 +89,9 @@ export default function SiteMapPage() {
</SandpackWithHTMLOutput>
-### Annotating specific items within the document with metadata {/*annotating-specific-items-within-the-document-with-metadata*/}
+### הוספת metadata לפריטים ספציפיים במסמך {/*annotating-specific-items-within-the-document-with-metadata*/}
-You can use the `<meta>` component with the `itemProp` prop to annotate specific items within the document with metadata. In this case, React will *not* place these annotations within the document `<head>` but will place them like any other React component.
+אפשר להשתמש ברכיב `<meta>` עם prop מסוג `itemProp` כדי להוסיף metadata לפריטים ספציפיים בתוך המסמך. במקרה כזה, React *לא* תמקם את ההערות האלה בתוך `<head>` של המסמך, אלא תמקם אותן כמו כל קומפוננטת React אחרת.
```js
<section itemScope>
diff --git a/src/content/reference/react-dom/components/option.md b/src/content/reference/react-dom/components/option.md
index 84725854c..0b86cf67b 100644
--- a/src/content/reference/react-dom/components/option.md
+++ b/src/content/reference/react-dom/components/option.md
@@ -4,7 +4,7 @@ title: "<option>"
<Intro>
-The [built-in browser `<option>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option) lets you render an option inside a [`<select>`](/reference/react-dom/components/select) box.
+רכיב הדפדפן המובנה [`<option>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option) מאפשר לרנדר אפשרות בתוך תיבת [`<select>`](/reference/react-dom/components/select).
```js
<select>
@@ -23,7 +23,7 @@ The [built-in browser `<option>` component](https://developer.mozilla.org/en-US/
### `<option>` {/*option*/}
-The [built-in browser `<option>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option) lets you render an option inside a [`<select>`](/reference/react-dom/components/select) box.
+רכיב הדפדפן המובנה [`<option>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option) מאפשר לרנדר אפשרות בתוך תיבת [`<select>`](/reference/react-dom/components/select).
```js
<select>
@@ -32,31 +32,31 @@ The [built-in browser `<option>` component](https://developer.mozilla.org/en-US/
</select>
```
-[See more examples below.](#usage)
+[ראו דוגמאות נוספות בהמשך.](#usage)
#### Props {/*props*/}
-`<option>` supports all [common element props.](/reference/react-dom/components/common#props)
+`<option>` תומך בכל [מאפייני האלמנט הנפוצים.](/reference/react-dom/components/common#props)
-Additionally, `<option>` supports these props:
+בנוסף, `<option>` תומך ב-props האלה:
-* [`disabled`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#disabled): A boolean. If `true`, the option will not be selectable and will appear dimmed.
-* [`label`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#label): A string. Specifies the meaning of the option. If not specified, the text inside the option is used.
-* [`value`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#value): The value to be used [when submitting the parent `<select>` in a form](/reference/react-dom/components/select#reading-the-select-box-value-when-submitting-a-form) if this option is selected.
+* [`disabled`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#disabled): ערך בוליאני. אם `true`, לא ניתן יהיה לבחור באפשרות והיא תוצג מעומעמת.
+* [`label`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#label): מחרוזת. מציינת את משמעות האפשרות. אם לא הוגדרה, ישמש הטקסט שבתוך האפשרות.
+* [`value`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#value): הערך שישמש [בעת שליחת טופס ה-`<select>` ההורה](/reference/react-dom/components/select#reading-the-select-box-value-when-submitting-a-form) אם האפשרות הזו נבחרה.
#### Caveats {/*caveats*/}
-* React does not support the `selected` attribute on `<option>`. Instead, pass this option's `value` to the parent [`<select defaultValue>`](/reference/react-dom/components/select#providing-an-initially-selected-option) for an uncontrolled select box, or [`<select value>`](/reference/react-dom/components/select#controlling-a-select-box-with-a-state-variable) for a controlled select.
+* React לא תומכת במאפיין `selected` על `<option>`. במקום זאת, העבירו את ה-`value` של האפשרות ל-[`<select defaultValue>`](/reference/react-dom/components/select#providing-an-initially-selected-option) של ההורה עבור select לא נשלט, או ל-[`<select value>`](/reference/react-dom/components/select#controlling-a-select-box-with-a-state-variable) עבור select נשלט.
---
-## Usage {/*usage*/}
+## שימוש {/*usage*/}
-### Displaying a select box with options {/*displaying-a-select-box-with-options*/}
+### הצגת תיבת select עם אפשרויות {/*displaying-a-select-box-with-options*/}
-Render a `<select>` with a list of `<option>` components inside to display a select box. Give each `<option>` a `value` representing the data to be submitted with the form.
+רנדרו `<select>` עם רשימת קומפוננטות `<option>` בתוכו כדי להציג תיבת select. תנו לכל `<option>` ערך `value` שמייצג את הנתון שיישלח עם הטופס.
-[Read more about displaying a `<select>` with a list of `<option>` components.](/reference/react-dom/components/select)
+[קראו עוד על הצגת `<select>` עם רשימת קומפוננטות `<option>`. ](/reference/react-dom/components/select)
<Sandpack>
@@ -80,4 +80,3 @@ select { margin: 5px; }
```
</Sandpack>
-
diff --git a/src/content/reference/react-dom/components/progress.md b/src/content/reference/react-dom/components/progress.md
index 9a8d60ab0..9f288c10d 100644
--- a/src/content/reference/react-dom/components/progress.md
+++ b/src/content/reference/react-dom/components/progress.md
@@ -4,7 +4,7 @@ title: "<progress>"
<Intro>
-The [built-in browser `<progress>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress) lets you render a progress indicator.
+רכיב הדפדפן המובנה [`<progress>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress) מאפשר לרנדר מחוון התקדמות.
```js
<progress value={0.5} />
@@ -20,32 +20,32 @@ The [built-in browser `<progress>` component](https://developer.mozilla.org/en-U
### `<progress>` {/*progress*/}
-To display a progress indicator, render the [built-in browser `<progress>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress) component.
+כדי להציג מחוון התקדמות, רנדרו את רכיב הדפדפן המובנה [`<progress>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress).
```js
<progress value={0.5} />
```
-[See more examples below.](#usage)
+[ראו דוגמאות נוספות בהמשך.](#usage)
#### Props {/*props*/}
-`<progress>` supports all [common element props.](/reference/react-dom/components/common#props)
+`<progress>` תומך בכל [מאפייני האלמנט הנפוצים.](/reference/react-dom/components/common#props)
-Additionally, `<progress>` supports these props:
+בנוסף, `<progress>` תומך ב-props האלה:
-* [`max`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#max): A number. Specifies the maximum `value`. Defaults to `1`.
-* [`value`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#value): A number between `0` and `max`, or `null` for indeterminate progress. Specifies how much was done.
+* [`max`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#max): מספר. מציין את ערך ה-`value` המקסימלי. ברירת המחדל היא `1`.
+* [`value`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#value): מספר בין `0` ל-`max`, או `null` להתקדמות לא-מוגדרת. מציין כמה כבר הושלם.
---
-## Usage {/*usage*/}
+## שימוש {/*usage*/}
-### Controlling a progress indicator {/*controlling-a-progress-indicator*/}
+### שליטה במחוון התקדמות {/*controlling-a-progress-indicator*/}
-To display a progress indicator, render a `<progress>` component. You can pass a number `value` between `0` and the `max` value you specify. If you don't pass a `max` value, it will assumed to be `1` by default.
+כדי להציג מחוון התקדמות, רנדרו קומפוננטת `<progress>`. אפשר להעביר מספר ב-`value` בין `0` לבין ערך ה-`max` שתגדירו. אם לא תעבירו `max`, ברירת המחדל תהיה `1`.
-If the operation is not ongoing, pass `value={null}` to put the progress indicator into an indeterminate state.
+אם הפעולה אינה מתקדמת כרגע, העבירו `value={null}` כדי להעביר את מחוון ההתקדמות למצב לא-מוגדר.
<Sandpack>
diff --git a/src/content/reference/react-dom/components/script.md b/src/content/reference/react-dom/components/script.md
index fc4b01277..9d1b4f93c 100644
--- a/src/content/reference/react-dom/components/script.md
+++ b/src/content/reference/react-dom/components/script.md
@@ -5,13 +5,13 @@ canary: true
<Canary>
-React's extensions to `<script>` are currently only available in React's canary and experimental channels. In stable releases of React `<script>` works only as a [built-in browser HTML component](https://react.dev/reference/react-dom/components#all-html-components). Learn more about [React's release channels here](/community/versioning-policy#all-release-channels).
+ההרחבות של React ל-`<script>` זמינות כרגע רק בערוצי canary ו-experimental של React. בגרסאות יציבות של React, `<script>` פועל רק כ-[רכיב HTML מובנה של הדפדפן](https://react.dev/reference/react-dom/components#all-html-components). מידע נוסף ב-[ערוצי השחרור של React](/community/versioning-policy#all-release-channels).
</Canary>
<Intro>
-The [built-in browser `<script>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script) lets you add a script to your document.
+רכיב הדפדפן המובנה [`<script>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script) מאפשר להוסיף סקריפט למסמך.
```js
<script> alert("hi!") </script>
@@ -27,67 +27,67 @@ The [built-in browser `<script>` component](https://developer.mozilla.org/en-US/
### `<script>` {/*script*/}
-To add inline or external scripts to your document, render the [built-in browser `<script>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script). You can render `<script>` from any component and React will [in certain cases](#special-rendering-behavior) place the corresponding DOM element in the document head and de-duplicate identical scripts.
+כדי להוסיף סקריפטים inline או חיצוניים למסמך, רנדרו את רכיב הדפדפן המובנה [`<script>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script). אפשר לרנדר `<script>` מכל קומפוננטה, ו-React [במקרים מסוימים](#special-rendering-behavior) תמקם את אלמנט ה-DOM המתאים ב-document head ותמנע כפילות של סקריפטים זהים.
```js
<script> alert("hi!") </script>
<script src="script.js" />
```
-[See more examples below.](#usage)
+[ראו דוגמאות נוספות בהמשך.](#usage)
#### Props {/*props*/}
-`<script>` supports all [common element props.](/reference/react-dom/components/common#props)
+`<script>` תומך בכל [מאפייני האלמנט הנפוצים.](/reference/react-dom/components/common#props)
-It should have *either* `children` or a `src` prop.
+הוא צריך לכלול *או* `children` *או* prop בשם `src`.
-* `children`: a string. The source code of an inline script.
-* `src`: a string. The URL of an external script.
+* `children`: מחרוזת. קוד המקור של סקריפט inline.
+* `src`: מחרוזת. ה-URL של סקריפט חיצוני.
-Other supported props:
+Props נתמכים נוספים:
-* `async`: a boolean. Allows the browser to defer execution of the script until the rest of the document has been processed — the preferred behavior for performance.
-* `crossOrigin`: a string. The [CORS policy](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/crossorigin) to use. Its possible values are `anonymous` and `use-credentials`.
-* `fetchPriority`: a string. Lets the browser rank scripts in priority when fetching multiple scripts at the same time. Can be `"high"`, `"low"`, or `"auto"` (the default).
-* `integrity`: a string. A cryptographic hash of the script, to [verify its authenticity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity).
-* `noModule`: a boolean. Disables the script in browsers that support ES modules — allowing for a fallback script for browsers that do not.
-* `nonce`: a string. A cryptographic [nonce to allow the resource](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/nonce) when using a strict Content Security Policy.
-* `referrer`: a string. Says [what Referer header to send](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#referrerpolicy) when fetching the script and any resources that the script fetches in turn.
-* `type`: a string. Says whether the script is a [classic script, ES module, or import map](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type).
+* `async`: ערך בוליאני. מאפשר לדפדפן לדחות את הרצת הסקריפט עד ששאר המסמך עובד — זו ההתנהגות המועדפת לביצועים.
+* `crossOrigin`: מחרוזת. [מדיניות CORS](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/crossorigin) לשימוש. הערכים האפשריים: `anonymous` ו-`use-credentials`.
+* `fetchPriority`: מחרוזת. מאפשר לדפדפן לדרג עדיפות לסקריפטים בזמן טעינה של כמה סקריפטים יחד. יכול להיות `"high"`, `"low"`, או `"auto"` (ברירת מחדל).
+* `integrity`: מחרוזת. hash קריפטוגרפי של הסקריפט לצורך [אימות אותנטיות](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity).
+* `noModule`: ערך בוליאני. מבטל את הסקריפט בדפדפנים שתומכים ב-ES modules — ומאפשר סקריפט חלופי לדפדפנים שלא.
+* `nonce`: מחרוזת. [nonce](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/nonce) קריפטוגרפי שמאפשר את המשאב כשמשתמשים ב-Content Security Policy קשוחה.
+* `referrer`: מחרוזת. מציינת [איזו כותרת Referer לשלוח](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#referrerpolicy) בעת טעינת הסקריפט וכל משאב שהסקריפט טוען לאחר מכן.
+* `type`: מחרוזת. מציינת אם הסקריפט הוא [classic script, ES module, או import map](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type).
-Props that disable React's [special treatment of scripts](#special-rendering-behavior):
+Props שמבטלים את [הטיפול המיוחד של React בסקריפטים](#special-rendering-behavior):
-* `onError`: a function. Called when the script fails to load.
-* `onLoad`: a function. Called when the script finishes being loaded.
+* `onError`: פונקציה. נקראת כשהסקריפט נכשל בטעינה.
+* `onLoad`: פונקציה. נקראת כשהסקריפט סיים להיטען.
-Props that are **not recommended** for use with React:
+Props ש-**לא מומלץ** להשתמש בהם עם React:
-* `blocking`: a string. If set to `"render"`, instructs the browser not to render the page until the scriptsheet is loaded. React provides more fine-grained control using Suspense.
-* `defer`: a string. Prevents the browser from executing the script until the document is done loading. Not compatible with streaming server-rendered components. Use the `async` prop instead.
+* `blocking`: מחרוזת. אם מוגדר ל-`"render"`, מורה לדפדפן לא לרנדר את העמוד עד שה-scriptsheet נטען. React מספקת שליטה מדויקת יותר דרך Suspense.
+* `defer`: מחרוזת. מונע מהדפדפן להריץ את הסקריפט עד שהמסמך סיים להיטען. לא תואם ל-streaming של קומפוננטות מרונדרות שרת. השתמשו ב-prop `async` במקום.
-#### Special rendering behavior {/*special-rendering-behavior*/}
+#### התנהגות רינדור מיוחדת {/*special-rendering-behavior*/}
-React can move `<script>` components to the document's `<head>`, de-duplicate identical scripts, and [suspend](/reference/react/Suspense) while the script is loading.
+React יכולה להזיז רכיבי `<script>` ל-`<head>` של המסמך, למנוע כפילות של סקריפטים זהים, ולבצע [suspend](/reference/react/Suspense) בזמן שהסקריפט נטען.
-To opt into this behavior, provide the `src` and `async={true}` props. React will de-duplicate scripts if they have the same `src`. The `async` prop must be true to allow scripts to be safely moved.
+כדי להפעיל את ההתנהגות הזו, ספקו את ה-props `src` ו-`async={true}`. React תמנע כפילות של סקריפטים אם יש להם אותו `src`. `async` חייב להיות true כדי שיהיה בטוח להזיז סקריפטים.
-If you supply any of the `onLoad` or `onError` props, there is no special behavior, because these props indicate that you are managing the loading of the script manually within your component.
+אם מספקים אחד מה-props `onLoad` או `onError`, אין התנהגות מיוחדת, כי props אלה מציינים שאתם מנהלים ידנית את טעינת הסקריפט בתוך הקומפוננטה.
-This special treatment comes with two caveats:
+לטיפול המיוחד הזה יש שתי הסתייגויות:
-* React will ignore changes to props after the script has been rendered. (React will issue a warning in development if this happens.)
-* React may leave the script in the DOM even after the component that rendered it has been unmounted. (This has no effect as scripts just execute once when they are inserted into the DOM.)
+* React תתעלם משינויים ב-props אחרי שהסקריפט רונדר. (React תציג אזהרה בזמן פיתוח אם זה קורה.)
+* React עשויה להשאיר את הסקריפט ב-DOM גם אחרי שהקומפוננטה שרנדרה אותו הוסרה. (אין לזה השפעה כי סקריפטים מורצים רק פעם אחת כשהם מוכנסים ל-DOM.)
---
-## Usage {/*usage*/}
+## שימוש {/*usage*/}
-### Rendering an external script {/*rendering-an-external-script*/}
+### רינדור סקריפט חיצוני {/*rendering-an-external-script*/}
-If a component depends on certain scripts in order to be displayed correctly, you can render a `<script>` within the component.
+אם קומפוננטה תלויה בסקריפטים מסוימים כדי להיות מוצגת נכון, אפשר לרנדר `<script>` בתוך הקומפוננטה.
-If you supply an `src` and `async` prop, your component will suspend while the script is loading. React will de-duplicate scripts that have the same `src`, inserting only one of them into the DOM even if multiple components render it.
+אם תספקו props של `src` ו-`async`, הקומפוננטה שלכם תבצע suspend בזמן שהסקריפט נטען. React תמנע כפילות של סקריפטים עם אותו `src`, ותכניס רק אחד מהם ל-DOM גם אם כמה קומפוננטות מרנדרות אותו.
<SandpackWithHTMLOutput>
@@ -115,12 +115,12 @@ export default function Page() {
</SandpackWithHTMLOutput>
<Note>
-When you want to use a script, it can be beneficial to call the [preinit](/reference/react-dom/preinit) function. Calling this function may allow the browser to start fetching the script earlier than if you just render a `<script>` component, for example by sending an [HTTP Early Hints response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103).
+כשאתם רוצים להשתמש בסקריפט, יכול להיות מועיל לקרוא לפונקציה [preinit](/reference/react-dom/preinit). קריאה לפונקציה הזו עשויה לאפשר לדפדפן להתחיל להביא את הסקריפט מוקדם יותר מאשר ברינדור רגיל של `<script>`, למשל באמצעות [HTTP Early Hints response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103).
</Note>
-### Rendering an inline script {/*rendering-an-inline-script*/}
+### רינדור סקריפט inline {/*rendering-an-inline-script*/}
-To include an inline script, render the `<script>` component with the script source code as its children. Inline scripts are not de-duplicated or moved to the document `<head>`, and since they don't load any external resources, they will not cause your component to suspend.
+כדי לכלול סקריפט inline, רנדרו את רכיב `<script>` עם קוד המקור של הסקריפט כ-children שלו. סקריפטים inline אינם עוברים de-duplication ואינם מועברים ל-`<head>` של המסמך, ומכיוון שהם לא טוענים משאבים חיצוניים הם לא יגרמו לקומפוננטה לבצע suspend.
<SandpackWithHTMLOutput>
diff --git a/src/content/reference/react-dom/components/style.md b/src/content/reference/react-dom/components/style.md
index 238a26d8c..6908f387b 100644
--- a/src/content/reference/react-dom/components/style.md
+++ b/src/content/reference/react-dom/components/style.md
@@ -5,13 +5,13 @@ canary: true
<Canary>
-React's extensions to `<style>` are currently only available in React's canary and experimental channels. In stable releases of React `<style>` works only as a [built-in browser HTML component](https://react.dev/reference/react-dom/components#all-html-components). Learn more about [React's release channels here](/community/versioning-policy#all-release-channels).
+ההרחבות של React ל-`<style>` זמינות כרגע רק בערוצי canary ו-experimental של React. בגרסאות יציבות של React, `<style>` פועל רק כ-[רכיב HTML מובנה של הדפדפן](https://react.dev/reference/react-dom/components#all-html-components). מידע נוסף ב-[ערוצי השחרור של React](/community/versioning-policy#all-release-channels).
</Canary>
<Intro>
-The [built-in browser `<style>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style) lets you add inline CSS stylesheets to your document.
+רכיב הדפדפן המובנה [`<style>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style) מאפשר להוסיף stylesheets של CSS inline למסמך.
```js
<style>{` p { color: red; } `}</style>
@@ -27,49 +27,49 @@ The [built-in browser `<style>` component](https://developer.mozilla.org/en-US/d
### `<style>` {/*style*/}
-To add inline styles to your document, render the [built-in browser `<style>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style). You can render `<style>` from any component and React will [in certain cases](#special-rendering-behavior) place the corresponding DOM element in the document head and de-duplicate identical styles.
+כדי להוסיף inline styles למסמך, רנדרו את רכיב הדפדפן המובנה [`<style>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style). אפשר לרנדר `<style>` מכל קומפוננטה ו-React [במקרים מסוימים](#special-rendering-behavior) תמקם את אלמנט ה-DOM המתאים בתוך ה-document head ותמנע כפילות של סגנונות זהים.
```js
<style>{` p { color: red; } `}</style>
```
-[See more examples below.](#usage)
+[ראו דוגמאות נוספות בהמשך.](#usage)
#### Props {/*props*/}
-`<style>` supports all [common element props.](/reference/react-dom/components/common#props)
+`<style>` תומך בכל [מאפייני האלמנט הנפוצים.](/reference/react-dom/components/common#props)
-* `children`: a string, required. The contents of the stylesheet.
-* `precedence`: a string. Tells React where to rank the `<style>` DOM node relative to others in the document `<head>`, which determines which stylesheet can override the other. Its value can be (in order of precedence) `"reset"`, `"low"`, `"medium"`, `"high"`. Stylesheets with the same precedence go together whether they are `<link>` or inline `<style>` tags or loaded using the [`preload`](/reference/react-dom/preload) or [`preinit`](/reference/react-dom/preinit) functions.
-* `href`: a string. Allows React to [de-duplicate styles](#special-rendering-behavior) that have the same `href`.
-* `media`: a string. Restricts the spreadsheet to a certain [media query](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries).
-* `nonce`: a string. A cryptographic [nonce to allow the resource](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/nonce) when using a strict Content Security Policy.
-* `title`: a string. Specifies the name of an [alternative stylesheet](https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative_style_sheets).
+* `children`: מחרוזת, חובה. תוכן ה-stylesheet.
+* `precedence`: מחרוזת. אומרת ל-React איך לדרג את `<style>` DOM node ביחס לאחרים בתוך `<head>` של המסמך, מה שקובע איזה stylesheet יכול לעקוף איזה. הערכים האפשריים (לפי סדר קדימות): `"reset"`, `"low"`, `"medium"`, `"high"`. stylesheets עם אותה קדימות מקובצים יחד בין אם הם תגיות `<link>`, תגיות inline `<style>`, או כאלה שנטענו בעזרת [`preload`](/reference/react-dom/preload) או [`preinit`](/reference/react-dom/preinit).
+* `href`: מחרוזת. מאפשרת ל-React [למנוע כפילות של סגנונות](#special-rendering-behavior) שיש להם אותו `href`.
+* `media`: מחרוזת. מגבילה את ה-spreadsheet ל-[media query](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries) מסוים.
+* `nonce`: מחרוזת. [nonce](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/nonce) קריפטוגרפי שמאפשר את המשאב כשמשתמשים ב-Content Security Policy קשוחה.
+* `title`: מחרוזת. מציינת שם של [stylesheet חלופי](https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative_style_sheets).
-Props that are **not recommended** for use with React:
+Props ש-**לא מומלץ** להשתמש בהם עם React:
-* `blocking`: a string. If set to `"render"`, instructs the browser not to render the page until the stylesheet is loaded. React provides more fine-grained control using Suspense.
+* `blocking`: מחרוזת. אם מוגדר ל-`"render"`, מורה לדפדפן לא לרנדר את העמוד עד שה-stylesheet נטען. React מספקת שליטה מדויקת יותר דרך Suspense.
-#### Special rendering behavior {/*special-rendering-behavior*/}
+#### התנהגות רינדור מיוחדת {/*special-rendering-behavior*/}
-React can move `<style>` components to the document's `<head>`, de-duplicate identical stylesheets, and [suspend](http://localhost:3000/reference/react/Suspense) while the stylesheet is loading.
+React יכולה להזיז רכיבי `<style>` ל-`<head>` של המסמך, למנוע כפילות של stylesheets זהים, ולבצע [suspend](http://localhost:3000/reference/react/Suspense) בזמן שה-stylesheet נטען.
-To opt into this behavior, provide the `href` and `precedence` props. React will de-duplicate styles if they have the same `href`. The precedence prop tells React where to rank the `<style>` DOM node relative to others in the document `<head>`, which determines which stylesheet can override the other.
+כדי להפעיל את ההתנהגות הזו, ספקו את ה-props `href` ו-`precedence`. React תמנע כפילות של סגנונות אם יש להם אותו `href`. ה-prop `precedence` אומר ל-React איך לדרג את `<style>` DOM node ביחס לאחרים בתוך `<head>` של המסמך, מה שקובע איזה stylesheet יכול לעקוף איזה.
-This special treatment comes with two caveats:
+לטיפול המיוחד הזה יש שתי הסתייגויות:
-* React will ignore changes to props after the style has been rendered. (React will issue a warning in development if this happens.)
-* React may leave the style in the DOM even after the component that rendered it has been unmounted.
+* React תתעלם משינויים ב-props אחרי שה-style רונדר. (React תציג אזהרה בזמן פיתוח אם זה קורה.)
+* React עשויה להשאיר את ה-style ב-DOM גם אחרי שהקומפוננטה שרנדרה אותו הוסרה.
---
-## Usage {/*usage*/}
+## שימוש {/*usage*/}
-### Rendering an inline CSS stylesheet {/*rendering-an-inline-css-stylesheet*/}
+### רינדור stylesheet של CSS inline {/*rendering-an-inline-css-stylesheet*/}
-If a component depends on certain CSS styles in order to be displayed correctly, you can render an inline stylesheet within the component.
+אם קומפוננטה תלויה בסגנונות CSS מסוימים כדי להיות מוצגת נכון, אפשר לרנדר stylesheet inline בתוך הקומפוננטה.
-If you supply an `href` and `precedence` prop, your component will suspend while the stylesheet is loading. (Even with inline stylesheets, there may be a loading time due to fonts and images that the stylesheet refers to.) The `href` prop should uniquely identify the stylesheet, because React will de-duplicate stylesheets that have the same `href`.
+אם מספקים `href` ו-`precedence`, הקומפוננטה תבצע suspend בזמן שה-stylesheet נטען. (גם עם stylesheets inline, ייתכן זמן טעינה בגלל פונטים ותמונות שה-stylesheet מפנה אליהם.) ה-`href` צריך לזהות בצורה ייחודית את ה-stylesheet, כי React תמנע כפילות של stylesheets עם אותו `href`.
<SandpackWithHTMLOutput>
diff --git a/src/content/reference/react-dom/components/title.md b/src/content/reference/react-dom/components/title.md
index 24b2aba2f..778205c82 100644
--- a/src/content/reference/react-dom/components/title.md
+++ b/src/content/reference/react-dom/components/title.md
@@ -5,14 +5,14 @@ canary: true
<Canary>
-React's extensions to `<title>` are currently only available in React's canary and experimental channels. In stable releases of React `<title>` works only as a [built-in browser HTML component](https://react.dev/reference/react-dom/components#all-html-components). Learn more about [React's release channels here](/community/versioning-policy#all-release-channels).
+ההרחבות של React ל-`<title>` זמינות כרגע רק בערוצי canary ו-experimental של React. בגרסאות יציבות של React, `<title>` פועל רק כ-[רכיב HTML מובנה של הדפדפן](https://react.dev/reference/react-dom/components#all-html-components). מידע נוסף ב-[ערוצי השחרור של React](/community/versioning-policy#all-release-channels).
</Canary>
<Intro>
-The [built-in browser `<title>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title) lets you specify the title of the document.
+רכיב הדפדפן המובנה [`<title>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title) מאפשר לקבוע את כותרת המסמך.
```js
<title>My Blog
@@ -28,41 +28,41 @@ The [built-in browser `
` component](https://developer.mozilla.org/en-US/d
### `<title>` {/*title*/}
-To specify the title of the document, render the [built-in browser `<title>` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title). You can render `<title>` from any component and React will always place the corresponding DOM element in the document head.
+כדי לקבוע את כותרת המסמך, רנדרו את רכיב הדפדפן המובנה [`<title>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title). אפשר לרנדר `<title>` מכל קומפוננטה ו-React תמיד תמקם את אלמנט ה-DOM המתאים בתוך ה-document head.
```js
<title>My Blog
```
-[See more examples below.](#usage)
+[ראו דוגמאות נוספות בהמשך.](#usage)
#### Props {/*props*/}
-`
` supports all [common element props.](/reference/react-dom/components/common#props)
+`<title>` תומך בכל [מאפייני האלמנט הנפוצים.](/reference/react-dom/components/common#props)
-* `children`: `<title>` accepts only text as a child. This text will become the title of the document. You can also pass your own components as long as they only render text.
+* `children`: רכיב `<title>` מקבל רק טקסט כ-child. הטקסט הזה יהפוך לכותרת המסמך. אפשר גם להעביר קומפוננטות משלכם כל עוד הן מרנדרות רק טקסט.
-#### Special rendering behavior {/*special-rendering-behavior*/}
+#### התנהגות רינדור מיוחדת {/*special-rendering-behavior*/}
-React will always place the DOM element corresponding to the `<title>` component within the document’s `<head>`, regardless of where in the React tree it is rendered. The `<head>` is the only valid place for `<title>` to exist within the DOM, yet it’s convenient and keeps things composable if a component representing a specific page can render its `<title>` itself.
+React תמיד תמקם את אלמנט ה-DOM המתאים ל-`<title>` בתוך `<head>` של המסמך, בלי קשר למקום שבו הוא מרונדר בעץ React. `<head>` הוא המקום החוקי היחיד ל-`<title>` בתוך ה-DOM, ובכל זאת זה נוח ושומר על קומפוזביליות אם קומפוננטה שמייצגת עמוד מסוים יכולה לרנדר בעצמה את `<title>` שלה.
-There are two exception to this:
-* If `<title>` is within an `<svg>` component, then there is no special behavior, because in this context it doesn’t represent the document’s title but rather is an [accessibility annotation for that SVG graphic](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/title).
-* If the `<title>` has an [`itemProp`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemprop) prop, there is no special behavior, because in this case it doesn’t represent the document’s title but rather metadata about a specific part of the page.
+יש שני חריגים לכך:
+* אם `<title>` נמצא בתוך רכיב `<svg>`, אין התנהגות מיוחדת, כי בהקשר הזה הוא לא מייצג את כותרת המסמך אלא [הערת נגישות לגרפיקת ה-SVG](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/title).
+* אם ל-`<title>` יש prop מסוג [`itemProp`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemprop), אין התנהגות מיוחדת, כי במקרה הזה הוא לא מייצג את כותרת המסמך אלא metadata על חלק מסוים בעמוד.
<Pitfall>
-Only render a single `<title>` at a time. If more than one component renders a `<title>` tag at the same time, React will place all of those titles in the document head. When this happens, the behavior of browsers and search engines is undefined.
+רנדרו רק `<title>` יחיד בכל רגע. אם יותר מקומפוננטה אחת מרנדרת תגית `<title>` באותו זמן, React תמקם את כל הכותרות האלה בתוך head של המסמך. במצב כזה ההתנהגות של דפדפנים ומנועי חיפוש אינה מוגדרת.
</Pitfall>
---
-## Usage {/*usage*/}
+## שימוש {/*usage*/}
-### Set the document title {/*set-the-document-title*/}
+### הגדרת כותרת המסמך {/*set-the-document-title*/}
-Render the `<title>` component from any component with text as its children. React will put a `<title>` DOM node in the document `<head>`.
+רנדרו את רכיב `<title>` מכל קומפוננטה עם טקסט כ-children שלו. React תשים DOM node של `<title>` בתוך `<head>` של המסמך.
<SandpackWithHTMLOutput>
@@ -82,17 +82,16 @@ export default function ContactUsPage() {
</SandpackWithHTMLOutput>
-### Use variables in the title {/*use-variables-in-the-title*/}
+### שימוש במשתנים בתוך הכותרת {/*use-variables-in-the-title*/}
-The children of the `<title>` component must be a single string of text. (Or a single number or a single object with a `toString` method.) It might not be obvious, but using JSX curly braces like this:
+ה-children של רכיב `<title>` חייבים להיות מחרוזת טקסט יחידה. (או מספר יחיד, או אובייקט יחיד עם מתודת `toString`.) זה עלול להיות לא ברור, אבל שימוש בסוגריים מסולסלים של JSX כך:
```js
<title>Results page {pageNumber} // 🔴 Problem: This is not a single string
```
-... actually causes the `
` component to get a two-element array as its children (the string `"Results page"` and the value of `pageNumber`). This will cause an error. Instead, use string interpolation to pass `<title>` a single string:
+... בעצם גורם לרכיב `<title>` לקבל מערך של שני אלמנטים כ-children (המחרוזת `"Results page"` והערך של `pageNumber`). זה יגרום לשגיאה. במקום זאת, השתמשו ב-string interpolation כדי להעביר ל-`<title>` מחרוזת יחידה:
```js
<title>{`Results page ${pageNumber}`}
```
-
diff --git a/src/content/reference/react-dom/flushSync.md b/src/content/reference/react-dom/flushSync.md
index a97d194e4..dfc8590ab 100644
--- a/src/content/reference/react-dom/flushSync.md
+++ b/src/content/reference/react-dom/flushSync.md
@@ -4,13 +4,13 @@ title: flushSync
-Using `flushSync` is uncommon and can hurt the performance of your app.
+שימוש ב-`flushSync` אינו נפוץ ועלול לפגוע בביצועים של האפליקציה.
-`flushSync` lets you force React to flush any updates inside the provided callback synchronously. This ensures that the DOM is updated immediately.
+`flushSync` מאפשרת לאלץ את React לבצע flush לכל עדכון בתוך callback שסופק באופן סינכרוני. כך מובטח שה-DOM מתעדכן מיידית.
```js
flushSync(callback)
@@ -26,7 +26,7 @@ flushSync(callback)
### `flushSync(callback)` {/*flushsync*/}
-Call `flushSync` to force React to flush any pending work and update the DOM synchronously.
+קראו ל-`flushSync` כדי לאלץ את React לבצע flush לעבודה ממתינה ולעדכן את ה-DOM באופן סינכרוני.
```js
import { flushSync } from 'react-dom';
@@ -36,33 +36,33 @@ flushSync(() => {
});
```
-Most of the time, `flushSync` can be avoided. Use `flushSync` as last resort.
+ברוב המקרים אפשר להימנע מ-`flushSync`. השתמשו בה כמוצא אחרון.
-[See more examples below.](#usage)
+[ראו דוגמאות נוספות בהמשך.](#usage)
#### Parameters {/*parameters*/}
-* `callback`: A function. React will immediately call this callback and flush any updates it contains synchronously. It may also flush any pending updates, or Effects, or updates inside of Effects. If an update suspends as a result of this `flushSync` call, the fallbacks may be re-shown.
+* `callback`: פונקציה. React תקרא ל-callback הזה מיד ותבצע flush סינכרוני לכל עדכון שהוא מכיל. ייתכן שיבוצע flush גם לעדכונים ממתינים, ל-Effects, או לעדכונים מתוך Effects. אם עדכון מבצע suspend כתוצאה מקריאת `flushSync`, ייתכן שה-fallbacks יוצגו שוב.
#### Returns {/*returns*/}
-`flushSync` returns `undefined`.
+`flushSync` מחזירה `undefined`.
#### Caveats {/*caveats*/}
-* `flushSync` can significantly hurt performance. Use sparingly.
-* `flushSync` may force pending Suspense boundaries to show their `fallback` state.
-* `flushSync` may run pending effects and synchronously apply any updates they contain before returning.
-* `flushSync` may flush updates outside the callback when necessary to flush the updates inside the callback. For example, if there are pending updates from a click, React may flush those before flushing the updates inside the callback.
+* `flushSync` יכולה לפגוע משמעותית בביצועים. להשתמש במשורה.
+* `flushSync` עשויה לאלץ גבולות Suspense ממתינים להציג את מצב ה-`fallback` שלהם.
+* `flushSync` עשויה להריץ effects ממתינים ולהחיל באופן סינכרוני כל עדכון שהם מכילים לפני החזרה.
+* `flushSync` עשויה לבצע flush לעדכונים מחוץ ל-callback כשנדרש כדי לבצע flush לעדכונים שבתוך ה-callback. לדוגמה, אם יש עדכונים ממתינים מקליק, React עשויה לבצע להם flush לפני ה-flush לעדכונים שבתוך ה-callback.
---
-## Usage {/*usage*/}
+## שימוש {/*usage*/}
-### Flushing updates for third-party integrations {/*flushing-updates-for-third-party-integrations*/}
+### ביצוע flush לעדכונים עבור אינטגרציות צד שלישי {/*flushing-updates-for-third-party-integrations*/}
-When integrating with third-party code such as browser APIs or UI libraries, it may be necessary to force React to flush updates. Use `flushSync` to force React to flush any state updates inside the callback synchronously:
+בעת אינטגרציה עם קוד צד שלישי כמו APIs של דפדפן או ספריות UI, לעיתים נדרש לאלץ את React לבצע flush לעדכונים. השתמשו ב-`flushSync` כדי לאלץ את React לבצע flush סינכרוני לכל עדכון state בתוך ה-callback:
```js [[1, 2, "setSomething(123)"]]
flushSync(() => {
@@ -71,15 +71,15 @@ flushSync(() => {
// By this line, the DOM is updated.
```
-This ensures that, by the time the next line of code runs, React has already updated the DOM.
+כך מובטח שעד שהשורה הבאה בקוד רצה, React כבר עדכנה את ה-DOM.
-**Using `flushSync` is uncommon, and using it often can significantly hurt the performance of your app.** If your app only uses React APIs, and does not integrate with third-party libraries, `flushSync` should be unnecessary.
+**שימוש ב-`flushSync` אינו נפוץ, ושימוש תכוף בה עלול לפגוע משמעותית בביצועים של האפליקציה.** אם האפליקציה שלכם משתמשת רק ב-React APIs, ולא מבצעת אינטגרציה עם ספריות צד שלישי, לרוב `flushSync` לא נדרשת.
-However, it can be helpful for integrating with third-party code like browser APIs.
+עם זאת, היא יכולה להיות שימושית לאינטגרציה עם קוד צד שלישי כמו APIs של דפדפן.
-Some browser APIs expect results inside of callbacks to be written to the DOM synchronously, by the end of the callback, so the browser can do something with the rendered DOM. In most cases, React handles this for you automatically. But in some cases it may be necessary to force a synchronous update.
+חלק מ-APIs של דפדפן מצפים שתוצאות בתוך callbacks ייכתבו ל-DOM בצורה סינכרונית עד סוף ה-callback, כדי שהדפדפן יוכל לפעול על ה-DOM המרונדר. ברוב המקרים React מטפלת בזה אוטומטית. אבל במקרים מסוימים ייתכן שיהיה צורך לאלץ עדכון סינכרוני.
-For example, the browser `onbeforeprint` API allows you to change the page immediately before the print dialog opens. This is useful for applying custom print styles that allow the document to display better for printing. In the example below, you use `flushSync` inside of the `onbeforeprint` callback to immediately "flush" the React state to the DOM. Then, by the time the print dialog opens, `isPrinting` displays "yes":
+לדוגמה, ה-API של הדפדפן `onbeforeprint` מאפשר לשנות את העמוד רגע לפני שנפתח חלון ההדפסה. זה שימושי ליישום סגנונות הדפסה מותאמים אישית שמשפרים את תצוגת המסמך להדפסה. בדוגמה הבאה משתמשים ב-`flushSync` בתוך ה-callback של `onbeforeprint` כדי לבצע "flush" מיידי של state של React ל-DOM. כך, בזמן שחלון ההדפסה נפתח, `isPrinting` מוצג כ-"yes":
@@ -122,12 +122,12 @@ export default function PrintApp() {
-Without `flushSync`, the print dialog will display `isPrinting` as "no". This is because React batches the updates asynchronously and the print dialog is displayed before the state is updated.
+בלי `flushSync`, חלון ההדפסה יציג `isPrinting` כ-"no". הסיבה היא ש-React מאגדת עדכונים באופן אסינכרוני וחלון ההדפסה מוצג לפני שה-state מתעדכן.
-`flushSync` can significantly hurt performance, and may unexpectedly force pending Suspense boundaries to show their fallback state.
+`flushSync` יכולה לפגוע משמעותית בביצועים, ועלולה באופן בלתי צפוי לאלץ גבולות Suspense ממתינים להציג את מצב ה-fallback שלהם.
-Most of the time, `flushSync` can be avoided, so use `flushSync` as a last resort.
+ברוב הזמן אפשר להימנע מ-`flushSync`, לכן השתמשו בה כמוצא אחרון.
diff --git a/src/content/reference/react-dom/hooks/index.md b/src/content/reference/react-dom/hooks/index.md
index 937de808c..28f4a1bc5 100644
--- a/src/content/reference/react-dom/hooks/index.md
+++ b/src/content/reference/react-dom/hooks/index.md
@@ -1,10 +1,10 @@
---
-title: "Built-in React DOM Hooks"
+title: "React DOM Hooks מובנים"
---
-The `react-dom` package contains Hooks that are only supported for web applications (which run in the browser DOM environment). These Hooks are not supported in non-browser environments like iOS, Android, or Windows applications. If you are looking for Hooks that are supported in web browsers *and other environments* see [the React Hooks page](/reference/react). This page lists all the Hooks in the `react-dom` package.
+החבילה `react-dom` כוללת Hooks שנתמכים רק באפליקציות ווב (שרצות בסביבת DOM של הדפדפן). Hooks אלה לא נתמכים בסביבות שאינן דפדפן, כמו אפליקציות iOS, Android או Windows. אם אתם מחפשים Hooks שנתמכים גם בדפדפנים *וגם בסביבות נוספות*, ראו [את עמוד React Hooks](/reference/react). העמוד הזה מציג את כל ה-Hooks בחבילת `react-dom`.
@@ -14,14 +14,14 @@ The `react-dom` package contains Hooks that are only supported for web applicati
-Form Hooks are currently only available in React's canary and experimental channels. Learn more about [React's release channels here](/community/versioning-policy#all-release-channels).
+Form Hooks זמינים כרגע רק בערוצי canary ו-experimental של React. מידע נוסף ב-[ערוצי השחרור של React](/community/versioning-policy#all-release-channels).
-*Forms* let you create interactive controls for submitting information. To manage forms in your components, use one of these Hooks:
+*Forms* מאפשרים ליצור רכיבים אינטראקטיביים לשליחת מידע. כדי לנהל טפסים בתוך הקומפוננטות, השתמשו באחד מה-Hooks הבאים:
-* [`useFormStatus`](/reference/react-dom/hooks/useFormStatus) allows you to make updates to the UI based on the status of the a form.
-* [`useFormState`](/reference/react-dom/hooks/useFormState) allows you to manage state inside a form.
+* [`useFormStatus`](/reference/react-dom/hooks/useFormStatus) מאפשר לבצע עדכוני UI לפי הסטטוס של טופס.
+* [`useFormState`](/reference/react-dom/hooks/useFormState) מאפשר לנהל state בתוך טופס.
```js
function Form({ action }) {
@@ -46,4 +46,3 @@ function Button() {
);
}
```
-
diff --git a/src/content/reference/react-dom/hooks/useFormState.md b/src/content/reference/react-dom/hooks/useFormState.md
index e2a8d5394..8b42f4548 100644
--- a/src/content/reference/react-dom/hooks/useFormState.md
+++ b/src/content/reference/react-dom/hooks/useFormState.md
@@ -5,13 +5,13 @@ canary: true
-The `useFormState` Hook is currently only available in React's Canary and experimental channels. Learn more about [release channels here](/community/versioning-policy#all-release-channels). In addition, you need to use a framework that supports [React Server Components](/reference/react/use-client) to get the full benefit of `useFormState`.
+ה-Hook `useFormState` זמין כרגע רק בערוצי Canary ו-experimental של React. מידע נוסף ב-[ערוצי שחרור](/community/versioning-policy#all-release-channels). בנוסף, צריך להשתמש ב-framework שתומך ב-[React Server Components](/reference/react/use-client) כדי לקבל את מלוא התועלת מ-`useFormState`.
-`useFormState` is a Hook that allows you to update state based on the result of a form action.
+`useFormState` הוא Hook שמאפשר לעדכן state על בסיס תוצאת פעולה של טופס.
```js
const [state, formAction] = useFormState(fn, initialState, permalink?);
@@ -29,7 +29,7 @@ const [state, formAction] = useFormState(fn, initialState, permalink?);
{/* TODO T164397693: link to actions documentation once it exists */}
-Call `useFormState` at the top level of your component to create component state that is updated [when a form action is invoked](/reference/react-dom/components/form). You pass `useFormState` an existing form action function as well as an initial state, and it returns a new action that you use in your form, along with the latest form state. The latest form state is also passed to the function that you provided.
+קראו ל-`useFormState` ברמה העליונה של הקומפוננטה כדי ליצור state לקומפוננטה שמתעדכן [כשפעולת טופס מופעלת](/reference/react-dom/components/form). אתם מעבירים ל-`useFormState` פונקציית form action קיימת יחד עם state התחלתי, והפונקציה מחזירה action חדשה שתשתמשו בה בטופס, יחד עם מצב הטופס העדכני ביותר. מצב הטופס העדכני גם מועבר לפונקציה שסיפקתם.
```js
import { useFormState } from "react-dom";
@@ -49,39 +49,39 @@ function StatefulForm({}) {
}
```
-The form state is the value returned by the action when the form was last submitted. If the form has not yet been submitted, it is the initial state that you pass.
+מצב הטופס הוא הערך שמוחזר מה-action כשהטופס הוגש לאחרונה. אם הטופס עדיין לא הוגש, זה יהיה ה-state ההתחלתי שהעברתם.
-If used with a Server Action, `useFormState` allows the server's response from submitting the form to be shown even before hydration has completed.
+בשימוש עם Server Action, `useFormState` מאפשר להציג את תגובת השרת מהגשת הטופס עוד לפני שה-hydration הושלם.
-[See more examples below.](#usage)
+[ראו דוגמאות נוספות בהמשך.](#usage)
#### Parameters {/*parameters*/}
-* `fn`: The function to be called when the form is submitted or button pressed. When the function is called, it will receive the previous state of the form (initially the `initialState` that you pass, subsequently its previous return value) as its initial argument, followed by the arguments that a form action normally receives.
-* `initialState`: The value you want the state to be initially. It can be any serializable value. This argument is ignored after the action is first invoked.
-* **optional** `permalink`: A string containing the unique page URL that this form modifies. For use on pages with dynamic content (eg: feeds) in conjunction with progressive enhancement: if `fn` is a [server action](/reference/react/use-server) and the form is submitted before the JavaScript bundle loads, the browser will navigate to the specified permalink URL, rather than the current page's URL. Ensure that the same form component is rendered on the destination page (including the same action `fn` and `permalink`) so that React knows how to pass the state through. Once the form has been hydrated, this parameter has no effect.
+* `fn`: הפונקציה שתיקרא כששולחים את הטופס או לוחצים על כפתור. כשהפונקציה נקראת, היא תקבל את מצב הטופס הקודם (בהתחלה ה-`initialState` שהעברתם, ובהמשך ערך ההחזרה הקודם שלה) כארגומנט ראשון, ואז את הארגומנטים ש-form action מקבלת בדרך כלל.
+* `initialState`: הערך שתרצו שיהיה למצב בתחילה. הוא יכול להיות כל ערך שניתן לסריאליזציה. מתעלמים מהארגומנט הזה אחרי הפעלת הפעולה בפעם הראשונה.
+* **אופציונלי** `permalink`: מחרוזת שמכילה את URL העמוד הייחודי שהטופס הזה משנה. מיועד לעמודים עם תוכן דינמי (למשל feed) יחד עם progressive enhancement: אם `fn` היא [server action](/reference/react/use-server) והטופס נשלח לפני ש-JavaScript bundle נטען, הדפדפן ינווט ל-URL של ה-permalink שצוין במקום ל-URL של העמוד הנוכחי. ודאו שאותה קומפוננטת טופס מרונדרת בעמוד היעד (כולל אותה action `fn` ואותו `permalink`) כדי ש-React תדע להעביר את המצב. אחרי שהטופס עובר hydration, לפרמטר הזה אין השפעה.
{/* TODO T164397693: link to serializable values docs once it exists */}
#### Returns {/*returns*/}
-`useFormState` returns an array with exactly two values:
+`useFormState` מחזירה מערך עם שני ערכים בדיוק:
-1. The current state. During the first render, it will match the `initialState` you have passed. After the action is invoked, it will match the value returned by the action.
-2. A new action that you can pass as the `action` prop to your `form` component or `formAction` prop to any `button` component within the form.
+1. המצב הנוכחי. בזמן הרינדור הראשון הוא יתאים ל-`initialState` שהעברתם. אחרי שהפעולה מופעלת, הוא יתאים לערך שהוחזר מהפעולה.
+2. פעולה חדשה שאפשר להעביר כ-prop בשם `action` לקומפוננטת `form` שלכם, או כ-prop בשם `formAction` לכל קומפוננטת `button` בתוך הטופס.
#### Caveats {/*caveats*/}
-* When used with a framework that supports React Server Components, `useFormState` lets you make forms interactive before JavaScript has executed on the client. When used without Server Components, it is equivalent to component local state.
-* The function passed to `useFormState` receives an extra argument, the previous or initial state, as its first argument. This makes its signature different than if it were used directly as a form action without using `useFormState`.
+* כשמשתמשים במסגרת שתומכת ב-React Server Components, `useFormState` מאפשרת להפוך טפסים לאינטראקטיביים עוד לפני ש-JavaScript בוצע בלקוח. בשימוש בלי Server Components, זה שקול ל-state מקומי של קומפוננטה.
+* הפונקציה שמועברת ל-`useFormState` מקבלת ארגומנט נוסף — ה-state הקודם או ההתחלתי — כארגומנט ראשון. לכן ה-signature שלה שונה מאשר שימוש ישיר בה כ-form action בלי `useFormState`.
---
## Usage {/*usage*/}
-### Using information returned by a form action {/*using-information-returned-by-a-form-action*/}
+### שימוש במידע שמוחזר מפעולת טופס {/*using-information-returned-by-a-form-action*/}
-Call `useFormState` at the top level of your component to access the return value of an action from the last time a form was submitted.
+קראו ל-`useFormState` ברמה העליונה של הקומפוננטה כדי לגשת לערך ההחזרה של action מהפעם האחרונה שהטופס הוגש.
```js [[1, 5, "state"], [2, 5, "formAction"], [3, 5, "action"], [4, 5, "null"], [2, 8, "formAction"]]
import { useFormState } from 'react-dom';
@@ -98,14 +98,14 @@ function MyComponent() {
}
```
-`useFormState` returns an array with exactly two items:
+`useFormState` מחזירה מערך עם שני פריטים בדיוק:
-1. The current state of the form, which is initially set to the initial state you provided, and after the form is submitted is set to the return value of the action you provided.
-2. A new action that you pass to `