wip

Author: mirorauhala

src/content/learn/lifecycle-of-reactive-effects.md

@@ -1,27 +1,27 @@
 ---
-title: 'Lifecycle of Reactive Effects'
+title: 'Reaktiivisten Efektien elinkaari'
 ---
 
 <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.
+Efekteilla on eri elinkaari komponenteista. Komponentit voivat mountata, päivittyä, tai un-mountata. Efekti voi tehdä vain kaksi asiaa: aloittaa synkronoimaan jotain, ja myöhemmin lopettaa synkronointi. Tämä sykli voi tapahtua useita kertoja, jos Efekti riippuu propseista ja tilasta, jotka muuttuvat ajan myötä. React tarjoaa linter-säännön, joka tarkistaa, että olet määrittänyt Efektin riippuvuudet oikein. Tämä pitää Efektisi synkronoituna viimeisimpiin proppseihin ja statukseen.
 
 </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
+- Miten Efektin elinkaari eroaa komponentin elinkaaresta
+- Miten ajatella jokaista yksittäistä Efektia erillään
+- Milloin Efektisi täytyy synkronoida uudelleen ja miksi
+- Miten Effektisi riippuvuudet määritellään
+- Mitä tarkoittaa kun arvo on reaktiivinen
+- Mitä tyhjä riippuvuustaulukko tarkoittaa
+- Miten React tarkistaa rippuuksien oikeudellisuuden linterin avulla
+- Mitä tehdä kun olet eri mieltä linterin kanssa
 
 </YouWillLearn>
 
-## The lifecycle of an Effect {/*the-lifecycle-of-an-effect*/}
+## Efektin elinkaari {/*the-lifecycle-of-an-effect*/}
 
 Every React component goes through the same lifecycle:
 
@@ -82,7 +82,7 @@ Some Effects don't return a cleanup function at all. [More often than not,](/lea
 
 </Note>
 
-### Why synchronization may need to happen more than once {/*why-synchronization-may-need-to-happen-more-than-once*/}
+### Miksi synkronointi voi tapahtua useammin kuin kerran {/*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:
 
@@ -128,8 +128,7 @@ At this point, you want React to do two things:
 2. Start synchronizing with the new `roomId` (connect to the `"travel"` room)
 
 **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.
-
-### How React re-synchronizes your Effect {/*how-react-re-synchronizes-your-effect*/}
+### Miten React uudelleen synkronisoi Efektisi {/*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.
 
@@ -162,7 +161,7 @@ Every time after your component re-renders with a different `roomId`, your Effec
 
 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.
 
-### Thinking from the Effect's perspective {/*thinking-from-the-effects-perspective*/}
+### Ajattelu Efektin perspektiivistä {/*thinking-from-the-effects-perspective*/}
 
 Let's recap everything that's happened from the `ChatRoom` component's perspective:
 
@@ -204,7 +203,7 @@ Previously, you were thinking from the component's perspective. When you looked
 
 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)
 
-### How React verifies that your Effect can re-synchronize {/*how-react-verifies-that-your-effect-can-re-synchronize*/}
+### Miten React vahvistaa, että Efektisi voi synkronoitua uudelleen {/*how-react-verifies-that-your-effect-can-re-synchronize*/}
 
 Here is a live example that you can play with. Press "Open chat" to mount the `ChatRoom` component:
 
@@ -286,7 +285,7 @@ The main reason your Effect will re-synchronize in practice is if some data it u
 
 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.
 
-### How React knows that it needs to re-synchronize the Effect {/*how-react-knows-that-it-needs-to-re-synchronize-the-effect*/}
+### Miten React tietää, että sen täytyy synkronoida Efekti uudelleen {/*how-react-knows-that-it-needs-to-re-synchronize-the-effect*/}
 
 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)
 
@@ -312,7 +311,7 @@ Every time after your component re-renders, React will look at the array of depe
 
 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.
 
-### Each Effect represents a separate synchronization process {/*each-effect-represents-a-separate-synchronization-process*/}
+### Kukin Efekti edustaa erillistä synkronointiprosessia {/*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:
 
@@ -350,7 +349,7 @@ function ChatRoom({ roomId }) {
 
 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.
 
-## Effects "react" to reactive values {/*effects-react-to-reactive-values*/}
+## Efektit "reagoivat" reaktiivisiin arvoihin {/*effects-react-to-reactive-values*/}
 
 Your Effect reads two variables (`serverUrl` and `roomId`), but you only specified `roomId` as a dependency:
 
@@ -470,7 +469,7 @@ button { margin-left: 10px; }
 
 Whenever you change a reactive value like `roomId` or `serverUrl`, the Effect re-connects to the chat server.
 
-### What an Effect with empty dependencies means {/*what-an-effect-with-empty-dependencies-means*/}
+### Mitä tyhjä riippuvuustaulukko tarkoittaa {/*what-an-effect-with-empty-dependencies-means*/}
 
 What happens if you move both `serverUrl` and `roomId` outside the component?
 
@@ -550,7 +549,7 @@ button { margin-left: 10px; }
 
 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.
 
-### All variables declared in the component body are reactive {/*all-variables-declared-in-the-component-body-are-reactive*/}
+### Kaikki muuttujat komponentin sisällä ovat reaktiivisia {/*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.
 
@@ -591,7 +590,7 @@ As you'll learn below on this page, a linter will check for these issues automat
 
 </DeepDive>
 
-### React verifies that you specified every reactive value as a dependency {/*react-verifies-that-you-specified-every-reactive-value-as-a-dependency*/}
+### React tarkistaa, että olet määrittänyt jokaisen reaktiivisen arvon riippuvuudeksi {/*react-verifies-that-you-specified-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:
 
@@ -693,7 +692,7 @@ In some cases, React *knows* that a value never changes even though it's declare
 
 </Note>
 
-### What to do when you don't want to re-synchronize {/*what-to-do-when-you-dont-want-to-re-synchronize*/}
+### Mitä tehdä kun et halua synkronoida uudelleen {/*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.