In versiunea 3.3 a Marionette, vom introduce Marionette.NextCollectionView de-a lungul curentului CollectionView. Aceasta noua CollectionView va aduce performante mai bune impreuna cu un API mai consistent si, facand acest lucru, include unele modificari de ultima ora si introduce o multime de coduri noi care trebuie testate in lupta in lumea reala.

Array

Prin urmare, introducerea acestuia alaturi de actualul CollectionView permite dezvoltatorilor sa incerce treptat si sa migreze inainte de a fi nevoie sa se mute la el intr-o versiune majora viitoare.

Obiectivele din spatele acestei schimbari se impart in trei mari categorii:

  • Ar trebui sa existe o metoda si un flux logic pentru a face ceva.
  • CollectionView ar trebui sa fie mai preocupat de vizualizarile copilului decat de modelele de colectie.
  • API-ul ar trebui sa fie intuitiv si consecvent

Backbone v1.

Array

3 a lansat o caracteristica substantiala atunci cand a inclus un eveniment de actualizare in colectie, care este descris de backbonejs.org ca un „eveniment unic declansat dupa ce un numar de modele au fost adaugate sau eliminate dintr-o colectie”. Inainte de aceasta versiune, unui dezvoltator i s-au oferit doua optiuni, resetati colectia, care in Marionette ar reda din nou intregul CollectionView sau lasati Marionette sa adauge si sa elimine vizualizarile modificate pe rand, de fiecare data determinand unde ar trebui inserata sau eliminata o vizualizare. in DOM.

Array

Daca Marionette ar sti ca redarea intregului CollectionView ar crea un fragment de document pentru a construi DOM-ul inainte de a-l insera dintr-o data, dar inserarea pe rand a facut-o astfel incat sa avem nevoie de doua moduri diferite de redare. Astfel, actualul CollectionView contine atat un attachBuffer, cat si un attachHtml. Desi Marionette a reusit sa utilizeze evenimentul de actualizare pentru a imbunatati performanta in unele cazuri, in altele a fost dificil, daca nu imposibil, fara a introduce modificari de rupere. Aceasta complexitate a introdus probleme suplimentare atunci cand a fost combinata cu sortarea si filtrarea.

O caracteristica adaugata a avut atat de multe probleme majuscule, deoarece au existat mai multe moduri de a adauga sau elimina vizualizari, unele legate de colectie si altele nu.

Asa ca am introdus un flux logic simplificat. Indiferent de modul in care un copil este adaugat sau eliminat, se foloseste acelasi flux logic.

Aceasta inseamna ca orice vizualizare adaugata la DOM de catre o colectie va fi adaugata prin aceeasi metoda attachHtml. De asemenea, inseamna ca fiecare vizualizare copil va fi instantaniata si redata numai daca trebuie sa fie. In afara de eliminarea si re-adaugarea unui model intr-o colectie, o vizualizare copil va fi redata de CollectionView numai o singura data (presupunand ca nu este pre-redata), indiferent de actiunea pe care o luati. In prezent, CollectionView va distruge cu greu si reinitializa toti copiii sai in multe cazuri, cum ar fi daca se adauga modele atunci cand optimizarea reorderOnSort a CollectionView este setata la adevarat.

Actualul CollectionView al Marionette are o relatie precara cu colectia sa. In teorie, API-ul ar sugera si, in multe cazuri, este conceput astfel incat sa nu aveti nevoie de o colectie pentru a utiliza vizualizarea. O colectie este doar o modalitate (si poate cea principala) de a gestiona vizualizarile intr-un CollectionView. Cu toate acestea, pe masura ce CollectionView a progresat, unele caracteristici s-au concentrat mai specific pe relatia CollectionView cu modelele de baza ale colectiei. Cel mai mare exemplu in acest sens este probabil filtrul.

Cand filtrati un CollectionView in prezent, vizualizarea itereaza peste this.collection.models pentru a filtra ce vizualizari ar trebui incluse in copii. Cu aceasta abordare, vizualizarile adaugate in afara colectiei, indiferent daca au un model sau nu, nu sunt niciodata luate in considerare de filtru. Pentru a complica lucrurile, modelele sunt filtrate inainte de a construi copiii. La inceput, acest lucru nu pare a fi o mare problema, dar dupa acest punct, daca un model este inserat in colectia originala, totul trebuie reconstruit, deoarece indexul inserat nu are un context real cu copiii deja filtrati.

In NextCollectionView, copiii sunt determinati mai intai . Apoi sortarea si filtrarea itereaza peste copii dupa vizualizare si nu dupa model. Vizualizarile care sunt filtrate sunt doar detasate in loc sa fie distruse si raman in copii. Daca sunt vreodata filtrate din nou, acestea sunt pur si simplu re-atasate si nu trebuie sa fie reconstruite sau redate.

Ca si in cazul oricarui refactor, este important sa faceti un pas inapoi si sa luati in considerare problema in ansamblu. In timp ce se repeta noile caracteristici de pe CollectionView, s-au adaugat API-uri care au avut sens in context, dar este timpul sa analizam modul in care API-ul ar putea fi facut mai consistent si mai intuitiv. In mod ideal, invatarea unei caracteristici duce la o intelegere timpurie a alteia astfel incat s-ar putea asuma API-ul unei alte caracteristici fara a fi nevoie sa cititi documentatia. API-ul a fost modificat putin in diferite domenii, dar cea mai drastica modificare a fost sortarea si filtrarea. Graficul de mai jos compara atat sortarea, cat si filtrarea pentru urmatoarea si actuala CollectionView.

Mai intai actiunile pentru efectuarea unui sortare sau filtrare au fost denumite in mod adecvat sortare si filtrare. Desi este posibil ca aceste metode sa nu aiba sens sa apelati direct des, optiunea exista pentru aceste cazuri de utilizare. Aceasta a insemnat ca steagul de sortare curent va trebui redenumit si i s-a dat un nume care se potriveste mai direct cu scopul sau de baza sortWithCollection. Ambele seturi de caracteristici au acum getters, setere si o metoda de eliminare (care este zaharul pentru set (nul)). In plus, iteratorii de vizualizare au fost denumiti in mod similar viewFilter si viewComparator si, dupa cum sa mentionat anterior, ambii iterati asupra vizualizarilor acum in loc de modele.

O imbunatatire suplimentara pentru ambii iteratori este ca pot fi definite ca un sir, indicand un atribut pe modelul de vizualizari (returnand un nedefinit daca vizualizarea nu are model). In plus, viewFilter poate lua un obiect predicat care ar incerca, de asemenea, sa se potriveasca cu valoarea din modelul vizualizarii, adica: view.setFilter ({visible: true});

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR