diff --git a/src/content/learn/choosing-the-state-structure.md b/src/content/learn/choosing-the-state-structure.md index 5be2b4d3..27241bb4 100644 --- a/src/content/learn/choosing-the-state-structure.md +++ b/src/content/learn/choosing-the-state-structure.md @@ -1,53 +1,53 @@ --- -title: Choosing the State Structure +title: Odabir strukture state-a --- -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. Here are some tips you should consider when structuring state. +Pravilno strukturiranje state-a može napraviti razliku između komponente koju je lako menjati i debug-ovati, i one koja je stalan izvor bug-ova. Ovde se nalazi par saveta koje trebate razmotriti kada strukturirate state. -* When to use a single vs multiple state variables -* What to avoid when organizing state -* How to fix common issues with the state structure +* Kada da koristite jednu ili više state promenljivih +* Šta izbegavati prilikom organizacije state-a +* Kako popraviti česte probleme sa strukturom state-a -## Principles for structuring state {/*principles-for-structuring-state*/} +## Principi za strukturiranje state-a {/*principles-for-structuring-state*/} -When you write a component that holds some state, you'll have to make choices about how many state variables to use and what the shape of their data should be. While it's possible to write correct programs even with a suboptimal state structure, there are a few principles that can guide you to make better choices: +Kada pišete komponentu koja sadrži neki state, moraćete da odlučite koliko state promenljivih da koristite i kakav oblik podataka u njima vam je potreban. Iako je moguće da napišete pravilan program sa neoptimizovanom strukturom state-a, postoji par principa koji vas mogu uputiti da donesete bolje odluke: -1. **Group related state.** If you always update two or more state variables at the same time, consider merging them into a single state variable. -2. **Avoid contradictions in state.** When the state is structured in a way that several pieces of state may contradict and "disagree" with each other, you leave room for mistakes. Try to avoid this. -3. **Avoid redundant state.** If you can calculate some information from the component's props or its existing state variables during rendering, you should not put that information into that component's state. -4. **Avoid duplication in state.** When the same data is duplicated between multiple state variables, or within nested objects, it is difficult to keep them in sync. Reduce duplication when you can. -5. **Avoid deeply nested state.** Deeply hierarchical state is not very convenient to update. When possible, prefer to structure state in a flat way. +1. **Grupisati povezane state-ove.** Ako uvek istovremeno ažurirate dve ili više state promenljivih, pokušajte da ih spojite u jednu state promenljivu. +2. **Izbegavati kontradikcije u state-u.** Kada je state strukturiran tako da više delova state-a budu kontradiktorni i "neodgovarajući" jedni drugima, ostavljate prostora za greške. Pokušajte ovo da izbegnete. +3. **Izbegavati suvišan state.** Ako, tokom renderovanja, neku informaciju možete izračunati na osnovu props-a komponente ili već postojeće state promenljive, ne biste trebali da stavite tu informaciju u state komponente. +4. **Izbegavati dupliranje u state-u.** Kada su isti podaci duplirani u više state promenljivih, ili unutar ugnježdenih objekata, teško je sinhronizovati ih. Smanjite dupliranje kada to možete. +5. **Izbegavati duboko ugnježedeni state.** Hijerarhijski dubok state nije zgodan za ažuriranje. Kada je moguće, preferirajte da strukturirate state da bude flat. -The goal behind these principles is to *make state easy to update without introducing mistakes*. Removing redundant and duplicate data from state helps ensure that all its pieces stay in sync. This is similar to how a database engineer might want to ["normalize" the database structure](https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description) to reduce the chance of bugs. To paraphrase Albert Einstein, **"Make your state as simple as it can be--but no simpler."** +Cilj iza ovih principa je da *napravite da se state lako ažurira bez uvođenja grešaka*. Uklanjanje suvišnih i dupliranih podataka iz state-a pomaže da svi njegovi delovi ostanu sinhronizovani. Ovo je slično onome kako inženjeri baza podataka žele da ["normalizuju" strukturu baze podataka](https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description) i smanje šanse za bug-ove. Da parafraziramo Alberta Ajnštajna, **"Napravite vaš state što jednostavnijim--ali ne jednostavnijim od toga."** -Now let's see how these principles apply in action. +Hajde da vidimo primenu ovih principa na delu. -## Group related state {/*group-related-state*/} +## Grupisati povezane state-ove {/*group-related-state*/} -You might sometimes be unsure between using a single or multiple state variables. +Ponekad se možete dvoumiti između upotrebe jedne ili više state promenljivih. -Should you do this? +Da li koristiti ovo? ```js const [x, setX] = useState(0); const [y, setY] = useState(0); ``` -Or this? +Ili ovo? ```js const [position, setPosition] = useState({ x: 0, y: 0 }); ``` -Technically, you can use either of these approaches. But **if some two state variables always change together, it might be a good idea to unify them into a single state variable.** Then you won't forget to always keep them in sync, like in this example where moving the cursor updates both coordinates of the red dot: +Tehnički, možete koristiti oba pristupa. Ali, **ako se dve state promenljive uvek menjaju zajedno, može biti dobra ideja da ih grupišete u jednu state promenljivu**. Tako nećete zaboravati da ih držite sinhronizovane, kao u ovom primeru gde pomeranje kursora ažurira obe koordinate crvene tačke: @@ -93,17 +93,17 @@ body { margin: 0; padding: 0; height: 250px; } -Another case where you'll group data into an object or an array is when you don't know how many pieces of state you'll need. For example, it's helpful when you have a form where the user can add custom fields. +Drugi slučaj gde možete grupisati podatke u objekat ili niz je kada ne znate koliko state-ova vam treba. Na primer, korisno je kada imate formu gde korisnik može uneti polja po sopstvenoj želji. -If your state variable is an object, remember that [you can't update only one field in it](/learn/updating-objects-in-state) without explicitly copying the other fields. For example, you can't do `setPosition({ x: 100 })` in the above example because it would not have the `y` property at all! Instead, if you wanted to set `x` alone, you would either do `setPosition({ ...position, x: 100 })`, or split them into two state variables and do `setX(100)`. +Ako vam je state promenljiva objekat, zapamtite da [ne možete ažurirati samo jedno polje u njemu](/learn/updating-objects-in-state) bez eksplicitnog kopiranja ostalih polja. Na primer, ne možete napisati `setPosition({ x: 100 })` u primeru iznad jer nemate `y` polje uopšte! Umesto toga, ako želite da postavite samo `x`, napisaćete `setPosition({ ...position, x: 100 })`, ili ćete ih podeliti u dve state promenljive i napisati `setX(100)`. -## Avoid contradictions in state {/*avoid-contradictions-in-state*/} +## Izbegavati kontradikcije u state-u {/*avoid-contradictions-in-state*/} -Here is a hotel feedback form with `isSending` and `isSent` state variables: +Ovde je feedback forma za hotel sa `isSending` i `isSent` state promenljivama: @@ -124,12 +124,12 @@ export default function FeedbackForm() { } if (isSent) { - return

Thanks for feedback!

+ return

Hvala za feedback!

} return (
-

How was your stay at The Prancing Pony?

+

Kako vam je bilo u The Prancing Pony hotelu?