Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translate State Management [DONE] #46

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 17 additions & 17 deletions src/v2/guide/state-management.md
Original file line number Diff line number Diff line change
@@ -1,20 +1,20 @@
---
title: State Management
title: Managementul Stărilor
type: guide
order: 502
---

## Official Flux-Like Implementation
## Implementare Oficială Similară cu Flux

Large applications can often grow in complexity, due to multiple pieces of state scattered across many components and the interactions between them. To solve this problem, Vue offers [vuex](https://github.com/vuejs/vuex): our own Elm-inspired state management library. It even integrates into [vue-devtools](https://github.com/vuejs/vue-devtools), providing zero-setup access to time travel.
Aplicațiile mari pot crește adesea în complexitate datorită mai multor părți ale stării împrăștiate prin multe componente și prin interacțiunile dintre ele. Pentru a rezolva această problemă, Vue oferă [vuex](https://github.com/vuejs/vuex): biblioteca proprie de management al stărilor inspirată din limbajul Elm. Aceasta se integrează chiar și în [vue-devtools](https://github.com/vuejs/vue-devtools), asigurând accesul la călătorii în timp fără configurări adiționale.

### Information for React Developers
### Informații pentru Dezvoltatorii-React

If you're coming from React, you may be wondering how vuex compares to [redux](https://github.com/reactjs/redux), the most popular Flux implementation in that ecosystem. Redux is actually view-layer agnostic, so it can easily be used with Vue via [simple bindings](https://github.com/egoist/revue). Vuex is different in that it _knows_ it's in a Vue app. This allows it to better integrate with Vue, offering a more intuitive API and improved development experience.
Dacă treceți de la React la Vue, s-ar putea să vă întrebați cum sunt legate vuex și [redux](https://github.com/reactjs/redux), cea mai populară implementare Flux în acel ecosistem. Redux este de fapt agnostic pentru straturile de prezentare, astfel încât poate fi utilizat cu ușurință cu Vue prin [legături simple](https://github.com/egoist/revue). Vuex este diferit prin faptul că _știe_ că se află într-o aplicație Vue. Acest lucru îi permite să se integreze mai bine cu Vue, oferind un API mai intuitiv și o experiență de dezvoltare îmbunătățită.

## Simple State Management from Scratch
## Un Simplu Container de Stări de la Zero

It is often overlooked that the source of truth in Vue applications is the raw `data` object - a Vue instance only proxies access to it. Therefore, if you have a piece of state that should be shared by multiple instances, you can share it by identity:
Adesea este trecut cu vederea faptul că "sursa adevărului" în aplicațiile Vue este obiectul brut `data` - o instanță Vue doar accesează proxy-ul acestuia. Prin urmare, dacă aveți un fragment al unei stări care ar trebui să fie partajat de mai multe instanțe, puteți să îl distribuiți prin identitate (link):

``` js
const sourceOfTruth = {}
Expand All @@ -28,30 +28,30 @@ const vmB = new Vue({
})
```

Now whenever `sourceOfTruth` is mutated, both `vmA` and `vmB` will update their views automatically. Subcomponents within each of these instances would also have access via `this.$root.$data`. We have a single source of truth now, but debugging would be a nightmare. Any piece of data could be changed by any part of our app at any time, without leaving a trace.
Acum, cu orice schimbare în `sourceOfTruth` atât `vmA` cât și `vmB` se vor actualiza. Subcomponentele din fiecare dintre aceste instanțe de asemenea vor avea acces prin intermediul `this.$root.$data`. Avem o singură sursă de adevăr acum, dar depanarea codului ar fi un coșmar. Orice bucată de date ar putea fi modificată de oricare parte a aplicației noastre în orice moment fără a lăsa urme.

To help solve this problem, we can adopt a **store pattern**:
Pentru a rezolva această problemă, putem folosi un **model de element de stocare**:

``` js
var store = {
debug: true,
state: {
message: 'Hello!'
message: 'Salut!'
},
setMessageAction (newValue) {
if (this.debug) console.log('setMessageAction triggered with', newValue)
if (this.debug) console.log('setMessageAction apelată cu', newValue)
this.state.message = newValue
},
clearMessageAction () {
if (this.debug) console.log('clearMessageAction triggered')
if (this.debug) console.log('clearMessageAction apelată')
this.state.message = ''
}
}
```

Notice all actions that mutate the store's state are put inside the store itself. This type of centralized state management makes it easier to understand what type of mutations could happen and how are they triggered. Now when something goes wrong, we'll also have a log of what happened leading up to the bug.
Rețineți că toate acțiunile care mută starea spațiului de stocare (store) sunt plasate în el însuși. Acest tip de management centralizat al stării ușurează înțelegerea tipurilor de mutații care s-ar putea întâmpla și cum sunt declanșate. Astfel, în cazul în care ceva nu merge bine vom avea un jurnal pe care puteți urmări secvența de acțiuni care generează bug-ul.

In addition, each instance/component can still own and manage its own private state:
În plus, fiecare instanță/componentă poate să mai dețină și să gestioneze propria sa stare privată:

``` js
var vmA = new Vue({
Expand All @@ -71,8 +71,8 @@ var vmB = new Vue({

![State Management](/images/state.png)

<p class="tip">It's important to note that you should never replace the original state object in your actions - the components and the store need to share reference to the same object in order for mutations to be observed.</p>
<p class="tip">Este important să rețineți că niciodată nu trebuie să înlocuiți obiectul original de stări în acțiunile dvs. - componentele și elementul de stocare trebuie să se refere la același obiect, altfel nu va fi posibilă urmărirea modificărilor.</p>

As we continue developing the convention where components are never allowed to directly mutate state that belongs to a store, but should instead dispatch events that notify the store to perform actions, we eventually arrive at the [Flux](https://facebook.github.io/flux/) architecture. The benefit of this convention is we can record all state mutations happening to the store and implement advanced debugging helpers such as mutation logs, snapshots, and history re-rolls / time travel.
Pe măsură ce continuăm să dezvoltăm convenția în care componentelor nu li se permite niciodată să muteze direct starea care aparține unui element de stocare, ci ar trebui să trimită în schimb evenimente care anunță elementul de stocare să efectueze acțiuni, vom ajunge în cele din urmă la arhitectura [Flux](https://facebook.github.io/flux/). Avantajul acestei abordări constă în abilitatea de a înregistra toate schimbările care au loc cu elementul de stocare, ceea ce permite utilizarea tehnicilor avansate de depanare, cum ar fi jurnalele de schimbare, instantaneele de date și istoricul revizuirilor / călătoriilor în timp.

This brings us full circle back to [vuex](https://github.com/vuejs/vuex), so if you've read this far it's probably time to try it out!
Toate acestea ne aduc înapoi la [vuex](https://github.com/vuejs/vuex), deci dacă ați citit până aici, atunci probabil a venit timpul să-l încercați!